The two latest vulnerabilities in PHP, CVE-2026-109618 and CVE-2026-109619, have reached mainstream news, so I think it's safe to say that almost everyone will have heard of it.
This seems to be an unprecedented issue, mostly due an early breach of an embargo and the ensuing scramble to understand what is happening. With this post, I wanted to try and assemble a chronological timeline of how PHP2Shell came to be. It probably won't be entirely correct and a lot of things overlapped with one another, but if you see any glaring errors, let me know.
2026-10-20 17:20 UTC+2
A leak on Hacker News discloses that two new CVEs will be published for PHP shortly, naming both as CVSS 10.0 vulnerabilities that allow unauthenticated RCE. The post gets flagged and deleted shortly afterwards.
2026-10-20 18:39 UTC+2
GossiTheDog picks up on this on Mastodon, which spreads awareness of the upcoming vulnerability.
2026-10-20 20:33 UTC+2
CERT-EU publishes an advisory highlighting the upcoming security release. They explicitly advise organisations to take their websites offline if they're unable to patch (which, at this point, was everyone as a fix had not yet been released).
As far as I'm aware, CERT-EU also proactively reached out to larger orgs (governments in particular) to notify them of this vulnerability.
2026-10-20 21:45 UTC+2
The PHP maintainers release a notice about an upcoming security release, evidently ahead of schedule due to the increased chatter about this vulnerability and the preceding leak on Hacker News.
2026-10-21 00:14 UTC+2
An exploit video from Calif circulates, showing unauthenticated RCE against a recent WordPress instance.
2026-10-21 5:00 UTC+2
Cloudflare starts deploying custom WAF rules to protect against the vulnerability. From the looks of it, this was a bit of a whack-a-mole game as new attack vectors kept popping up (as per Dane Knecht on X).
2026-10-21 8:00 UTC+2
Various mitigations like session.upload_progress.enabled = Off or disabling multipart/form-data uploads entirely start circulating. Maintainers on both X and Reddit deny that this helps mitigate every case and instead recommend turning off systems entirely.
2026-10-21 9:00 UTC+2
Larger news sites like Golem (in German) and Reuters pick up on the PHP vulnerability.
2026-10-21 10:43 UTC+2
Various proof of concepts purporting to show the exploit start popping up, like these two. However, there's ultimately a lot of confusion as to what's actually vulnerable and what isn't. Some people report that the posted PoCs ultimately don't work at all or only partially.
2026-10-21 11:00 UTC+2
Organisations start taking their websites offline from the morning to help protect against any possible attacks, as it's still unclear what exactly is causing the vulnerability. This lasts until 3 pm patch time, as more and more organisations (including a large part of the Dutch Gov't) start taking down websites.
2026-10-21 15:40 UTC+2
Shortly before the announced release, GitHub Security Advisories appear that detail the vulnerabilities. They clearly show that the previously discussed, albeit unofficial, mitigations do not prevent either RCE from being exploited. Pages that are still up as binary patches get released are bound to be vulnerable.
2026-10-21 17:40 UTC+2
PHP pushes new images with fixed versions to Docker Hub. Downstream tools like Nextcloud are still in the process of building new releases.
Patches will no doubt still take some time to roll out over the next few hours, so if you have a PHP application (whether that's Wordpress, Nextcloud or similar), it's advised to keep them offline. Also, patches are only being provided for PHP 8, meaning those on PHP 7 or below will have to upgrade to PHP 8 fast or keep their websites offline longer.
I expect that this will carry on for quite some time, though maybe we're lucky this time and quite a lot more people are updating their boxes to the latest PHP 8 because of the large media coverage.