CVE-2026-45293: WordPress Coding Standards RCE Vulnerability

CVE-2026-45293 Overview

CVE-2026-45293 is an arbitrary code execution vulnerability in WordPress Coding Standards (WordPressCS), a widely used set of PHP_CodeSniffer rules that enforce WordPress coding conventions. The flaw affects versions 0.14.1 through 3.4.0 and resides in the WordPress.WP.EnqueuedResourceParameters sniff, which is active in the WordPress and WordPress-Extra rulesets. The sniff reconstructs the $ver argument passed to functions such as wp_enqueue_script() and evaluates it with PHP's eval() inside its is_falsy() method. A crafted argument executes host-side commands when PHPCS scans the file. The issue is fixed in version 3.4.1.

Critical Impact
Running PHPCS with WordPressCS against untrusted PHP, such as third-party code or pull requests in a CI pipeline, results in arbitrary command execution on the scanning host.

Affected Products

WordPress Coding Standards 0.14.1 through 3.4.0
WordPress ruleset (affected)
WordPress-Extra ruleset (affected); WordPress-Core and WordPress-Docs rulesets are not affected

Discovery Timeline

2026-07-28 - CVE-2026-45293 published to the National Vulnerability Database
2026-07-29 - Last updated in NVD database

Technical Details for CVE-2026-45293

Vulnerability Analysis

The vulnerability is a code injection flaw classified under CWE-95: Improper Neutralization of Directives in Dynamically Evaluated Code. WordPressCS analyzes calls to WordPress enqueue functions such as wp_enqueue_script(), wp_enqueue_style(), wp_register_script(), and wp_register_style(). The EnqueuedResourceParameters sniff inspects the $ver parameter to warn developers about missing or falsy version strings.

To determine whether the reconstructed argument is falsy, the sniff feeds the token stream back into a PHP expression and passes it to eval() inside is_falsy(). Because the tokens come directly from the file under review, an attacker who controls that file controls the string being evaluated. The scanning process runs with the privileges of the developer or CI runner executing PHPCS, so injected code executes in that context.

Root Cause

The root cause is the use of eval() on attacker-influenced input during static analysis. Static analyzers should reason about code structurally, not execute reconstructed source. Any expression that PHP accepts as a function call, such as 'system'('id'), is evaluated when the sniff processes it, converting a lint pass into code execution.

Attack Vector

The attack vector is local but exploitable through common developer workflows. A malicious contributor submits a pull request containing PHP source with a crafted $ver argument to an enqueue function. When a maintainer or a CI pipeline runs PHPCS with the WordPress or WordPress-Extra ruleset, the payload executes on the scanning host. User interaction is required in the form of running the scan, but the outcome compromises confidentiality, integrity, and availability of that host and any credentials, tokens, or repositories accessible to it.

See the GitHub Security Advisory GHSA-3pwp-g2mj-5p3v and Pull Request #2771 for the technical write-up and the corresponding fix.

Detection Methods for CVE-2026-45293

Indicators of Compromise

Unexpected child processes (for example sh, bash, curl, wget, nc) spawned by phpcs, php, or CI runner processes during lint stages
Outbound network connections initiated by the PHPCS process to external hosts
Presence of wp_enqueue_script(), wp_enqueue_style(), wp_register_script(), or wp_register_style() calls whose $ver argument contains function-call syntax such as 'system'('id') or backtick operators
Modification of files under ~/.ssh, CI secrets directories, or Git credentials by the PHPCS process

Detection Strategies

Scan repositories for enqueue function calls where the $ver parameter is not a simple string or numeric literal, using AST-based tooling rather than PHPCS itself
Audit CI pipeline logs for PHPCS invocations that produced non-standard output, unexpected exit codes, or execution times inconsistent with prior runs
Inventory PHPCS installations and confirm the WordPressCS version is 3.4.1 or later; treat any installation between 0.14.1 and 3.4.0 as vulnerable

Monitoring Recommendations

Enable process-tree telemetry on developer workstations and CI runners to alert on shell or interpreter processes descending from phpcs
Restrict egress from CI runners to a known allowlist so exploitation attempts that fetch second-stage payloads fail visibly
Log and review changes to CI configuration files that alter the PHPCS ruleset or bypass version pinning

How to Mitigate CVE-2026-45293

Immediate Actions Required

Upgrade WordPress Coding Standards to version 3.4.1 or later across all developer environments and CI pipelines
Pin the WordPressCS version in composer.json and CI configuration to prevent silent downgrades
Re-run scans of recent untrusted contributions after upgrading, and rotate any secrets that were reachable from affected CI runners

Patch Information

The fix removes the use of eval() in the is_falsy() method of the EnqueuedResourceParameters sniff. See the 3.4.1 release notes and the remediation commit a29048d. Users on any version from 0.14.1 through 3.4.0 should upgrade immediately.

Workarounds

If upgrading is not immediately possible, switch the active ruleset to WordPress-Core or WordPress-Docs, which do not include the vulnerable sniff
Alternatively, exclude the WordPress.WP.EnqueuedResourceParameters sniff via the <exclude> directive in the project phpcs.xml configuration
Isolate PHPCS execution for untrusted code in an ephemeral container with no secrets, no persistent storage, and no outbound network access

bash

# Upgrade WordPressCS in a Composer-managed project
composer require --dev wp-coding-standards/wpcs:^3.4.1

# Verify the installed version
vendor/bin/phpcs -i

# Temporary workaround: exclude the vulnerable sniff in phpcs.xml
# <rule ref="WordPress">
#     <exclude name="WordPress.WP.EnqueuedResourceParameters"/>
# </rule>