On Wednesday 21 October 2026 the PHP project released emergency updates for two critical vulnerabilities in PHP itself, now known as PHP2Shell (CVE-2026-109618 and CVE-2026-109619). PHP is the programming language behind a large part of the web, from WordPress sites and web shops to custom applications built in Laravel. Through these flaws, an attacker could run their own code on the server without logging in.
If your website or application runs on PHP, this applied to you too. If we manage your environment, we took care of it for you on 21 October. This article explains what happened and exactly what we did.
In short
- On 21 October 2026, emergency updates were released for two critical flaws in PHP, together called PHP2Shell. Only an update of PHP itself fixes them.
- If we manage your website or application, this was taken care of on 21 October: sites temporarily put into maintenance as a precaution, servers updated, checked and brought back.
- Where the package source lagged behind, we built a patched PHP version ourselves from the official source code, until the official packages replace it.
- As our client, you do not need to do anything. If your environment is managed elsewhere, we are happy to take a look with you.
What was going on
On Tuesday 20 October, the PHP security team announced a release for the next day at 14:00 UTC for two critical vulnerabilities, both scored 9.2 out of 10. That same day, details were already circulating online, before there was a fix. According to security firm Sansec, Cloudflare reported the first attacks on the morning of 21 October, a few hours before the updates appeared.
The fix is in PHP 8.2.35, 8.3.36, 8.4.27 and 8.5.12. According to PHP, every installation that handles web requests is at risk, however PHP is connected to the web server. Both flaws sit in the way PHP manages memory and data between requests internally. That is what makes them so awkward: the attack happens before the application itself has run a single line of code. A security plugin or carefully written application code will not stop it. Only an update of PHP itself fixes it.
Why this flaw only surfaced now
The flaw is not new. According to Calif, the research firm that discovered it, the oldest vulnerable path goes back to PHP 5.4 from 2012. The bug had been in PHP for well over ten years. In 2024, a PHP developer had already seen the first signs of the underlying memory problem. No working attack route was found at the time, and the security team could not agree on a fix: every option had a drawback, from existing code that would stop working to changes in thousands of extensions. As a result, the work stalled for months. The PHP Foundation itself now calls that a structural failure, caused by the way decisions were made and by a shortage of people: the security work rests on a small group of paid developers and some volunteer help.
What changed the situation is AI. In August 2026, Calif found the flaw within a few days, using AI models that are available to everyone, and security firm Wiz found it independently as well. With a working attack on the table, the urgency was suddenly there. The PHP Foundation puts it plainly: tools now find bugs faster than ever, for defenders and attackers alike. Flaws that stayed hidden for years now surface sooner, and the pace at which software has to be updated goes up. We use AI every day in our own work; how we do that for organisations is described under AI implementation.
Why patching cannot happen everywhere at once
Once PHP publishes an update, it is not yet on your server. The PHP project ships source code; almost every server gets PHP through an intermediary: the Linux distribution, a package source, a hosting provider or a Docker image. Each link has to build, test and publish the new version, and on 21 October that did not happen equally fast everywhere. Distributions had received the fix in advance and some had packages ready quickly; other package sources followed hours later, the official Docker image for PHP only arrived in the early evening, and the hosting platform ServerPilot had no update that day, nor did a widely used source for Red Hat-style servers. Some distributions also apply the fix under an older version number, so the version number alone tells you nothing.
When the fix of 21 October became available per step; times are approximate.
“The patch is out” does not mean the patch is on your server.
What we did for our clients
Our maintenance systems keep track of which PHP versions run where and how PHP is installed. So after the announcement we immediately had a clear view of where we needed to be, and could work out per server by which route the update would arrive and which sites and applications depended on it.
Between the details leaking and an update being available, there was a window in which attacks were possible and a fix was missing. The UK’s NCSC advised organisations to consider taking systems offline that could not be fixed right away. We made that call per site: what is at stake if it goes wrong (customer data, payments, access to systems behind the site) and what does a few hours of downtime cost? On the morning of 21 October, when the first attacks were reported and the update was not yet out, we put almost all sites into maintenance mode as a precaution. The regular maintenance mode of WordPress or of an application does not help here, by the way: PHP has already processed the request before the application can show a maintenance page. Only a static page that the web server serves without PHP being involved offers protection, and that is what we did.
Where it made sense, we applied the temporary settings from PHP’s advisory. Our own website was in maintenance for a while too, with extra monitoring for suspicious processes, unexpected connections and changed files; the same trade-off applies to us.
As soon as the updates were available, we updated server by server, checked each one and only then brought the sites back. Where the package source lagged behind, we temporarily built a patched PHP version ourselves from the official source code. We verified that source code was authentic, and every build was reviewed before it went live. As soon as the official packages appear, they replace our own builds. PHP 7.4 and other versions that no longer receive updates get no fix at all. We either moved sites on such a version to a supported version or kept them offline until that is done.
Why maintenance made the difference
A flaw like this shows why maintenance is not an afterthought. If you know which versions run where, you can act within a day. If you first have to find out, you lose the hours that matter. The same goes for outdated versions: PHP 7.4 has had no updates since the end of 2022, and PHP 8.2 gets no more security updates after 31 December 2026. Outdated software is a risk that builds up quietly, just like an outdated integration. Planning an upgrade before you have to is cheaper than improvising when you must. For the clients this applies to, we include the upgrade to a supported PHP version in regular maintenance. Ongoing development and maintenance describes how we set that up.
If we manage your website or application, you do not need to do anything; if you still have questions about your own environment, we are happy to answer them. Is your environment managed elsewhere and are you not sure this was picked up? We are happy to take a look with you.