CVE-2021-29504

Improper Certificate Validation in WP-CLI framework

HIGH
7.4
CVSS Score
Published: June 7, 2021 at 08:50 PM UTC
Updated: June 17, 2026 at 03:47 AM UTC
1 product affected across 1 vendorCli Wp Cli

Using wp-cli by wp-cli?

Get instant alerts when new vulnerabilities affect wp-cli - before attackers find them.

Real-time alertsTrack your software stackFree plan available
Severity
HIGH7.4
Exploit prediction
EPSS 1%

Description

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.

Affected

Our own answer: ranges merged, affected separated from platform-only, with confidence and review flags.

v < 2.5.00.12.0 ≤ v < 2.5.0
Affected range stops below 2.5.0, so it looks safe — our inference, not a vendor statement

References (7)

x_refsource_MISCPatchThird Party Advisory
https://github.com/wp-cli/checksum-command/pull/86
x_refsource_MISCPatchThird Party Advisory
https://github.com/wp-cli/config-command/pull/128
x_refsource_MISCPatchThird Party Advisory
https://github.com/wp-cli/core-command/pull/186
x_refsource_MISCPatchThird Party Advisory
https://github.com/wp-cli/extension-command/pull/287
x_refsource_MISCPatchThird Party Advisory
https://github.com/wp-cli/wp-cli/pull/5523

CVSS

Attack Vector
NETWORK
Complexity
HIGH
Privileges
NONE
User Interaction
NONE
Scope
UNCHANGED
Confidentiality
HIGH
Integrity
HIGH
Availability
NONE
Vector?

Quick Info

StatusMODIFIED
CWE
CWE-295

Get alerted

Stop reading CVE feeds looking for your own stack

Track the products you run and VulnTracker tells you when a new CVE affects them — with what is known about fixing it, and nothing about the rest.

Free plan, no card