Answer in brief
CVE-2026-45293 records a High severity rce vulnerability in WordPress Coding Standards (WordPressCS) contains an arbitrary code execution vulnerability. The source record does not mark it as known exploited. 1 affected package is mapped in the feed.
Answer in brief
CVE-2026-45293 records a High severity rce vulnerability in WordPress Coding Standards (WordPressCS) contains an arbitrary code execution vulnerability. The source record does not mark it as known exploited. 1 affected package is mapped in the feed.
Update wp-coding-standards/wpcs to 3.4.1 if you use the affected versions. Test the change in a non-production environment first.
Local check
hol-guard supply-chain scanRCE describes the vulnerability class recorded for this advisory. The current record does not mark CVE-2026-45293 as known exploited; continue to monitor the source for status changes. The feed includes package mappings that can be checked against lockfiles and deployed manifests.
| Package | Affected range | Fixed version |
|---|---|---|
| wp-coding-standards/wpcscomposer | >=0.14.1,<3.4.1 | 3.4.1 |
Fixed versions are reported by the source feed; confirm compatibility before updating.
Reported by GitHub Security Advisories (ghsa).
CVE-2026-45293 records a High severity rce vulnerability in WordPress Coding Standards (WordPressCS) contains an arbitrary code execution vulnerability. The source record does not mark it as known exploited. 1 affected package is mapped in the feed.
The source record does not mark it as known exploited.
Check lockfiles and deployed manifests for wp-coding-standards/wpcs.
HOL Guard can help your team review package activity against supported protection paths.
Explore HOL GuardUpdate wp-coding-standards/wpcs to 3.4.1 if you use the affected versions. Test the change in a non-production environment first.
Local check
hol-guard supply-chain scanRCE describes the vulnerability class recorded for this advisory. The current record does not mark CVE-2026-45293 as known exploited; continue to monitor the source for status changes. The feed includes package mappings that can be checked against lockfiles and deployed manifests.
| Package | Affected range | Fixed version |
|---|---|---|
| wp-coding-standards/wpcscomposer | >=0.14.1,<3.4.1 | 3.4.1 |
Fixed versions are reported by the source feed; confirm compatibility before updating.
Reported by GitHub Security Advisories (ghsa).
CVE-2026-45293 records a High severity rce vulnerability in WordPress Coding Standards (WordPressCS) contains an arbitrary code execution vulnerability. The source record does not mark it as known exploited. 1 affected package is mapped in the feed.
The source record does not mark it as known exploited.
Check lockfiles and deployed manifests for wp-coding-standards/wpcs.
HOL Guard can help your team review package activity against supported protection paths.
Explore HOL Guard### Impact WordPress Coding Standards (WordPressCS) versions before 3.4.1 contain an arbitrary code execution vulnerability in the `WordPress.WP.EnqueuedResourceParameters` sniff. As a result, running PHPCS with WordPressCS over untrusted PHP code, for example, in a CI pipeline that lints pull requests, or on a developer machine reviewing third-party code, could lead to arbitrary command execution on the scanning host. This affects users of the `WordPress` and `WordPress-Extra` rulesets. The `WordPress-Core` ruleset and the `WordPress-Docs` ruleset are not affected. The vulnerability happens when the sniff checks whether the `$var` argument passed to functions such as `wp_enqueue_script()` or `wp_register_script()` evaluates to a falsy value. The sniff's `is_falsy()` method reconstructed the argument and ran it through `eval()`. Because of this, a maliciously crafted `$ver` argument such as `'system'('id')` would be executed during the scan. ### Patches This issue has been fixed in WordPressCS 3.4.1. We recommend all users upgrade to 3.4.1 or later. ### Workaround Users of the `WordPress` and `WordPress-Extra` rulesets, who cannot upgrade immediately, can disable the affected sniff by adding an `<exclude>` tag to their custom ruleset (the `<rule>` `ref` value might vary depending on the ruleset): ```xml <rule ref="WordPress"> <exclude name="WordPress.WP.EnqueuedResourceParameters"/> </rule> ``` To verify that the sniff has been disabled, run PHPCS with the `-e` flag, which lists all the sniffs a standard will run. `WordPress.WP.EnqueuedResourceParameters` should no longer appear in the output under the `WordPress` section: ``` phpcs -e --standard=/path/to/ruleset.xml ``` ### Credits Many thanks to [@FORIMOC](https://github.com/FORIMOC) for responsibly disclosing this vulnerability. ### How can I report a security bug? Please report security vulnerabilities privately via [the "Security and quality" tab on the WPCS repository](https://github.com/WordPress/WordPress-Coding-Standards/security).
### Impact WordPress Coding Standards (WordPressCS) versions before 3.4.1 contain an arbitrary code execution vulnerability in the `WordPress.WP.EnqueuedResourceParameters` sniff. As a result, running PHPCS with WordPressCS over untrusted PHP code, for example, in a CI pipeline that lints pull requests, or on a developer machine reviewing third-party code, could lead to arbitrary command execution on the scanning host. This affects users of the `WordPress` and `WordPress-Extra` rulesets. The `WordPress-Core` ruleset and the `WordPress-Docs` ruleset are not affected. The vulnerability happens when the sniff checks whether the `$var` argument passed to functions such as `wp_enqueue_script()` or `wp_register_script()` evaluates to a falsy value. The sniff's `is_falsy()` method reconstructed the argument and ran it through `eval()`. Because of this, a maliciously crafted `$ver` argument such as `'system'('id')` would be executed during the scan. ### Patches This issue has been fixed in WordPressCS 3.4.1. We recommend all users upgrade to 3.4.1 or later. ### Workaround Users of the `WordPress` and `WordPress-Extra` rulesets, who cannot upgrade immediately, can disable the affected sniff by adding an `<exclude>` tag to their custom ruleset (the `<rule>` `ref` value might vary depending on the ruleset): ```xml <rule ref="WordPress"> <exclude name="WordPress.WP.EnqueuedResourceParameters"/> </rule> ``` To verify that the sniff has been disabled, run PHPCS with the `-e` flag, which lists all the sniffs a standard will run. `WordPress.WP.EnqueuedResourceParameters` should no longer appear in the output under the `WordPress` section: ``` phpcs -e --standard=/path/to/ruleset.xml ``` ### Credits Many thanks to [@FORIMOC](https://github.com/FORIMOC) for responsibly disclosing this vulnerability. ### How can I report a security bug? Please report security vulnerabilities privately via [the "Security and quality" tab on the WPCS repository](https://github.com/WordPress/WordPress-Coding-Standards/security).