PHP2Shell: the day the PHP world held its breath (and how we got through it)

Every so often, something drops that makes the whole industry stop what it’s doing. A couple of weeks ago, that was PHP.

What happened

On 20 October, word leaked on Hacker News that two critical remote code execution vulnerabilities in PHP were about to be disclosed. The PHP team confirmed it and promised emergency patches the next day. On Wednesday 21 October, they shipped 8.5.12, 8.4.27, 8.3.36 and 8.2.35, fixing CVE-2026-109618 and CVE-2026-109619 (since nicknamed “PHP2Shell”). Both scored 9.2 on CVSS, could be triggered by unauthenticated attackers, and were already being exploited before disclosure.

For a language running a huge chunk of the web, that’s about as bad as it gets.

Where we stand with PHP

Two years ago, our engineering team was almost entirely PHP. Since then we’ve shifted to building new services in Python, with some Next.js along the way. All that’s left on PHP now is a couple of older, legacy services, and they’ll eventually move to the new stack.

So PHP is only a small corner of what we run these days, but this one still landed on our doorstep.

The call

Around midday on the Wednesday, one of the team spotted the news on Hacker News and raised the alarm. It went up the chain quickly, and leadership made the call to take our PHP services offline until the patch was out. We look after sensitive information for our customers, and protecting it comes first, even when that means downtime.

We let the heads of each function know straight away, and they started putting contingency plans together so their teams could keep working through the afternoon. With the patch’s timing still uncertain and no idea how long we’d be down, that groundwork mattered.

Waiting, then planning

There’s not much you can do while waiting on an upstream patch, so after a bit of thumb-twiddling, we put the time to use. We formed a small PHP task force, two engineers per service, and planned exactly how we’d roll the fix out the moment it landed.

Waiting on everyone else

It quickly became clear we weren’t just waiting on PHP. The tools we rely on had to update first and then there were the Docker images we build on.

This is where it got fun. The Docker official images PR for the patched versions (#22541) turned into a live watch party. Developers from around the world piled in with “lgtm”, “gogogo” and Power Rangers references, until the maintainers had to lock the comments. Meanwhile, half the internet was refreshing Ondřej Surý’s PPA build page, the volunteer-run package source that a huge number of Ubuntu servers rely on for PHP.

It was a stressful day, but there was something genuinely lovely about watching a whole community rally around the same problem in real time.

What we took away

Learning the other side of the stack. As a Python engineer, I don’t often get into the PHP side of our world. This was a crash course in how those services are deployed, what they depend on, and how all the moving parts fit together.

Sometimes quieter is better. Early on, I found myself wondering why the BBC wasn’t covering it. On reflection, it made sense. Shining a bigger spotlight on an unpatched vulnerability doesn’t help anyone, and with AI making it easier than ever to turn a disclosure into a working exploit, the less noise before people could patch, the better.

Back up by the next morning. We had both services back up by the next business morning, within 18 hours. That wasn’t a night of coding like a mad woman. Most of the wait was on upstream tooling, so once we had done what we could, we got some rest and picked it back up fresh.

There was some luck with timing. The patch landed at 3pm UK time, on a day the whole team happened to be in the office. That made coordinating easy. But what if it had dropped in the middle of the night, or on a day we were all working from home? Would we have moved with the same speed?

There’s room to improve. We handled it well. Having a proper incident process in place, something like incident.io or clear playbooks for who does what, is the next step in our journey as a team.