PHP2Shell: How We Patched Every Site the Afternoon the Fix Landed

On 20 October, details of two critical flaws in PHP leaked ahead of schedule. By the next morning there was a working exploit, and it needed nothing more than a single anonymous web request. The bugs, now known as PHP2Shell (CVE-2026-109618 and CVE-2026-109619), live in the PHP engine itself, not in WordPress, Laravel or any plugin. Every PHP site serving web traffic was exposed, whether it ran PHP-FPM, Apache's mod_php or anything else. PHP rates them 9.2 out of 10; one research team scored one of them a perfect 10.

The PHP project published fixed versions on 21 October at 14:00 UTC. Cloudflare had already seen attack traffic against its customers, with attackers changing their payloads to slip past the filters. Sansec reported early attacks from 07:43 UTC, more than six hours before any fix existed.

This is what we did that day, and what we're changing because of it.

Release day, hour by hour (UTC)

Morning, before any fix existed. We checked every PHP runtime on the platform: which versions each site runs, which containers run background workers, and what our build pipeline would need to roll out a fix the moment one appeared. We confirmed we were exposed, like every PHP host on the internet, and got ready to rebuild.

13:43. PHP 8.5.12 was live for every site on PHP 8.5. We don't install PHP from distribution packages. We compile it ourselves from the official source, so as soon as the PHP project published the code we could build, test and roll out without waiting for anyone else.

14:20 and 14:28. PHP 8.3.36 and 8.4.27 were live on every site running those versions, and 8.2.35 was built and ready. Each PHP-FPM pool was restarted onto the new build, and we checked every site afterwards.

14:57. This is the part most write-ups skip. Patching the web server isn't enough if your background PHP is still old. Queue workers, schedulers and job runners execute PHP too, and on many servers they use the operating system's packaged PHP. On release day Ubuntu's packaged PHP still had no fix (and at the time of writing it still doesn't), and one popular third-party package repository had no update either. We found background workers in six containers on that packaged PHP and switched every one of them to our own patched build, keeping their configuration exactly as it was.

After the patches. Patching shuts the door; it doesn't tell you whether anyone walked through it while it was open. So we went through our logs from the leak onward. We looked for PHP worker crashes, out-of-memory errors (the bugs' trigger), server errors, new or modified PHP files in site directories, and unexpected processes running as a web user. Every check came back clean.

The community did well

Moments like this show the industry at its best. Researchers coordinated, the PHP security team shipped fixes for four release branches at once (with source backports for even older ones), and many organisations chose caution over convenience. BambooHR took its service offline in the US, Canada and Ireland. In the Netherlands, DigiD, MijnOverheid, the House of Representatives' website and the national cyber-security centre went offline as a precaution. As of this writing no successful break-in has been confirmed. That isn't luck; it's thousands of teams doing the boring, urgent work on the same afternoon.

Cloudflare deserves particular credit. They had protective firewall rules in place about nine hours before the flaws were officially disclosed, and turned them on for every customer, free plans included. Any site behind Cloudflare had a filter between it and the first wave of attacks while its owners waited for the patch.

Why we're not on Cloudflare, and what we're doing about it

We deliberately don't route our platform through a US-based proxy. "Your data stays in the EU" is a promise we make literally: veldhost itself and nearly every site we host are served straight from our own infrastructure in Germany, through our own nameservers. (A few customers have chosen to put their own domains behind Cloudflare, and those sites got Cloudflare's rules as well.) For everyone else, on a day like 21 October there was no third-party filter in front. Getting the real patch out fast was the protection, so we did that within hours of release.

We already run a hardened edge: known attack paths are blocked before they reach PHP, junk crawlers are turned away, login pages are rate-limited, and repeat probers are banned at the firewall automatically. PHP2Shell showed us the next step. We're extending that edge with a managed rule layer for every customer on the platform, so that when the next critical vulnerability lands we can push a targeted blocking rule to every site at once. You'd be protected from the first exploit attempt, hours before a patch exists and before you'd even need to read the news. You won't need a separate product, a plan upgrade or a setting to switch on.

Better logs, kept sensibly, read by machines

The other lesson is about what we can see. Our post-incident review was clean, but it could have been sharper. Our access logs didn't record some of the request details that would let us pick out exactly this kind of attack at a glance.

So we're expanding our logging to capture more about each request: what kind of request it was, how big it was, and how the server handled it. These logs will be kept for a sensible period, long enough to investigate properly but not forever, because logs about your visitors are personal data and we treat them that way. On top of that, we're putting automated agents to work reading those logs continuously, so unusual patterns are spotted and blocked as they happen rather than found in a review afterwards.

What you need to do

If you host with veldhost: nothing. Every site on our platform runs a fixed PHP version, and its background workers do too. If you'd like the details for your own site, ask us. We're happy to share them.

If you run PHP anywhere else:

• Update to 8.5.12, 8.4.27, 8.3.36 or 8.2.35 or later. PHP 8.1 and older get no official fix, so plan the upgrade.
• Check every PHP on the machine, not just the web server: command-line PHP, queue workers, cron jobs and schedulers.
• Don't assume your distribution or package repository has the fix yet. Check the actual installed version.
• After patching, look back through your logs from 20 October onward for crashes, out-of-memory errors and files you didn't put there.

Security incidents are never fully in anyone's control. What is in our control is how quickly we move, how thoroughly we check our own work, and how clearly we tell you about it. On 21 October we moved fast, and the work above should make the next response faster still.