This is a code execution vulnerability in WordPress Coding Standards (WordPressCS) — specifically, eval() on reconstructed function arguments within a PHPCS sniff. Version 3.4.1 patches it. That much is straightforward.
But the vulnerability isn't really in the code being scanned — it's in the CI pipeline scanning it. WordPressCS is deployed precisely to lint untrusted input: third-party plugins, community pull requests, open-source contributions under review. When your CI runs WordPressCS on a PR from a stranger, you're executing 200+ sniffs written by a third party on your build agent, with no sandbox and no visibility into what those sniffs do at runtime. This CVE inverts that trust model: the tool designed to analyze untrusted code becomes the execution vector for that untrusted code.
The EPSS score of 0.00184 is dangerously misleading. EPSS models exploitation likelihood for internet-facing servers — it doesn't account for the blast radius of a compromised build agent that runs linters on every commit across an organization. A single vulnerable WordPressCS instance on a build agent gives an attacker persistent, invisible access to artifact repositories, deployment credentials, and staging environments. Each commit triggers the linter, each run is a potential execution opportunity, and anomalous behavior looks identical to normal operation because the linter is supposed to process untrusted input.
Check your CI pipelines now. If WordPressCS is running pre-3.4.1, treat that build agent as potentially compromised — not because exploitation is likely in the EPSS sense, but because the attack surface is exactly what the tool was designed to process. The CVSS 8.6 reflects the impact correctly; the EPSS should not be used to argue this is theoretical.