high · 8.6CVE-2026-45293Jul 28, 2026

CVE-2026-45293: WordPress Coding Standards (WPCS) Eval Injection via EnqueuedResourceParameters Sniff

Rohit Hatagale
AI Security Researcher, SecureLayer7

A code linting tool (WordPress Coding Standards) executed arbitrary OS commands on the developer or CI machine that ran it, just by scanning a maliciously crafted PHP file.

Packagewp-coding-standards/wpcs
Ecosystemcomposer
Affected>= 0.14.1, < 3.4.1
Fixed in3.4.1
CVE-2026-45293: WordPress Coding Standards (WPCS) Eval Injection via EnqueuedResourceParameters Sniff

The problem

The WordPress.WP.EnqueuedResourceParameters sniff in WordPressCS checks whether the $ver argument passed to functions like wp_enqueue_script() is falsy. Its is_falsy() method reconstructed the argument value as a PHP expression string and passed it directly to eval() to test it.

Anyone who scanned untrusted PHP code with PHPCS and the WordPress or WordPress-Extra ruleset was at risk. A malicious contributor could trigger command execution on a CI runner or a developer's workstation simply by submitting a pull request containing a crafted enqueue call.

Proof of concept

A working proof-of-concept for CVE-2026-45293 in wp-coding-standards/wpcs, with the exact payload below.

php
<?php
// Malicious file submitted for code review or opened in a CI pipeline.
// When PHPCS runs the WordPress.WP.EnqueuedResourceParameters sniff,
// is_falsy() reconstructs the $ver argument and passes it to eval().
// PHP's variable-function syntax turns 'system' into a callable, running id(1).
wp_enqueue_script( 'evil', 'https://example.com/evil.js', [], 'system'('id') );

The root cause is CWE-95: the sniff reconstructed the token stream of the $ver argument into a raw PHP expression string, then called eval() on it to check whether the result would be falsy at runtime. PHP's variable-function syntax ('system'('id')) is a valid expression, so eval() called system() with id as its argument, executing a shell command on the host running the scan.

The fix in commit a29048d0bbef5cf25d42349c74e4072d3cbc8325 (PR #2771) removed the eval() call entirely. The patched is_falsy() now inspects the token type and value directly against a known-safe allowlist of falsy literals (false, null, 0, 0.0, '', '0') without ever executing the argument.

The fix

Upgrade wp-coding-standards/wpcs to **3.4.1** or later via Composer:

`` composer require wp-coding-standards/wpcs:^3.4.1 ``

If an immediate upgrade is not possible, exclude the affected sniff in your custom ruleset:

``xml <rule ref="WordPress"> <exclude name="WordPress.WP.EnqueuedResourceParameters"/> </rule> ``

Only the WordPress and WordPress-Extra rulesets are affected. WordPress-Core and WordPress-Docs are not.

Reported by FORIMOC.

References: [1][2][3][4][5]

Related research