{"id":"CVE-2021-29504","aliases":["BIT-wp-cli-2021-29504","EUVD-2021-1189","GHSA-rwgm-f83r-v3qj","openSUSE-SU-2024:11514-1"],"status":"published","title":"Improper Certificate Validation in WP-CLI framework","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.","severity":{"version":"3.1","score":9.1,"vector":"CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:N","level":"critical","assessor":"cna","from":"cve"},"epss":{"day":"2026-11-10","score":0.01312,"percentile":0.70924,"model":"v2026.06.15"},"facts":{"in_kev":false,"known_exploited":false,"public_exploit":false,"fix_available":true},"cwes":["CWE-295"],"published":"2021-05-19T23:03:11Z","modified":"2026-10-24T10:50:12Z","fixes":[{"ecosystem":"Packagist","package":"wp-cli/wp-cli","fixed_in":["2.5.0"],"sources":["ghsa","osv"]},{"ecosystem":"Bitnami","package":"wp-cli","fixed_in":["2.5.0"],"sources":["osv"]},{"ecosystem":"openSUSE:Tumbleweed","package":"wp-cli","fixed_in":["2.5.0-1.2"],"sources":["osv"]}],"affected":[{"source":"ghsa","ecosystem":"Packagist","package":"wp-cli/wp-cli","ranges":[{"type":"ECOSYSTEM","events":[{"introduced":"0.12.0"},{"fixed":"2.5.0"}]}]},{"source":"osv","ecosystem":"Bitnami","package":"wp-cli","ranges":[{"type":"SEMVER","events":[{"introduced":"0.12.0"},{"fixed":"2.5.0"}]}]},{"source":"osv","ecosystem":"Packagist","package":"wp-cli/wp-cli","ranges":[{"type":"ECOSYSTEM","events":[{"introduced":"0.12.0"},{"fixed":"2.5.0"}]}],"versions":["v0.12.0","v0.12.1","v0.13.0","v0.14.0","v0.14.1","v0.15.0","v0.15.1","v0.16.0","v0.17.0","v0.17.1","v0.17.2","v0.18.0","v0.18.1","v0.19.0","v0.19.1","v0.19.2","v0.19.3","v0.20.0","v0.20.1","v0.20.2","v0.20.3","v0.20.4","v0.21.0","v0.21.1","v0.22.0","v0.23.0","v0.23.1","v0.24.0","v0.24.1","v0.25.0","v1.0.0","v1.1.0","v1.2.0","v1.2.1","v1.3.0","v1.4.0","v1.4.1","v1.5.0","v1.5.1","v2.0.0","v2.0.1","v2.1.0","v2.2.0","v2.3.0","v2.4.0","v2.4.1"]},{"source":"osv","ecosystem":"openSUSE:Tumbleweed","package":"wp-cli","ranges":[{"type":"ECOSYSTEM","events":[{"introduced":"0"},{"fixed":"2.5.0-1.2"}]}]}],"products":[{"vendor":"wp-cli","product":"wp-cli"}],"references":[{"url":"https://github.com/wp-cli/wp-cli/security/advisories/GHSA-rwgm-f83r-v3qj","tags":["x_refsource_CONFIRM","x_transferred","Third Party Advisory","advisory","web"]},{"url":"https://github.com/wp-cli/checksum-command/pull/86","tags":["x_refsource_MISC","x_transferred","Patch","Third Party Advisory","advisory","fix","web"]},{"url":"https://github.com/wp-cli/config-command/pull/128","tags":["x_refsource_MISC","x_transferred","Patch","Third Party Advisory","advisory","fix","web"]},{"url":"https://github.com/wp-cli/core-command/pull/186","tags":["x_refsource_MISC","x_transferred","Patch","Third Party Advisory","advisory","fix","web"]},{"url":"https://github.com/wp-cli/extension-command/pull/287","tags":["x_refsource_MISC","x_transferred","Patch","Third Party Advisory","advisory","fix","web"]},{"url":"https://github.com/wp-cli/package-command/pull/138","tags":["x_refsource_MISC","x_transferred","Third Party Advisory","advisory","web"]},{"url":"https://github.com/wp-cli/wp-cli/pull/5523","tags":["x_refsource_MISC","x_transferred","Patch","Third Party Advisory","advisory","fix","web"]},{"url":"https://nvd.nist.gov/vuln/detail/CVE-2021-29504","tags":["web","advisory"]},{"url":"https://github.com/FriendsOfPHP/security-advisories/blob/master/wp-cli/wp-cli/CVE-2021-29504.yaml","tags":["web"]},{"url":"https://github.com/advisories/GHSA-rwgm-f83r-v3qj"},{"url":"","tags":["advisory"]},{"url":"https://www.suse.com/security/cve/CVE-2021-29504","tags":["web"]}],"sources":{"cve":[{"id":"CVE-2021-29504","title":"Improper Certificate Validation in WP-CLI framework","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.","status":"published","published":"2021-06-07T20:50:17Z","modified":"2024-08-03T22:11:05.507Z","cvss":[{"version":"3.1","score":9.1,"vector":"CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:N","level":"critical","assessor":"cna"}],"cwes":["CWE-295"],"updated_at":"2026-11-02T14:33:06.32268Z"}],"euvd":[{"id":"EUVD-2021-1189","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.","status":"published","published":"2021-06-07T20:50:17Z","modified":"2024-08-03T22:11:05Z","cvss":[{"version":"3.1","score":9.1,"vector":"CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:N","level":"critical"}],"updated_at":"2026-11-03T03:24:44.540278Z"}],"ghsa":[{"id":"GHSA-rwgm-f83r-v3qj","title":"Improper Certificate Validation in WP-CLI framework","description":"### Impact\nAn 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.\n\n### Patches\nThe 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.\n\nThe 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.\n\nhttps://github.com/wp-cli/wp-cli/pull/5523 has also added an `--insecure` flag to the `cli update` command to counter this breaking change.\n\nSubsequent PRs on the command repositories have added an `--insecure` flag to the appropriate commands on the following repositories to counter the breaking change:\n\n* https://github.com/wp-cli/config-command/pull/128\n* https://github.com/wp-cli/core-command/pull/186\n* https://github.com/wp-cli/extension-command/pull/287\n* https://github.com/wp-cli/checksum-command/pull/86\n* https://github.com/wp-cli/package-command/pull/138\n\n### Workarounds\nThere is no direct workaround for the default insecure behavior of `wp-cli/wp-cli` versions before 2.5.0.\n\nThe 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.\n\n### References\n* [CWE: Improper Certificate Validation](https://cwe.mitre.org/data/definitions/295.html)\n\n### For more information\nIf you have any questions or comments about this advisory:\n* Join the `#cli` channel in the [WordPress.org Slack](https://make.wordpress.org/chat/) to ask questions or provide feedback.\n","status":"published","published":"2021-05-19T23:03:11Z","modified":"2024-02-07T18:52:56Z","cvss":[{"version":"3.1","score":9.1,"vector":"CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:N","level":"critical"}],"cwes":["CWE-295"],"updated_at":"2026-11-02T14:37:36.777238Z"}],"nvd":[{"id":"CVE-2021-29504","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.","status":"published","published":"2021-06-07T21:15:08.387Z","modified":"2026-06-17T03:47:47.383Z","cvss":[{"version":"3.1","score":9.1,"vector":"CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:N","level":"critical","assessor":"secondary"},{"version":"3.1","score":7.4,"vector":"CVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:U/C:H/I:H/A:N","level":"high","assessor":"primary"},{"version":"2.0","score":7.5,"vector":"AV:N/AC:L/Au:N/C:P/I:P/A:P","level":"high","assessor":"primary"}],"cwes":["CWE-295"],"updated_at":"2026-11-02T14:06:54.439974Z"}],"osv":[{"id":"CVE-2021-29504","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.","status":"published","published":"2021-06-07T21:15:08.387Z","modified":"2026-10-24T10:50:12.575917823Z","cvss":[{"version":"3.1","score":7.4,"vector":"CVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:U/C:H/I:H/A:N","level":"high"}],"updated_at":"2026-11-02T15:44:19.129331Z"},{"id":"GHSA-rwgm-f83r-v3qj","title":"Improper Certificate Validation in WP-CLI framework","description":"### Impact\nAn 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.\n\n### Patches\nThe 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.\n\nThe 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.\n\nhttps://github.com/wp-cli/wp-cli/pull/5523 has also added an `--insecure` flag to the `cli update` command to counter this breaking change.\n\nSubsequent PRs on the command repositories have added an `--insecure` flag to the appropriate commands on the following repositories to counter the breaking change:\n\n* https://github.com/wp-cli/config-command/pull/128\n* https://github.com/wp-cli/core-command/pull/186\n* https://github.com/wp-cli/extension-command/pull/287\n* https://github.com/wp-cli/checksum-command/pull/86\n* https://github.com/wp-cli/package-command/pull/138\n\n### Workarounds\nThere is no direct workaround for the default insecure behavior of `wp-cli/wp-cli` versions before 2.5.0.\n\nThe 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.\n\n### References\n* [CWE: Improper Certificate Validation](https://cwe.mitre.org/data/definitions/295.html)\n\n### For more information\nIf you have any questions or comments about this advisory:\n* Join the `#cli` channel in the [WordPress.org Slack](https://make.wordpress.org/chat/) to ask questions or provide feedback.\n","status":"published","published":"2021-05-19T23:03:11Z","modified":"2026-07-08T06:28:33.16207698Z","cvss":[{"version":"3.1","score":9.1,"vector":"CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:N","level":"critical"}],"cwes":["CWE-295"],"updated_at":"2026-11-02T15:46:56.281047Z"},{"id":"BIT-wp-cli-2021-29504","title":"Improper Certificate Validation in WP-CLI framework","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.","status":"published","published":"2024-03-06T11:08:47.759Z","modified":"2026-09-10T16:01:48.484421397Z","updated_at":"2026-11-02T15:28:36.455807Z"},{"id":"openSUSE-SU-2024:11514-1","title":"wp-cli-2.5.0-1.2 on GA media","description":"These are all security issues fixed in the wp-cli-2.5.0-1.2 package on the GA media of openSUSE Tumbleweed.","status":"published","published":"2024-06-15T00:00:00Z","modified":"2026-02-04T03:07:50.703897Z","updated_at":"2026-11-02T16:58:35.195147Z"}]}}