Read the docs
TI-2021-10212 Aliases CVE-2021-29504GHSA-rwgm-f83r-v3qj

Improper Certificate Validation in WP-CLI framework

Priority MEDIUM 42CWE-295Published · Updated

Key facts

Attack vector
Network
Privileges required
None
User interaction
None
Attack complexity
Low
Impact type
Spoofing
Confidentiality · integrity · availability
High · High · None
Fix status
Fixed

Attack profile from CVSS 3.1 · CNA. Fix status from CNA and GitHub. Impact type from CWE-295.

Summary

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.

Why it matters now

EPSS 0.01312 70th percentileScored 2026-11-07
Fix Fixed wp-cli (wp-cli): 2.5.0wp-cli/wp-cli (Packagist): 2.5.0

SSVC decision points

Not available: CISA has not published SSVC decision points for this record.

Affected products

VendorProductAffected versionsFixed inStatusSource
wp-cliwp-clibefore 2.5.02.5.0Patch availableCNA
—wp-cli/wp-cli (Packagist)0.12.0 to before 2.5.02.5.0Patch availableGHSA-rwgm-f83r-v3qj
  • wp-cli Vendorwp-cli Affected before 2.5.0 Fixed in 2.5.0 Patch available CNA
  • wp-cli/wp-cli (Packagist) Vendor— Affected 0.12.0 to before 2.5.0 Fixed in 2.5.0 Patch available GHSA-rwgm-f83r-v3qj

CPE configurations NVD · 1

CPEVersionsRoleVendor
cpe:2.3:a:wp-cli:wp-cli:*:*:*:*:*:*:*:*0.12.0 to before 2.5.0Vulnerablewp-cli
  • cpe:2.3:a:wp-cli:wp-cli:*:*:*:*:*:*:*:* Versions 0.12.0 to before 2.5.0 Vulnerable ·wp-cli

Remediation

  • Fix · CNA wp-cli (wp-cli) Fixed in 2.5.0
  • Fix · GHSA-rwgm-f83r-v3qj wp-cli/wp-cli (Packagist) Fixed in 2.5.0 Advisory →

Vendor assessments

Red Hat

Red Hat's page for this CVE →

Not affected: 1 product
  • Red Hat

Timeline

  1. 2026-10-02 Threatist record created from CVE-2021-29504
  2. 2026-10-03 Alias added: GHSA-rwgm-f83r-v3qj

References

Sources