What is the CVSS score of CVE-2026-45293?

CVE-2026-45293 has a CVSS 3.1 base score of 8.6 (High). CVSS vector: CVSS:3.1/AV:L/AC:L/PR:N/UI:R/S:C/C:H/I:H/A:H. EPSS exploitation probability: 0.2%.

Which versions of WordPress Coding Standards are affected by CVE-2026-45293?

WordPressCS (WordPress Coding Standards), a PHP code linting tool embedded in development workflows and CI/CD pipelines, contains a remote code execution vulnerability in versions before 3.4.1.. A patch is available.

How to fix or mitigate CVE-2026-45293?

Within 24 hours: Identify all machines running WordPressCS (development, CI/CD, build servers) by reviewing composer.json/lock files and CI job definitions; pause or segregate WordPressCS scans of untrusted pull requests pending patching. Within 7 days: Deploy WordPressCS 3.4.1 or later across all environments via composer or your package manager; prioritize CI/CD systems scanning external pull requests. Within 30 days: Audit build server logs from before the patch date for unusual execution patterns in WordPressCS-related jobs; verify no build artifacts or deployed code were compromised.

WordPress Coding Standards CVE-2026-45293

EUVD-2026-49877 HIGH

Eval Injection (CWE-95)

2026-07-28 https://github.com/WordPress/WordPress-Coding-Standards

GHSA-3pwp-g2mj-5p3v

PHP WordPress RCE Code Injection

8.6

CVSS 3.1 · Vendor: https://github.com/WordPress/WordPress-Coding-Standards

Severity by source

Vendor (https://github.com/WordPress/WordPress-Coding-Standards) PRIMARY

8.6 HIGH

AV:L/AC:L/PR:N/UI:R/S:C/C:H/I:H/A:H

vuln.today AI

8.6 HIGH

Attacker supplies local file but the victim must run the scan (AV:L/UI:R); no attacker privileges needed (PR:N); eval breakout from the sniff to host yields S:C and full C/I/A on the scanning host.

3.1 AV:L/AC:L/PR:N/UI:R/S:C/C:H/I:H/A:H

4.0 AV:L/AC:L/AT:N/PR:N/UI:A/VC:H/VI:H/VA:H/SC:N/SI:N/SA:N

Primary rating from Vendor (https://github.com/WordPress/WordPress-Coding-Standards).

CVSS VectorVendor: https://github.com/WordPress/WordPress-Coding-Standards

Attack Vector

Local

Attack Complexity

Low

Privileges Required

None

User Interaction

Required

Scope

Changed

Confidentiality

High

Integrity

High

Availability

High

Lifecycle Timeline

Source Code Evidence Fetched

Jul 28, 2026 - 14:50 vuln.today

Analysis Generated

Jul 28, 2026 - 14:50 vuln.today

CVE Published

Jul 28, 2026 - 14:28 github-advisory

HIGH 8.6

DescriptionCVE.org

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 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.

Articles & Coverage 2

News 6 New PHP Vulnerabilities - Jul 29, 2026 News 19 New WordPress Vulnerabilities - 2 Critical, 17 High Jul 29, 2026

AnalysisAI

Arbitrary command execution in WordPress Coding Standards (WordPressCS) before 3.4.1 lets attacker-controlled PHP source trigger code execution on the machine running the linter. The flawed WordPress.WP.EnqueuedResourceParameters sniff reconstructed the $ver argument of wp_enqueue_script()/wp_register_script() and passed it to eval(), so scanning a malicious file (for example a pull request in CI) with the WordPress or WordPress-Extra rulesets runs the attacker's payload. There is no public exploit identified at time of analysis and EPSS is low (0.18%), but the technical impact is total and a patched release (3.4.1) is available.

Technical ContextAI

WordPressCS is a set of PHP_CodeSniffer (PHPCS) sniffs distributed as the Composer package wp-coding-standards/wpcs, used to statically lint PHP against WordPress coding conventions. The root cause is CWE-95 (improper neutralization of directives in dynamically evaluated code, 'eval injection'): the is_falsy() method in EnqueuedResourceParametersSniff tried to decide whether a version argument evaluated to a falsy value by string-concatenating the argument's tokens into $code_string and calling eval("return (bool) $code_string;"). A token allow-list (T_STRING_CONCAT, parentheses, operators, casts, etc.) was intended to keep this 'safe,' but constructs like the dynamic function-call syntax 'system'('id') slipped through and were executed. The fix (PR #2771 / commit a29048d) removes eval() entirely and replaces it with static analysis using PHPCSUtils (Arrays, TextStrings, Collections), only recognizing literal false/0/'0'/''/empty-array as falsy.

RemediationAI

Vendor-released patch: 3.4.1 - upgrade wp-coding-standards/wpcs to 3.4.1 or later (e.g. composer require --dev wp-coding-standards/wpcs:^3.4.1), per the release at https://github.com/WordPress/WordPress-Coding-Standards/releases/tag/3.4.1 and advisory GHSA-3pwp-g2mj-5p3v. If you cannot upgrade immediately, disable the vulnerable sniff in your custom ruleset by adding <exclude name="WordPress.WP.EnqueuedResourceParameters"/> inside your <rule ref="WordPress"> (or WordPress-Extra) block, then confirm removal with phcs -e --standard=/path/to/ruleset.xml - the trade-off is losing enqueued-resource parameter checks (missing/incorrect $ver and in-footer arguments), a coding-quality regression but no security loss. As additional containment for CI, avoid linting untrusted pull requests on privileged runners, run the linter in an isolated/ephemeral container without deployment secrets, and treat third-party code review runs as untrusted execution.