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

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

View

Attack ChainAIDerived

Hypothetical attack flow derived from CVE metadata – not a confirmed exploit chain

Access

Submit malicious PHP via PR
Delivery

CI runs WordPressCS lint
Exploit

Sniff reconstructs $ver into eval()
Execution

Payload 'system'('id') executes
Persist

Code execution on runner
Impact

Steal CI secrets

Vulnerability Assessment

Weakness	CWE CWE-95 OWASP Top 10:2025 A05:2025 - Injection ASVS 5.0 V1 - Encoding and Sanitization Eval input sanitization MITRE ATT&CK 1 technique across 1 tactic: Execution The technique list with ATT&CK links and the kill-chain view is part of the Basic plan and up. Sign in to read
Exploitation Conditions	Exploitation requires the victim to run PHPCS with WordPressCS versions >= 0.14.1 and < 3.4.1 configured with the WordPress or WordPress-Extra ruleset (the WordPress-Core and WordPress-Docs rulesets are not affected, and the EnqueuedResourceParameters sniff must be enabled) over PHP source the attacker controls. The attacker's file must invoke an enqueue function such as wp_enqueue_script()/wp_register_script() with a malicious $ver argument (e.g. 'system'('id')) that the sniff reconstructs and passes to eval(). Limiting factors: this is local/config-driven (AV:L) and requires that scan to actually be run (UI:R) - there is no remote or unauthenticated network trigger; the payload only fires when the specific sniff executes on the untrusted file, so environments that pin WordPress-Core/WordPress-Docs, exclude the sniff, or never lint untrusted code are not exploitable.
Impact	Signals are mixed and should be weighed carefully. Technical impact is severe - total code execution on the scanning host (CVSS 8.6, CVSS:3.1/AV:L/AC:L/PR:N/UI:R/S:C/C:H/I:H/A:H; SSVC Technical Impact: total) - but the exposure is narrow. The CVSS vector is Local (AV:L) with required user interaction (UI:R): an attacker cannot reach this over the network; a victim must actively run PHPCS/WordPressCS over the attacker's PHP, so it is a supply-chain/developer-tooling risk rather than a server-exposed one. SSVC records Exploitation: none and Automatable: no, and EPSS is low (0.18%, 8th percentile), consistent with no public exploit identified at time of analysis. The practical danger concentrates in CI pipelines that auto-lint untrusted pull requests, where 'user interaction' is effectively automated and the scanning runner may hold secrets or deployment credentials. Net: high impact but conditional and not currently exploited in the wild - prioritize for teams that lint third-party/PR code, lower urgency for isolated local use.
Exploit ScenarioDerived	An attacker opens a pull request to a repository whose CI lints changed PHP with the WordPress or WordPress-Extra ruleset, adding a file that calls wp_enqueue_script() with a crafted version argument such as 'system'('id'). When the CI job runs PHPCS, the sniff's is_falsy() feeds that argument to eval() and the command runs on the runner, potentially exposing CI secrets or enabling further compromise. No public exploit is identified at time of analysis, but the technique is described in the advisory and is trivial to reproduce given local execution.

This Week Schedule remediation this week. Why: HIGH severity (CVSS 7.0-8.9).

Patch available 0.2% exploitation probability (EPSS)

Get an e-mail when this CVE is exploited, patched or re-scored. Free account.

Alert me

AnalysisAIv1 – Jul 30, 2026

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.

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.

Affected VersionsENISA

WordPress-Coding-Standards 0.14.1, < 3.4.1

Affected Packages

composer wp-coding-standards/wpcs fix: 3.4.1

euvd wordpress_coding_standards_0_14_1 fix: 3.4.1

Source: OSV (Open Source Vulnerabilities)

Affects your stack

Affects 2 packages in composer, euvd

Checking this CVE against your own stacks and servers is part of the Basic plan and up.

Technical ContextAI · show details

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.

Know when PHP gets its next vulnerability

Watch products and get an email when something new is published
Check this CVE against your own stack and servers
Exploit and PoC references, threat intelligence from 22 sources

Continue with Google Continue with GitHub

No credit card · 7-day full trial

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

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

Executive ViewAI

Why It Matters

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. While no public exploit identified at time of analysis, unpatched systems running automated code scans on external pull requests face direct supply chain risk. Organizations using this tool in WordPress projects should apply the available patch (3.4.1) immediately.

Business Impact: High

Compensating Controls

Apply vendor patch.

Threat Intelligence Overview

EPSS Score

0.2%

Top 92% exploitable

Prevalence

Medium

widely used PHP dev linter, but dev-tooling not production runtime

Threat Intel

1 source

Data Quality

7 sources

Confidence: High

EUVD

NVD

CVE.org

EPSS

Vulnrichment GHSA

GitHub

VulDB

How this decision was reached

The engine reads each signal below and applies a fixed list of rules from top to bottom. The first rule that matches sets the recommended action – like a statement, every line is shown.

SignalValue

Severity HIGH

CISA KEV No

Public POC No

EPSS 0.2%

Patch available Yes

Active threat No

Deciding rule

HIGH severity (CVSS 7.0-8.9)

What every action level means

Emergency Immediate action required. Criteria: CRITICAL + in CISA KEV (actively exploited) without patch, OR CRITICAL + EPSS > 30% without patch, OR CRITICAL + active threat signals without patch.

Act Now Prioritize within 24-48h. Criteria: in KEV with patch available, OR CRITICAL + public POC, OR HIGH + EPSS > 10%, OR CRITICAL + active threat, OR any CRITICAL severity.

This Week Schedule remediation this week. Criteria: HIGH severity (CVSS 7.0-8.9). Patch within normal change window.

This Month Plan within 30 days. Criteria: MEDIUM severity (CVSS 4.0-6.9), lower exploitation probability. Include in regular patch cycle.

Monitor Track and reassess. Criteria: LOW severity (CVSS 0.1-3.9), minimal exploitation risk. No immediate action needed.

SSVC AssessmentENISA

SSVC Decision

Scheduled

Exploitation

None

System Exposure· derived

Small

Automatable

Human Impact

High

Technical Impact

Total

Priority Score

Low Medium High Critical

KEV: 0

EPSS: 0

CVSS: +43

PoC: 0

Weaponized: 0

Threat intel: 0

Gov advisory: 0

Attack Technique

Code Injection CRITICAL

Code injection occurs when an application accepts user input and passes it directly into a language interpreter or evaluator without proper sanitization.

Remote Code Execution CRITICAL

Remote Code Execution represents the critical moment when an attacker successfully runs arbitrary code on a target system without physical access.