7 PHP2Shell Lessons From the Volunteer Who Saved the Internet

Before I get to the PHP2Shell lessons, some context. Most weeks, nobody outside a server room thinks about who builds the software running underneath their website. This week was different. PHP2Shell, a pair of critical bugs in the PHP engine, leaked before its fix was ready. Millions of exploit attempts followed within a day. And a big part of the reason the internet kept working was a man most developers had never heard of: Ondřej Surý, a volunteer in Czechia who has quietly packaged PHP for Debian and Ubuntu servers for more than 20 years.

I've been thinking about the PHP2Shell lessons ever since, because this story isn't really about one bug. It's about how fragile the foundations of our work are, and how few of us ever look at them. So instead of another "patch now" post, here are seven things I think every developer, freelancer and small agency should take away from it.

First, what actually happened

Here's the quick version for anyone who missed it.

PHP powers a huge share of the web. NDTV estimates roughly 70 percent of websites, including most WordPress sites. Two bugs, tracked as CVE-2026-109618 and CVE-2026-109619, could let an attacker run their own code on a PHP server without logging in. According to NDTV, they were found by researchers using a frontier AI model from OpenAI.

The PHP project was preparing a coordinated fix when details leaked online on October 20. Cloudflare CEO Matthew Prince shared what his network saw: thousands of exploit attempts in the 10 hours before the official announcement, tens of thousands in the 45 minutes after it, hundreds of thousands within two hours, and millions after that.

PHP released the fixes a day early, on October 21. But a fix in source code doesn't help most servers, because most servers don't compile PHP themselves. They install ready-made packages. That's where Surý came in. The PHP project had brought him in ahead of time, and on release day his repository (packages.sury.org, plus the Ubuntu PPA ppa:ondrej/php) shipped patched builds for every current PHP version. He then backported the fix all the way back to PHP 5.6, a version PHP stopped supporting in 2018.

He isn't employed by the PHP Foundation. His day job, as The Atlantic reported, is director of DNS engineering at the Internet Systems Consortium. The PHP work is done in his own time, funded by donations.

When asked about being called a hero, he said: "I feel a responsibility toward the users of the internet." He also pointed out that he doesn't run PHP on any of his own systems.

I wrote a fuller profile of him and his work on ByteMuni: Ondrej Sury, the volunteer who saved the internet from PHP2Shell. That's the story. Now, the PHP2Shell lessons I think matter most.

PHP2Shell lessons #1: You depend on people you've never thanked

Think about the last PHP or Laravel server you set up on Ubuntu. There's a good chance a tutorial told you to run sudo add-apt-repository ppa:ondrej/php. Most of us typed it, copied the next command and never thought about it again.

That one line meant trusting a single volunteer to build, test and ship the runtime under your entire application, for free, for years. It worked so well that it became invisible. That's the strange thing about good infrastructure: the better it works, the less anyone notices it.

There's a famous xkcd comic, #2347 "Dependency", showing all of modern digital infrastructure balanced on one tiny block maintained by "some random person in Nebraska." Reason's Eric Boehm pointed out this week that PHP2Shell made the joke real, except the random person lives in Czechia.

What to do: spend ten minutes listing what your stack actually depends on, beyond your composer.json or package.json. Who builds your PHP? Your Node.js? Your web server? Your Docker base images? You can't protect what you've never noticed.

Lesson 2: The fix isn't finished until it's installed

We tend to treat a security release as the end of the story: "PHP patched it." But a patch sitting on php.net protects nobody. It only matters once it's running on the actual server handling your traffic.

Matt Shumer put it well, in a line Reason quoted: it's like millions of buildings sharing the same broken lock. "The lock maker has sent out a fix, but every building owner has to install it themselves, and many haven't yet."

Surý's work closed most of that gap for Debian and Ubuntu users. On release day, patching became a normal apt upgrade instead of hours spent compiling from source while attacks were already underway. That last mile is where real-world security is won or lost.

What to do: after any security update, check the version your website is actually running, not just your terminal. php -v shows the command-line PHP, which can differ from the PHP-FPM or Apache module serving your pages. Check your hosting panel, or create a temporary phpinfo() page and delete it as soon as you've looked.

Lesson 3: Preparation beats panic

The part of Surý's interview that stayed with me most wasn't the heroics. It was how calm he was:

"I'm in the stage of my life where I was like, This is bad. It needs to be fixed. But it doesn't cause panic, at least for me. It did cause panic for a lot of people. But you know, it was more like, We have a situation, it needs to be solved, and this is how we do it. And I have time to properly prepare."

He was calm because he was ready. Much of his build process is automated, he'd been brought in early, and he had done this kind of work for two decades. When the leak brought everything forward by a day, he simply executed.

Compare that with how most teams handle an emergency patch: someone sees a tweet, logs into a server nobody has touched in a year, can't remember how PHP was installed, and starts guessing.

What to do: write a one-page "emergency update" note for each server or client site. Include how PHP was installed, where the config lives, how to restart it, and how to roll back. Write it on a calm day so you aren't writing it on a bad one.

Lesson 4: Old versions don't disappear; they get forgotten

Officially, PHP 5.6 and 7.x are dead. In reality, they're still running all over the internet: on a school's admissions portal, a small business's billing tool, a client site built years ago that "just works," or an internal dashboard nobody wants to touch.

Those were exactly the systems at greatest risk this week, because PHP itself doesn't patch end-of-life versions. Surý patched them anyway. NDTV described it as saving the small businesses, schools and systems "that would have been forgotten otherwise." His repository shipped backported fixes for PHP 8.1, 8.0, 7.4, 7.3, 7.2, 7.1 and 5.6.

That was generous, but it isn't a plan. You can't build your security on the hope that a volunteer will backport the next fix too.

What to do: if you run or manage anything on PHP older than 8.2, treat these PHP2Shell lessons as your warning shot. Install the backported fix now, read its changelog, and then put a real upgrade on the calendar. "We'll do it later" is how a server ends up on PHP 5.6 in 2026.

Lesson 5: Open source isn't free; someone else is paying

Surý didn't hold back on this. He said AI has sped up both attacks and defence, but the deeper problem is that infrastructure is taken for granted and underfunded. He said open-source work can feel like exploitation, and that he wants the companies that benefit most to pay for it.

Of all the PHP2Shell lessons, this one is the hardest to hear. Then something telling happened. Once his story spread, donations poured in. He said contributions in a single day roughly matched what he would normally receive in a year.

That's heartwarming and a little uncomfortable at the same time. It took a near-disaster for people to notice. Most maintainers never get that moment. They just keep working until they burn out or quietly stop.

What to do:

• If you earn money from PHP sites, even as a solo freelancer, set aside a small yearly amount for the projects you rely on. Even a modest sum adds up across thousands of developers.
• If you run an agency or company, make open-source support a line item in the budget, not an occasional act of goodwill.
• If money is tight, contribute in other ways: report bugs clearly, improve documentation, answer questions in forums, or simply say thank you. Maintainers hear far more complaints than thanks.

Lesson 6: AI is speeding everything up, on both sides

Some PHP2Shell lessons reach well beyond PHP. This one is part of a bigger pattern. AI helped find these bugs, and AI is also helping attackers exploit bugs faster than before. Reason cited CrowdStrike data showing "agentic intrusions," attacks run by autonomous or semi-autonomous AI, doubled from July to August and doubled again in September.

That changes the math for everyone. The window between a vulnerability becoming public and mass exploitation used to be measured in days or weeks. With PHP2Shell, it was measured in minutes.

Yet when it came down to it, the fix still reached real servers because a human had prepared, automated his workflow and cared enough to do it. As Reason put it, "In the war between AI hackers and AI defenders, it's still humans who are the heroes. At least for now."

What to do: automate your own boring security work. Turn on unattended security updates where it's safe, set up uptime and version monitoring, and subscribe to the security mailing lists of the runtimes you use. The less you depend on remembering, the faster you'll move when it counts.

Lesson 7: Check your bus factor, including your own

Surý made a throwaway comment that should worry every engineering team: "It would be a crazy day for me if I was on a boat in the middle of the Adriatic Sea. That could happen."

He was lucky the leak didn't land on his holiday. But plenty of projects, and plenty of companies, have a single person who knows how something critical works. Engineers call this the bus factor: how many people would need to disappear before things grind to a halt. For many teams, and many freelancers, the honest answer is one.

If you're a freelancer managing 20 client sites, you are the bus factor for all of them. If you fell sick during the next PHP2Shell, who would patch them?

What to do: document access and procedures for every system you manage, and keep them somewhere secure that a trusted colleague or the client can reach in an emergency. For your own upstream dependencies, prefer projects with more than one active maintainer, or a paid support option for anything business-critical.

A quick PHP2Shell checklist for freelancers and small agencies

If you manage PHP or WordPress sites for clients, here's how to turn these PHP2Shell lessons into action:

1. List every site and server you're responsible for, with its hosting type (shared, VPS, managed) and PHP version.
2. Shared or managed hosting: check that your host has patched. Most hosting panels show the PHP version, and many hosts have published PHP2Shell notices. If yours hasn't, ask them directly.
3. VPS on Debian or Ubuntu: run apt policy php8.3 (use your version) to see where your PHP comes from. If it's Surý's repository, run sudo apt update and sudo apt install --only-upgrade 'php*', then restart PHP-FPM or Apache.
4. Docker: rebuild your images with docker build --pull so you get the patched base image, then redeploy.
5. Old PHP (below 8.2): apply the backported fix now, then quote your clients for an upgrade. Use this incident to explain why it matters.
6. Confirm the web-facing PHP version for every site, not just php -v.
7. Write the one-page emergency note for each server while it's fresh in your mind.
8. Give something back to the projects that kept your clients safe this week.

For deeper technical detail, I've covered the bugs, the server patching steps and the attack data in separate posts on ByteMuni: the PHP2Shell explainer, the patching guide for PHP web servers, and the Docker rollout checks.

Final thought on the PHP2Shell lessons

It's easy to read a story like this, feel a moment of gratitude and move on. I'd rather it changed a few habits. Every time we type a command like add-apt-repository or composer require, we're trusting someone. Usually that trust is well placed. Ondřej Surý proved it this week.

But trust works both ways. If people like him are going to keep catching the internet when it falls, the least the rest of us can do is know their names, keep our own systems in order and help pay for the work. Those are the PHP2Shell lessons I'm taking with me, and I hope you will too.

Sources: ByteMuni: Ondrej Sury profile · NDTV · Reason · LinuxCompatible · xkcd #2347