Most recent entries from all

EUVD-2026-342330

fkie_cve-2026-45293

WordPress Coding Standards is a set of PHP_CodeSniffer rules (sniffs) that enforce WordPress coding conventions. From 0.14.1 until 3.4.1, the WordPress.WP.EnqueuedResourceParameters sniff (active in the WordPress and WordPress-Extra rulesets) reconstructed the $ver argument passed to functions such as wp_enqueue_script() and ran it through eval() inside its is_falsy() method, so a maliciously crafted argument such as 'system'('id') would execute during a scan; as a result, running PHPCS with WordPressCS over untrusted PHP (for example a CI pipeline that lints pull requests, or a developer reviewing third-party code) could lead to arbitrary command execution on the scanning host. The WordPress-Core and WordPress-Docs rulesets are not affected. This issue is fixed in version 3.4.1.

GHSA-3pwp-g2mj-5p3v — WordPress Coding Standards (WordPressCS) contains an arbitrary code execution vulnerability

Affected: Packagist: wp-coding-standards/wpcs

### 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` fla…