PHP 8.2.35 Tag Ships With an Expired Signing Key as RCE Warnings Circulate
Sergey Panteleev created the git tag php-8.2.35 in the official php/php-src repository on GitHub, pointing to commit 09a9f29. The tag message reads "Tag for php-8.2.35". The GitHub release page dates the tag 19 Oct at 07:30.
The tag is signed with Panteleev's GPG key (GNU Privacy Guard, the standard tool for cryptographic signatures on code), key ID 659A97C9CF2A795A. GitHub marks that key as expired, so the signature will show as verified only against a key that has since lapsed. The release page lists two assets.
The release sits alongside a separate set of security notices. The PHP 8 ChangeLog page on php.net carries a banner reading "Critical remote code execution vulnerabilities, update now." It lists a Version 8.5.12 entry dated 22 Oct 2026, which cites two advisories, GHSA-w8hw-w9fx-j79w and GHSA-6wmf-4rv5-p3rp. The entry describes them as avoiding state corruption via bailout, PHP's internal mechanism for abandoning execution after a fatal error. The page provides changelog tabs for PHP 8.5, 8.4, 8.3, 8.2, 8.1 and 8.0.
The Hacker News published an article titled "PHP2Shell: Two Unpatched Critical PHP RCE Flaws" in October 2026. Remote code execution (RCE) means an attacker can run their own code on a machine they do not control. The article reports that PHP has published no workaround for the two critical flaws. The article's title and the php.net banner describe the same class of problem.
Earlier in the autumn, Pantheon's release notes for September 2026 stated that PHP 8.2, 8.3, 8.4 and 8.5 had been updated to their latest security versions. Those notes include a high-severity issue in the SOAP extension, a PHP module for web-service messaging, tracked as CVE-2026-91765. Hosting providers and platform operators therefore had a record of security releases across all four supported branches before the latest tag and changelog entries appeared.
For operators, the practical sequence is straightforward to state but harder to execute. A tag is a pointer, not a binary (a compiled, ready-to-run program). Anyone deploying 8.2.35 has to build or pull the artifact, verify it against the expired key with an explicit trust decision, and confirm which advisories the build actually addresses. Teams running PHP 8.2 in production should not infer their exposure from a tag name alone, and should cross-check the changelog entries against the advisories themselves.
In my view, the signing detail deserves more attention than its prominence on the page suggests. An expired key on a release tag is a small operational irritant when the artifact is well understood, and a real problem when a remote code execution advisory is circulating and an engineer has to decide, under time pressure, whether a signature still means what it used to. Projects with a long release history tend to handle key rotation quietly, and the people who depend on that quiet are usually the ones who notice when it lapses.
The broader context here is a mature release pipeline doing its job under pressure. The open questions for the next few days are whether the workaround gap described by The Hacker News is closed by the 8.5.12 entry and the banner, and whether the PHP 8.2 line receives its own fix list that maps cleanly onto the advisories.
