When the PHP2Shell news broke on October 21, I wasn’t thinking about the future of AI. I was thinking about our clients’ websites.

At Renderbit, we build and maintain applications for clients who expect them to work, including when something goes wrong in software neither they nor we wrote. The team spent the hours after the disclosure, and the stretch that followed, working around the clock to secure those sites.

There was no great mystery about our goal. We needed to understand the risk, deal with it on live systems, and be sure we hadn’t introduced a different problem in the process. The details were less simple. Each client has its own hosting setup, PHP version, dependencies, and tolerance for disruption. An urgent security update still has to be a safe update.

I’ve followed security stories for years. I even wrote about CloudBleed back in 2017. It’s different when you’re responsible for the systems in question. You stop reading the news as a spectator.

And I think PHP2Shell is worth writing about for a reason beyond the late nights it caused us. It offers a very practical glimpse of what software security may look like from here on.

The problem wasn’t in our code

PHP2Shell refers to two critical vulnerabilities, CVE-2026-109618 and CVE-2026-109619. They involve how PHP handles memory when a request fails at just the wrong point. Under certain conditions, an attacker could read sensitive data or run code on the server without signing in.

The unsettling part was that the flaws sat in PHP itself. You could have a well-maintained Laravel application or a WordPress site with carefully chosen plugins and still be at risk because of the runtime underneath it. Wiz demonstrated working attacks against popular content management systems, but the issue was not specific to those applications.

The PHP team released fixes in 8.2.35, 8.3.36, 8.4.27, and 8.5.12, and urged everyone running affected versions to update.

That looks straightforward when you read it in an advisory: upgrade PHP. In a live client environment, it raises a much longer list of questions. Which version is actually serving requests? Does the host manage it, or do we? What might break after an upgrade? Can we check the result quickly? What protection can we put in place while we work?

Those were the kinds of questions that made our response an around-the-clock job. It reinforced something I’ve learned from years of managing client infrastructure: knowing exactly what you run, and being able to change it safely, is a big part of security.

AI didn’t invent the bug. It changed what was possible.

The PHP Foundation’s account is fascinating. Signs of the underlying memory problem had surfaced during an audit in 2024. But nobody had proved a practical remote attack, and the possible fixes came with difficult trade-offs for PHP and its extensions.

This year, researchers working with AI showed how serious it could be. OpenAI credits security firm Calif with finding a critical flaw using GPT-5.6 Sol, while Wiz independently reported the vulnerabilities. Wiz says its team used Gemini 4 Argon, GPT-5.6 Sol, and its own tools to find, test, and adapt exploits.

I especially liked Calif researcher Ryan Austin’s account. He didn’t type a vague prompt asking a model to find every bug in PHP. He knew the history of older PHP memory-limit flaws, had a theory about where to look, and used AI to pursue it.

That is a much more interesting story than “AI found a zero-day.” A skilled researcher could ask more questions, try more ideas, and work through the failed attempts much faster. Something that had been too hard to exploit in practice became achievable.

The same advantage won’t belong only to the people reporting bugs responsibly.

The clock is getting shorter

Cloudflare CEO Matthew Prince shared some remarkable figures on X. Cloudflare saw thousands of PHP2Shell exploit attempts in the ten hours before the public announcement. The count rose to tens of thousands in the first 45 minutes afterward, hundreds of thousands within two hours, and millions by the time he posted.

Those are attempts, not millions of successful breaches. We should be careful about that distinction. Still, they show how quickly the internet reacts to a serious flaw. AWS even found an attempted exploit against a honeypot on October 17, four days before the public disclosure. AWS could not say how that actor got the information.

We cannot assume AI drove any particular attempt in those numbers. But we can see where this is going. AI can help someone read a patch, adapt a proof of concept, and test whether an attack works on a particular setup. It can make both discovery and exploitation less dependent on rare expertise and long stretches of manual work.

That is why the hours our team spent responding matter to me. When an advisory lands, a small firm cannot afford to spend the first day merely finding out what it operates. We need to be ready to act.

Thankfully, AI and automation can also help the other side. Cloudflare prepared WAF rules ahead of disclosure and introduced full transaction detection, which examines a request together with the server’s response. Prince said Cloudflare had to develop a new form of WAF protection for this case.

That protection bought operators time. It did not make the PHP fixes optional. One of the easiest lessons to forget in the middle of an incident is that a WAF rule and a patched server solve different parts of the problem.

Then came the Claude report

Six days later, on October 27, Anthropic published a report on an unreleased internal Claude research model. It was an extraordinary read. The team described five working chains of vulnerabilities:

• Chrome: Four flaws chained together to run code outside the browser sandbox. Anthropic says Google assigned and patched 62 reported CVEs by Chrome 156, including 13 sandbox escapes.
• Safari: A chain that bypassed the same-origin policy and let a malicious website read data from other sites. Apple patched the flaws, including in a relevant iOS and iPadOS update.
• Android: A way to extract data from a locked Pixel 9 by combining weaknesses in USB transfer and pairing checks.
• Windows: A network flaw that could remotely crash certain servers handling HTTP/3 traffic, fixed as CVE-2026-33096.
• Linux: A zero-click attack against an affected multipath TCP listener that could run commands as root, fixed as CVE-2026-98432.

The model was not named in that October report, and Anthropic did not describe a separate iOS exploit chain. Earlier in the year, Anthropic had announced Project Glasswing, saying Claude Mythos Preview had found thousands of previously unknown vulnerabilities across major operating systems and browsers. We shouldn’t assume the two reports used the same model.

What interests me is the ability to put several small mistakes together and produce a working attack. A single code scanner might identify a suspicious line. These systems can explore what that line makes possible, try an approach, and keep going when it fails.

That’s a capability I want defenders to have. It’s also a capability I don’t want to assume attackers will lack.

What those late nights taught us

I don’t want to turn our response at Renderbit into a heroic incident story. Securing client websites is part of the job, and much of it is painstaking, ordinary work. But the urgency of PHP2Shell made a few things harder to ignore.

First, security starts with an accurate picture of the systems we own. A list of repositories is not enough. We need to know which runtime is live, which infrastructure serves the application, which dependencies it uses, and who can safely change each part.

Second, a fix is not finished when a deployment reports success. We need to check the running version, the application behaviour, and the protections around it. We need a path back if an urgent change causes trouble. And we should practise that before we’re under pressure.

Third, layers matter. Cloudflare rules, restricted access, monitoring, backups, and tested recovery procedures can reduce the impact of a missed flaw. None removes the need for a proper patch. We should never mistake the presence of a security tool for proof that a system is secure.

Finally, AI should be part of how we defend software, not just a subject we discuss after the next alarming headline. I want us to use it to review code, inspect dependencies and configurations, search for related flaws, and test fixes. I also want a person to check the findings. The PHP Foundation has already described the burden of handling a flood of invalid and duplicate security reports. More alerts are useful only if we can tell which ones matter.

For a smaller engineering firm, this is both a challenge and an opportunity. We can’t put a large security team on every client account. But we can build repeatable checks, keep our infrastructure ready for urgent changes, and use capable tools to do more careful work with the team we have.

I am proud that our team put in the hours when PHP2Shell broke. I would also like the next response to demand fewer of them—not because we take the risk less seriously, but because we have improved what happens before the alert arrives.

I don’t think PHP2Shell will be the last disclosure that sends teams scrambling. In fact, I expect AI-assisted vulnerability research to make such discoveries far more common.

The best outcome isn’t that we get faster at staying up all night. It’s that we build and run software well enough to need fewer emergency nights in the first place.