Article guideContents, topics, tags, and RSS
It’s easy to look at PHP2Shell and think, “Well, good thing we’re using something else.” These are serious bugs in PHP, but I don’t think the rest of us should get too comfortable.
The way researchers used AI to find and investigate these bugs caught my attention. But I don't want that part of the story to obscure something more ordinary: critical security advisories keep arriving for other products too, and some vulnerabilities are already being exploited when they're disclosed. Whatever technology we use, we need to be ready to respond.
The bigger picture
On September 27, Citrix disclosed two critical NetScaler vulnerabilities, CVE-2026-88771 and CVE-2026-88772, that could allow remote code execution without authentication. CISA confirmed that both were already being exploited. For organizations exposing remote access through these appliances, investigating whether someone got in before the patch matters as much as updating the appliance.
On October 1, Fortinet disclosed CVE-2026-104286 in FortiMail. The flaw could let an unauthenticated attacker write arbitrary files on the underlying system, and active exploitation had been reported. Canada's Cyber Centre published an advisory identifying the affected versions and confirming its addition to CISA's known-exploited list.
Then, on October 14, Next.js released fixes for two critical remote code execution vulnerabilities: CVE-2026-96889 in the image optimisation pipeline on glibc-based Linux and GHSA-673q-mjm6-r5xr affecting App Router applications using Cache Components. These had specific conditions; the advisory didn't establish that either had been exploited in the wild.
On October 20, the day before the PHP fixes, CISA added six more vulnerabilities to its Known Exploited Vulnerabilities catalogue. These were not simply high-scoring CVEs. The additions were based on evidence of real exploitation.
That's a few weeks of security news across a JavaScript framework, remote access infrastructure, email security and several other products. It would be wrong to suggest AI discovered all these bugs, or that every critical CVE is already being exploited. But the frequency is worth paying attention to. We can't build our response around whichever vulnerability happens to make the biggest headline.
I think the more useful questions are whether we run the affected software, whether the vulnerable feature is exposed, whether attackers have been seen exploiting it, and how quickly we can act. That matters much more than whether the latest story happens to involve PHP.
The research and AI
On October 21, 2026, PHP released fixes for CVE-2026-109618 and CVE-2026-109619. These are serious bugs in PHP’s memory management and error handling. Under the right conditions, they let an attacker execute code on a server without logging in. The PHP Foundation’s account explains the release and the work behind it.
Calif investigated PHP as part of OpenAI’s Patch the Planet initiative. According to OpenAI’s write-up, the team used GPT-5.6 Sol to identify a critical flaw. PHP’s maintainers then led the work on the fixes and release, with help from researchers and infrastructure providers.
Calif researcher Ryan Austin used his knowledge of earlier PHP vulnerabilities to ask the agent what happens when memory operations are interrupted. It found a sequence where PHP updated internal state before the related data was fully initialised. An error at that point could leave the cleanup code using data that hadn’t been set up properly.
They then asked the model to turn the finding into reusable review instructions in a SKILL.md file. Searching for the same pattern led to another bug in session upload-progress handling.
In Calif’s technical write-up, Austin says the initial discovery didn’t need exclusive models or a special agent harness. His knowledge of PHP and the questions he asked mattered.
I can see a lot of value in that way of working: investigate a problem, write down what made it a problem, then use that knowledge to guide the next review.
Wiz describes a parallel investigation using Wiz Atlas, Gemini 4 Argon and GPT-5.6 Sol. The models helped find bugs, develop exploits and check patches. Getting the exploits working across different environments still needed testing and debugging, but the team says AI reduced the specialist effort involved.
Finding suspicious code and showing that it can actually be exploited are separate jobs. These accounts describe AI helping researchers with both, while people directed the work and checked the results.
There are things PHP needs to answer for here too. The Foundation acknowledges that signs of the underlying out-of-memory problem existed in 2024. Compatibility concerns, limited resources and stalled decisions delayed a fix. It calls that a structural failure. That deserves attention alongside the research.
We’ve also seen this kind of research outside PHP. Earlier this year, Anthropic reported that Claude Opus 4.6 found 22 Firefox vulnerabilities over two weeks. Mozilla classified 14 as high severity and credits the researchers and Claude in its security advisory.
Of course, choosing a different technology can improve security. Memory-safe implementations can eliminate particular classes of bugs, and that’s a good reason to consider them. CISA recommends looking at both our own software and its external dependencies. We should make those improvements and still have a plan for the vulnerabilities that remain.
Preparing for next time
If a critical bug turns up in something we run tomorrow, we should already know how we’re going to handle it. It could be an application dependency, a runtime or an appliance we barely think about until it needs an update. We shouldn't have to invent a new process every time.
We also need to look back further than the day an advisory was published. Amazon reported a PHP2Shell exploitation attempt on October 17, four days before public disclosure. The report doesn’t establish whether the early attempts would have succeeded against real systems or whether the attackers used AI. It does give us a reason to investigate earlier activity when responding. Getting a patch installed is only part of that work.
Here’s where I’d start:
- Know what we’re running. Keep track of runtimes, dependencies, versions and who looks after each service.
- Check whether we’re affected. Confirm the affected versions and configurations, how exposed the service is, and whether exploitation has been reported. Severity alone doesn’t tell us what to fix first.
- Get a fix out quickly. Prioritise actively exploited and exposed vulnerabilities. Have a process for urgent security updates and temporary mitigations, including who can approve them outside the normal release schedule.
- Check the result and investigate. Confirm the patched version is actually running and the service still works. Look for earlier suspicious activity and start incident response if there are signs of compromise.
- Keep people informed. Know who needs to update colleagues and customers, record the decisions and follow up on what needs improving.
Then we need to practise it. How long does it take to find the affected services, reach the right people and get an update deployed? I’d rather find out where we get stuck during an exercise than during a security incident.
Support the people fixing the bugs
There’s also a lot of work for the people receiving these reports. The PHP Foundation says the security team published 15 CVEs since July 1 while processing more than 100 reports that were invalid, duplicates or impossible to reproduce. Those numbers don’t tell us how many reports came from AI or give us an AI false-positive rate.
Every report still needs someone to look at it. For a valid finding, someone has to reproduce the bug, work out the impact, review a fix and check that it hasn’t broken something else. Finding bugs faster means we need people who have time to do that work too.
The response also needed coordination between maintainers, researchers and providers, as OpenAI describes. If our companies depend on these projects, helping fund their maintenance should be part of looking after our own systems.
So before making the next PHP joke, I’d take a look at how we’d handle a critical bug in our own stack. I want us to have an answer better than “we use something else.”
