WP-CLI is the command-line interface for WordPress. 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. 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 https://github.com/wp-cli/wp-cli/pull/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. https://github.com/wp-cli/wp-cli/pull/5523 has also added an `--insecure` flag to the `cli update` command to counter this breaking change. 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.

There are packages installed that are affected by a vulnerability referenced in the following CVE:

  - WP-CLI is the command-line interface for WordPress. 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. 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 https://github.com/wp-cli/wp-cli/pull/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. https://github.com/wp-cli/wp-cli/pull/5523 has also added an
    `--insecure` flag to the `cli update` command to counter this breaking change. 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. (CVE-2021-29504)

ID	Name	Product	Family	Severity
418965	SCA: security update for wp-cli/wp-cli (GHSA-rwgm-f83r-v3qj)	Tenable Cloud Security	SCA Checks	high
418965	SCA: security update for wp-cli/wp-cli (GHSA-rwgm-f83r-v3qj)	Tenable Self-Hosted Container Security	SCA Checks	high

Detections

Analytics

CVE-2021-29504

high

Tenable Plugins

high

high