PHP2Shell: a Timeline

Much has been written about the PHP2Shell vulnerabilities in recent days, and much more will be published in the coming weeks. My goal in this article is to provide a concrete timeline of key events, without passing judgement. I have my own thoughts on how things played out, but will reserve them for a future blog post.

PHP2Shell concerns two related vulnerabilities that could allow unauthenticated remote code execution in affected PHP deployments. The vulnerabilities were assigned CVE-2026-109618 and CVE-2026-109619, and fixes were released in PHP 8.2.35, 8.3.36, 8.4.27, and 8.5.12.

As a release manager, I was privy to some internal discussions, and as one of the release managers for PHP 8.5, I actually did some of the things discussed below (including tagging and creating tarballs for PHP 8.5.12). I have only included events and times that are verifiable with public information. This timeline is not exhaustive, but should cover the main points of interest, up to and including the public release of the fixes.

Discovery

• 2024.06.25: "security-audit-2024" tag was created in the php/php-src GitHub repository. This tag identified a specific commit during the PHP 8.4 development cycle that would be the basis of a security audit being performed by QuarksLab.¹
• 2024 (exact date unknown): While working to address an issue identified during that audit, a PHP developer "found the first signs of the [out of memory] problem behind CVE-2026-109618".²
• 2026.05.18: The PHP Foundation announced the creation of an "Ecosystem Security Team".³
• 2026.07.30: Calif began an audit of the PHP project as part of the Patch the Planet project.²
• 2026.08.01: Calif began the discovery of code paths that led to the remote code execution vulnerabilities.⁴
• 2026.08.11: Calif reported an unconditional remote code execution vulnerability with the same underlying cause as the out of memory issue found in 2024, followed by additional reports from other organizations.²

Mitigation

• 2026.08.11: Addressing the out of memory vulnerability became "the top priority for all of the PHP Foundation's team working on security."²
• 2026 (August - October): Security patches to address the vulnerability were created, tested, and prepared for release.

Releasing

All times given are in UTC.

Monday, 2026.10.19

• 07:30: tag for php-8.2.35 was created.⁵
• 07:38: tarballs for PHP 8.2.35 were created.⁶
• 14:00: tag for php-8.3.36 was created.⁵
• 14:13: tarballs for PHP 8.3.36 were created.⁶
• 14:44: tag for php-8.4.27 was created.⁵
• 14:53: tarballs for PHP 8.4.27 were created.⁶
• 17:04: tag for php-8.5.12 was created.⁵
• 17:19: tarballs for PHP 8.5.12 were created.⁶

The tags and tarballs created on Monday were not published to public GitHub repositories until Wednesday, as discussed below. On Monday, the code for the releases was settled, but the tags were not pushed to php/php-src, nor were the tarballs uploaded to php/web-php-distributions.

As I have previously written, PHP releases are normally tagged on Tuesdays; creating the tags on Monday was unusual. The decision not to make the tags public at the time was also inconsistent with the existing documentation for the release process; a pull request is open to align the documentation with the new practice.

At the time these tags were created, the releases were still expected to be made public on Thursday (in line with PHP's normal release schedule). The date is evident from the dates in the NEWS files for each release. The coordinated releases were originally scheduled for 14:00 UTC on Thursday, October 22.²

Tuesday, 2026.10.20

• ~15:00: online discussion of the two CVE IDs (CVE-2026-109618 and CVE-2026-109619) was noted, though with some incorrect details. In response to the discussion, the release was rescheduled from 14:00 UTC on Thursday, October 22, to Wednesday, October 21, at the same time.²
• 19:25: the php/web-php repository on GitHub was updated to include a pre-release announcement for the upcoming security releases. That repository controls the news items shown on php.net, and is periodically synced to the live website.⁷
• 19:33: the PHP security team announces on the php-announce mailing list that a security release will be made public the following day.⁸ The announcement was also made in a few other places around the same time.
• ~20:00: Calif published a video with a proof of concept; the video was later deleted, but not before being copied.²
• 20:27: a copy of that video was published and remains online.⁹

Wednesday, 2026.10.21

• Morning (exact time unknown): Chainguard published patched versions of PHP 8.2, 8.3, 8.4, and 8.5. The PHP Foundation reports that Chainguard unilaterally broke embargo at 07:41,² while reports on Hacker News suggest that the patched builds were available at least since 06:07.¹⁰
• 13:31: the php/web-php-distributions repository was updated with the tarballs for PHP 8.2.35, 8.3.36, 8.4.27, and 8.5.12.¹¹
• 13:33: the php/web-php repository was updated with release announcements for the four new versions, along with an overall security announcement explaining the issue and how to upgrade, including the fact that source-only backports have been created for PHP 7.4, PHP 8.0, and PHP 8.1.¹² The php.net website was shortly thereafter synced to include the announcements.
• 13:34: the GitHub advisories ("RCE via stale global state" and "RCE via OOM corruption") for the vulnerabilities were published.¹³
• 13:35: the php/php-src repository was updated with:¹⁴
  • A new PHP-7.4-CVE-2026-109618-109619 branch that includes the fixes, backported for PHP 7.4
  • A new PHP-8.0-CVE-2026-109618-109619 branch that includes the fixes, backported for PHP 8.0
  • A new PHP-8.1-CVE-2026-109618-109619 branch that includes the fixes, backported for PHP 8.1
  • A new PHP-8.2.35 branch that includes the fixes
  • A new PHP-8.3.36 branch that includes the fixes
  • An updated PHP-8.4.27 branch that includes the fixes
  • An updated PHP-8.5.12 branch that includes the fixes

PHP 8.4 and 8.5 are actively maintained, while PHP 8.2 and 8.3 continue to receive security fixes. PHP 8.1 and older branches are no longer supported, although due to the severity of these issues, minimal backports were published.

GitHub does not appear to publicize when the git tags with the fixes were pushed to GitHub. GitHub reports that the GPG signatures on those tags were all verified at 13:35 the same day, so they must have been on GitHub by then. Git does have the functionality to push both branches and tags to a repository (e.g. from a local machine to GitHub) in an atomic operation, so it is possible that the tags were pushed to GitHub at 13:35 in the same operation that pushed the branches, but no public record establishes that this was the case.

Deployment

Fixes to the vulnerabilities were confidentially shared with multiple vendors under embargo before the public release yesterday, giving those organizations the opportunity to deploy fixes to the sites under their control before the vulnerabilities were made public.

Administrators of other websites that run on PHP should upgrade immediately if they have not already done so. Upgrading is the only complete solution to these vulnerabilities. See the advisory on php.net for more information.