PHPCSUtils EUVD-2026-97779

Requires the host to run PHP_CodeSniffer over attacker-supplied/untrusted PHP source using a sniff that extends AbstractArrayDeclarationSniff and calls getActualArrayKey() - concretely, PHPCSExtra's Universal.Arrays.DuplicateArrayKey or Universal.Arrays.MixedArrayKeyTypes sniffs, on PHPCSUtils >=1.0.0-alpha1 and <1.2.3. The limiting factors are: the vulnerable/triggering sniffs must be enabled in the active ruleset (UI:R - a person or pipeline must actively invoke the scan), and the attacker must be able to get their PHP code onto the scanning host (e.g. an untrusted PR in CI or third-party code reviewed on a developer machine). Teams that only lint their own trusted code, or that have excluded the triggering sniffs via <exclude> ruleset tags, are not realistically exposed.

This is a genuine high-severity issue but its real-world exploitability is meaningfully narrower than the 8.6 base score suggests. The CVSS 3.1 vector (AV:L/AC:L/PR:N/UI:R/S:C/C:H/I:H/A:H) yields full CIA impact with a scope change - accurate for what eval()-based CWE-95 code injection does once triggered: arbitrary command execution on the scanning host. However, AV:L plus UI:R correctly captures the practical gate: the malicious PHP must already be present on the host and a human/pipeline must actively run PHPCS over it with a triggering sniff. There is no EPSS score, no CISA KEV listing, and no public exploit code identified at time of analysis, so this is 'no public exploit identified' - do not treat it as actively exploited. The threat model is essentially supply-chain/CI: linting untrusted pull requests or third-party code. The eval() primitive is trivial to weaponize (AC:L, PR:N - no auth needed because the attacker only supplies the code being scanned), so despite the low prevalence of active exploitation, teams running PHPCS on attacker-controlled code in CI should prioritize the upgrade. Net: real priority for CI/lint-farm operators, lower urgency for teams that only lint their own trusted code.

An attacker opens a pull request (or publishes a package) containing PHP with a crafted array key such as ['system'('id') => 1]. A CI pipeline or developer runs PHPCS with PHPCSExtra's Universal.Arrays.DuplicateArrayKey or MixedArrayKeyTypes sniff, which calls getActualArrayKey(); the key is passed to eval() and the embedded command executes on the scanning host under the CI/developer's privileges. No proof-of-concept exploit is publicly available at time of analysis, but the malicious-key technique is described explicitly in the advisory.