Unpatched CVEs in dev linting tools, and phpcs unusable on PHP 8.5

[donnchawp]

This issue was generated by AI.

PHP Tests fails on the 8.2 and 8.3 matrix legs. 8.4 and 8.5 pass. No code change caused it, it started on its own.

Trunk's last run was green on 2026-07-27 at 5833e1e. I re-ran that same run today, same commit, nothing changed in between, and 8.2 and 8.3 both fail: https://github.com/Automattic/wp-super-cache/actions/runs/30265607855

What happens

composer install fails platform verification on 8.2 and 8.3, because composer.lock pins two packages that need PHP 8.4:

• doctrine/instantiator 2.1.0, requires php ^8.4
• symfony/string v8.0.8, requires php >=8.4

.github/workflows/php-tests.yml:29-30 then falls back to composer update, and that now refuses to resolve:

mediawiki/mediawiki-codesniffer v43.0.0 requires squizlabs/php_codesniffer 3.8.1
-> found squizlabs/php_codesniffer[3.8.1] but these were not loaded, because they
   are affected by security advisories ("PKSA-rdkp-vv9z-mjkg")

That advisory is CVE-2026-67434, OS command injection in PHP_CodeSniffer, affecting <3.13.6 and >=4.0.0,<4.0.2. It was published after our last green run, which is why a build with no commits behind it went red. Composer checks advisories against Packagist at resolve time, so this breaks retroactively.

8.4 and 8.5 pass because composer install succeeds there and the fallback never runs.

composer.lock has not been touched since a47179b on 2026-06-17.

Things I tried that do not work

Attempt	Result
config.platform.php: "8.2" on its own	automattic/jetpack-codesniffer ^4.0 hard-pins php_codesniffer 3.8.1, so it still will not resolve
Bump to jetpack-codesniffer ^5.0 or ^8.0	Lands on 3.10.3 and 3.13.5, both inside the advisory range
jetpack-codesniffer ^8.1 plus squizlabs/php_codesniffer ^3.13.6	Real conflict upstream. mediawiki-codesniffer v51.0.1 is the only one requiring the patched 3.13.6, and it pins phpcsstandards/phpcsextra 1.5.0 exactly, while wp-coding-standards/wpcs 3.4.1 and automattic/vipwpcs 3.1.0 both need ^1.5.1

The version chain that would give us a patched linter is knotted upstream in jetpack-codesniffer and mediawiki-codesniffer. There is no clean bump available today.

Options

Two ways out, and the choice needs a human because one of them means sitting on a CVE for a while.

1. Ignore the advisory, via policy.advisories.ignore-id in composer.json. PHP_CodeSniffer is a dev-only linter we run over our own code in CI, so the command injection risk here is about as low as it gets. Quickest unblock. Wants a comment saying why, and removing once upstream sorts itself out.
2. Regenerate composer.lock with config.platform.php set to 8.2, so the lock resolves for the lowest PHP we support. Then composer install works across the whole matrix and the composer update fallback never runs at all. This is the better fix, but producing the new lock needs one successful composer update, which the advisory currently blocks, so it probably needs option 1 temporarily anyway.

Option 2 with option 1 as scaffolding is probably the answer, but I would rather someone decided that than have an agent quietly pin around a CVE.

Also worth a look

Local phpcs is unusable on PHP 8.5. The vendored PHPCompatibility and PHPCSUtils sniffs throw deprecation errors and abort the run, on untouched files as much as changed ones:

An error occurred during processing; checking has been aborted.
The error message was: PHPCSUtils\BackCompat\Helper::getEncoding(): Implicitly marking
parameter $phpcsFile as nullable is deprecated

make lint reports clean when this happens, so it currently gives a false green locally. Running phpcs inside the wp-env container (PHP 8.3) works. Same lock refresh would probably fix this too.

[donnchawp]

This comment was generated by AI.

Reopening. I closed this by accident: #1083 said "Fixes #1082" at the top and "I left #1082 open for that" further down, which cannot both be true. The CI failure in the title is genuinely fixed, but two things in here are not, and they had nowhere else to live.

What #1083 actually did

Pinned config.platform.php to 8.2 and regenerated the lock, so composer install succeeds on every leg of the matrix and the advisory-blocked composer update fallback never runs. Trunk is green on all four PHP versions. No advisory was ignored or silenced.

Still to do: the two CVEs

squizlabs/php_codesniffer is still 3.8.1 in the lock. Nothing is patched, the failure just stopped being something CI trips over.

• CVE-2026-67434, OS command injection, squizlabs/php_codesniffer <3.13.6
• CVE-2026-45293, arbitrary code execution, high severity, wp-coding-standards/wpcs >=0.14.1,<3.4.1

Both are dev-only linting tools that never go into the plugin zip, so the exposure is a developer machine or a CI runner, not a site running WP Super Cache.

They cannot both be fixed today. mediawiki-codesniffer 51.0.1 is the only route to a patched php_codesniffer and it pins phpcsstandards/phpcsextra to exactly 1.5.0, while the patched wpcs 3.4.1 needs ^1.5.1. On top of that jetpack-codesniffer v8.1.1 constrains wpcs to >=3.0.0 <3.4.1, which excludes the fixed release outright.

So the trigger to watch for is a jetpack-codesniffer release that allows wpcs 3.4.1 alongside phpcsextra ^1.5.1. When that lands, bump and regenerate. Until then there is nothing to do here that is not a lie about our dependency graph.

Still to do: local phpcs is unusable on PHP 8.5

The lock refresh did not fix this, I checked rather than assumed. On PHP 8.5.9 today:

The error originated in the .PHPCompatibility. sniff on line 131.

The vendored PHPCompatibility and PHPCSUtils sniffs abort on every file, changed or not. make lint still exits 0 and prints nothing when this happens, so it reports clean while having checked nothing at all. That is the worse half of this, because a false green is more dangerous than a red one.

Running phpcs inside the wp-env container on PHP 8.3 works, and is what I have been doing. Same upstream bump would probably fix this too, since the newer PHPCompatibility releases are what carry the PHP 8.5 nullable-parameter fixes.

Worth noting the title of this issue now describes work that is done. Happy to retitle it to something like "Unpatched CVEs in dev linting tools, and phpcs unusable on PHP 8.5" if that reads better.