Impact
An improper error handling in HTTPS requests management in WP-CLI version 0.12.0 and later allows remote attackers able to intercept the communication to remotely disable the certificate verification on WP-CLI side, gaining full control over the communication content, including the ability to impersonate update servers and push malicious updates towards WordPress instances controlled by the vulnerable WP-CLI agent, or push malicious updates toward WP-CLI itself.
Patches
The vulnerability stems from the fact that the default behavior of WP_CLI\Utils\http_request()
when encountering a TLS handshake error is to disable certificate validation and retry the same request.
The default behavior has been changed with version 2.5.0 of WP-CLI and the wp-cli/wp-cli
framework (via wp-cli/wp-cli#5523) so that the WP_CLI\Utils\http_request()
method accepts an $insecure
option that is false
by default and consequently that a TLS handshake failure is a hard error by default. This new default is a breaking change and ripples through to all consumers of WP_CLI\Utils\http_request()
, including those in separate WP-CLI bundled or third-party packages.
wp-cli/wp-cli#5523 has also added an --insecure
flag to the cli update
command to counter this breaking change.
Subsequent PRs on the command repositories have added an --insecure
flag to the appropriate commands on the following repositories to counter the breaking change:
Workarounds
There is no direct workaround for the default insecure behavior of wp-cli/wp-cli
versions before 2.5.0.
The workaround for dealing with the breaking change in the commands directly affected by the new secure default behavior is to add the --insecure
flag to manually opt-in to the previous insecure behavior.
References
For more information
If you have any questions or comments about this advisory:
References
Impact
An improper error handling in HTTPS requests management in WP-CLI version 0.12.0 and later allows remote attackers able to intercept the communication to remotely disable the certificate verification on WP-CLI side, gaining full control over the communication content, including the ability to impersonate update servers and push malicious updates towards WordPress instances controlled by the vulnerable WP-CLI agent, or push malicious updates toward WP-CLI itself.
Patches
The vulnerability stems from the fact that the default behavior of
WP_CLI\Utils\http_request()
when encountering a TLS handshake error is to disable certificate validation and retry the same request.The default behavior has been changed with version 2.5.0 of WP-CLI and the
wp-cli/wp-cli
framework (via wp-cli/wp-cli#5523) so that theWP_CLI\Utils\http_request()
method accepts an$insecure
option that isfalse
by default and consequently that a TLS handshake failure is a hard error by default. This new default is a breaking change and ripples through to all consumers ofWP_CLI\Utils\http_request()
, including those in separate WP-CLI bundled or third-party packages.wp-cli/wp-cli#5523 has also added an
--insecure
flag to thecli update
command to counter this breaking change.Subsequent PRs on the command repositories have added an
--insecure
flag to the appropriate commands on the following repositories to counter the breaking change:Workarounds
There is no direct workaround for the default insecure behavior of
wp-cli/wp-cli
versions before 2.5.0.The workaround for dealing with the breaking change in the commands directly affected by the new secure default behavior is to add the
--insecure
flag to manually opt-in to the previous insecure behavior.References
For more information
If you have any questions or comments about this advisory:
#cli
channel in the WordPress.org Slack to ask questions or provide feedback.References