Thank you

Thank you.

To the PHP security team and release managers. To the people who package PHP for Linux distributions and long-term support. To Ryan A at Calif, to Wiz, and to OpenAI's Codex Security team, especially Amy Burnett. To OSTIF, Quarkslab, Alpha-Omega, Anthropic and Germany's Sovereign Tech Agency. That's the PHP Foundation's own thank-you list, and we're borrowing it.1

Thank you, too, to the cloud providers who built protections overnight, the national cyber agencies who sent warnings, and the IT teams who took their own sites offline for a few hours to keep people safe.

Most of these people will never meet the folks they protected. PHP runs a big part of the web, including, in the Foundation's words, "government services, online stores, banks, media sites."1 If you've paid a bill or read the news online this month, some of their work may have been standing between you and a bad day.

Why say thank you in public? Because this time we got to watch the work.

The firefighters we rarely see

Picture a town that hears about fires all the time but almost never sees a firefighter. Then one week, after a big fire, the crews sit down and explain it. Here's where it started. Here's how the teams split the work. Here's what we saved, what we got wrong, and what equipment we still need.

That talk doesn't promise there will never be another fire. It does something better. It gives the town a reason to trust the fire department that's based on what it saw, not on what it was told.

In this story, the firefighters are the maintainers, researchers, cloud operators, agency staff and IT teams. One difference from most towns: many of these crews aren't paid by the public. Some are volunteers. We'll come back to that.

Reassurance says "don't worry." Accountability says "here's what happened, what we did, what worked, and what's still open." This response gave us the second kind.

We've seen this before. Log4Shell in 2021 drew a similar public, cross-border response.2 This is just the latest chance to see the crews up close.

What happened, in plain terms

In 2024, Germany's Sovereign Tech Agency paid for a security audit of PHP. OSTIF organized it and Quarkslab did it. While fixing one of Quarkslab's findings, a PHP core developer spotted the first signs of a deeper memory problem. An attack was "theorized, but no concrete vectors were found."1

The fixes weren't simple. Each option broke something: old code, speed, or many add-ons built by other people. So the fix stalled.

In 2026, the picture changed. On August 11, Ryan A at Calif reported a way to run code on a PHP server without logging in. OpenAI separately found the same root cause. Wiz and OpenAI then found more ways in.134

Now the hard choices couldn't wait. The PHP team picked fixes, tested them and gave Linux distributions and other packagers time to get ready. On October 21, PHP shipped emergency updates for four versions and told everyone to "update immediately."5

The technical details matter less here than the shape: a problem found, a problem proven, a fix chosen by people, and a release built so that others could act on it fast.

Coordination under pressure, not perfection

It didn't go smoothly. The Foundation says so itself.

The day before release, the bugs' public ID numbers leaked with the wrong date and the wrong severity score. They said 10.0. The real score was 9.2. That evening, Calif "mistakenly published a video," which was taken down but copied. Advice meant for critical infrastructure teams "may have leaked as well." The next morning, one distributor broke the embargo, the agreed quiet period, more than six hours early.1

So the team moved the release up a day. It couldn't move it up further, because distributors were still packaging the fix. A fix that works on the team's machines isn't yet a fix people can install.

The Foundation was blunt about the bigger miss, too: "We won't pretend otherwise: the delay was a structural failure, caused by both the security team's decision process and its lack of resources."1 The fix sat from 2024 to 2026. They're changing how they decide, moving from needing everyone to agree to a majority vote, and making sure leaders hear about stuck fixes sooner.

None of that is a reason to blame one person. It's what pressure looks like when many groups share one problem. The point isn't that the teamwork was seamless. It's that it held together anyway.

Conceptual overview of the roles described in this article. Lines show information sharing across overlapping work. Original diagram by Renaissance Solutions with Codex; CC0.

What we can actually say

It helps to separate a few different things, from mildest to most serious.

A patch exists.5 Cloudflare had firewall rules running about nine hours before public disclosure, on by default, free plans included.6 Germany's cyber agency, BSI, and the US cyber agency, CISA, sent warnings and said systems that couldn't be patched should come offline.78 In Germany, BSI says "countless websites" were briefly taken offline until they were patched. Hesse's state sites and the federal police site were among them, "purely as a precaution," and back by evening.910

Attacks were attempted early. On October 17, four days before disclosure, AWS saw an attempt on its decoy servers, though it says "it's unclear if any of these attempts would have succeeded."11 Cloudflare saw attack traffic on October 21.6 On October 22, BSI said it knew of no widespread successful attacks yet.7

Then some attacks worked. On October 26, CISA added both flaws to its list of vulnerabilities known to be exploited.8 By October 28, researchers had confirmed successful attacks on decoy servers set up to be easy targets.1213 One security firm reported that attackers also broke into firewalls at a real organization.14

So attacks were attempted, and some succeeded. We don't know how many, and we may never know how much harm was prevented. What we can say is that defenses showed up fast, and they may have kept things from being worse.

Observed events and publication dates are different kinds of milestones. Sources:

AWS, PHP, Cloudflare and Dream. Original timeline by Renaissance Solutions with Codex; CC0.

Why seeing the work builds trust

More and more public talk about technology is about AI: what it can do, what it gets wrong, and where it's headed. That talk can feel like hearing about fires without seeing anyone respond.

This incident shows something steadier. The Foundation's post names who found what, and when. It owns its delay. It even corrects a wrong score in public, which a press release rarely does. That invites people to check.

It also shows where AI fits. The Foundation thanks "Alpha-Omega, OpenAI, and Anthropic for giving the team access to their tools and funding some of the security work." In its words, "tools now find bugs faster than ever, for defenders and attackers alike." The team says it has published 15 security fixes since July 1 and sorted through more than 100 reports that turned out to be invalid, duplicates or impossible to reproduce.1

What stays human is the call. "AI helps the team validate reports and group reports sharing the same root cause, but a person makes every call and works on every patch."1 Tools are making bugs faster to find. Deciding what to do about them is still people's work.

Recognize the work, and the needs

Open source is a strength and a weak spot at the same time. Thousands of people can pitch in from anywhere. But a project that much of the web relies on can still run short on hands.

The Foundation says its security work "still depends on a small group of foundation-funded developers and a little volunteer help."1 That's the fire crew from earlier that isn't paid by the town.

Gratitude doesn't replace steady support, and it doesn't erase the two-year delay. It does let us be thankful for this response while helping to make the next one easier.

Showing up

The firefighters are visible now. The work isn't over. Teams are still patching, still investigating, and still handling a related, lower-risk issue through the normal release cycle.5

We don't know everything that happened during this incident. We may never know how many attacks succeeded or how much damage was prevented.

But we do know that people across organizations, industries, and national boundaries worked together to address a serious problem.

They didn't wait for perfect agreement. They didn't have unlimited resources. And they didn't get everything right.

They showed up, shared what they knew, made difficult decisions, and kept working.

That's worth recognizing.

Because trust in technology isn't built only by making systems more capable. It's also built by showing people what happens when those systems need help.

To everyone who helped protect the PHP ecosystem: thank you.

And to everyone still doing that work, often without recognition or the resources they need: we see you. Keep going.

Footnotes

  1. PHP Foundation, "Today's PHP security release and how we're strengthening PHP security," Oct 21, 2026. https://thephp.foundation/blog/2026/10/21/todays-php-security-release-and-how-were-strengthening-php-security/ ↩ ↩2 ↩3 ↩4 ↩5 ↩6 ↩7 ↩8 ↩9

  2. CISA, "Apache Log4j Vulnerability Guidance," 2021. https://www.cisa.gov/news-events/news/apache-log4j-vulnerability-guidance ↩

  3. Wiz, "PHP2Shell: PHP RCE," Oct 21, 2026. https://www.wiz.io/blog/php2shell-php-rce ↩

  4. OpenAI, "Coordinated disclosure of critical vulnerabilities," Oct 21, 2026. https://openai.com/index/coordinated-disclosure-of-critical-vulnerabilities/ ↩

  5. PHP.net news archive, Oct 21 and Oct 23, 2026. https://www.php.net/archive/2026.php ↩ ↩2 ↩3

  6. Cloudflare, "PHP vulnerabilities: WAF protection," Oct 21, 2026. https://blog.cloudflare.com/php-vulnerabilities-waf-protection/ ↩ ↩2

  7. BSI, Cybersicherheitswarnung 2026-297981-1032, v1.2, Update 2, Oct 22, 2026. https://www.bsi.bund.de/SharedDocs/Cybersicherheitswarnungen/DE/2026/2026-297981-1032.html ↩ ↩2

  8. CISA, "Critical Vulnerabilities in PHP Require Immediate Patching," Oct 21, 2026, revised Oct 26, 2026. https://www.cisa.gov/news-events/alerts/2026/10/21/critical-vulnerabilities-php-require-immediate-patching ↩ ↩2

  9. BSI, "PHP2Shell" situation page, accessed Oct 29, 2026. https://www.bsi.bund.de/DE/Themen/Unternehmen-und-Organisationen/Cyber-Sicherheitslage/Analysen-und-Prognosen/Threat-Intelligence/Krisen-Grosslagen/PHP2Shell/PHP2Shell_node.html ↩

  10. tagesschau.de / hr, "Sicherheitslücke: Zahlreiche Behörden-Webseiten in Hessen abgeschaltet," Oct 2026. https://www.tagesschau.de/inland/regional/hessen/hr-sicherheitsluecke-zahlreiche-behoerden-webseiten-in-hessen-abgeschaltet-100.html ↩

  11. AWS Security Blog, "Amazon threat intelligence identifies PHP2Shell exploitation prior to public disclosure in MadPot," Oct 2026. https://aws.amazon.com/blogs/security/amazon-threat-intelligence-identifies-php2shell-exploitation-prior-to-public-disclosure-in-madpot/ ↩

  12. Previdian, "PHP2Shell activity across the Previdian network," Oct 28, 2026. https://blog.previdian.com/php2shell-activity-across-previdian-network/ ↩

  13. Sysdig, "PHP2Shell: CVE-2026-109618 and CVE-2026-109619," updated Oct 28, 2026. https://www.sysdig.com/blog/php2shell-cve-2026-109618-and-cve-2026-109619-detecting-unauthenticated-remote-code-execution-in-php-core ↩

  14. Dream, "Chained PHP2Shell exploit roots 25 servers," Oct 26, 2026. https://dreamgroup.com/blog/chained-php2shell-exploit-roots-25-servers ↩