Skip to content

Perspectives

When AI finds the weakness: what PHP2Shell tells us about the future of cybersecurity

AI is changing the economics of finding and exploiting software flaws. The harder question is whether our ability to fix what it finds can keep pace.

· AI, Cybersecurity, Delivery

A vulnerability that had been hiding in plain sight

In October 2026, cybersecurity researchers disclosed two critical vulnerabilities in PHP, one of the technologies underpinning a significant proportion of the web.

The vulnerabilities, collectively known as PHP2Shell, could allow an attacker with no account or login to run code on affected servers, or to read sensitive data such as passwords and access keys held in server memory. Researchers demonstrated exploitation against widely used platforms including WordPress, Drupal and Joomla.

What makes this story particularly interesting is not simply the severity of the flaws. It is the role that artificial intelligence played in finding and exploiting them.

According to Wiz Research, the underlying weaknesses had existed for more than a decade. Turning them into practical exploits required a complex sequence of technical steps, including reasoning about memory corruption, adapting techniques to different environments, and repeatedly testing and debugging the results.

AI helped make that process considerably more practical.

This is an important distinction. AI did not create the vulnerabilities, and the work was not completed by a model acting independently. Researchers used frontier AI models alongside specialist knowledge, testing tools and human validation.

Wiz says frontier models were critical to making the work practical, and that a single researcher completed in a week what would previously have taken a world-class team months.

The picture is not entirely one-sided, though. One of the other researchers credited with finding the flaws has written that the discovery relied on his own experience of the software and its history of vulnerabilities, with no special tools or model access beyond what is publicly available. That is a useful reminder that the most effective results still come from people who know where to look, using AI to go further and faster.

Even so, the case demonstrates something significant: AI can help bridge the gap between identifying a potential weakness in software and proving that it can be exploited in the real world.

Why was it found now?

If the flaws had been in PHP for more than a decade, why did they come to light in 2026?

Part of the answer is that noticing a bug and proving it is dangerous are very different things. One of the flaws had in fact been spotted by a core PHP developer in 2024, during work on PHP's first external security audit. Someone suspected it might be exploitable, but nobody found a concrete way to do it. The small security team drafted several competing fixes, each with a cost, and the work stalled. The PHP Foundation later described the delay as a structural failure, caused by both its decision process and its lack of resources.

That points to the real barrier. What kept these flaws harmless for years was not that nobody could see them. It was the cost of showing that they could be turned into a working attack.

Three things changed that. Two separate teams, at Wiz and Calif, found flaws independently within weeks of each other in August 2026, which suggests a shift in the tools and attention being applied rather than one lucky discovery. Programmes such as OpenAI's Patch the Planet are now directing researchers, equipped with AI, at the foundational open-source software that much of the internet depends on. And AI lowered the effort needed to turn a suspicion into proof, which is exactly the step that had previously stalled.

There is also an uncomfortable resourcing point. PHP underpins a large share of the web, yet its foundation has one full-time employee and around fourteen mostly part-time contractors. Critical shared infrastructure is often maintained by very small teams.

From finding bugs to making them exploitable

Software vulnerabilities are nothing new. Developers and security researchers have spent decades identifying flaws in operating systems, web applications, libraries and the infrastructure connecting them.

The challenge is that not all vulnerabilities are equally easy to exploit.

A scanner might identify suspicious code or flag a potentially unsafe operation. Establishing whether that weakness can be exploited remotely, without authentication, is a different problem altogether.

In the PHP2Shell investigation, researchers had to work through complex interactions involving memory management and internal program state. The challenge was not just finding an individual defect, but understanding how several conditions could be combined to produce a reliable exploit.

AI-assisted analysis helped researchers work through this complexity, test hypotheses, debug failures and adapt techniques across different application environments.

Wiz reports that frontier models substantially reduced the specialist effort needed to develop and adapt the exploits.

The significance is therefore not that AI can find a bug. It is that AI can reduce the time and expertise required to turn certain difficult-to-exploit bugs into practical attacks.

That changes the economics of cybersecurity.

If an attack previously required a highly specialised team and considerable time, it might not have been commercially attractive or operationally feasible for many attackers. If AI reduces that barrier, a larger set of vulnerabilities could become realistic targets.

The same change creates an opportunity for defenders. Security researchers can investigate more code, test more hypotheses and uncover weaknesses that might otherwise have remained undiscovered.

The technology is not inherently defensive or offensive. Its impact depends on who uses it, what access they have and how quickly the surrounding systems respond.

The uncomfortable duality of AI security

There is an obvious tension here.

The capabilities that help defenders uncover vulnerabilities can also help attackers analyse software, adapt exploit techniques and automate parts of an attack.

This is why I think it is too simplistic to describe AI as either a cybersecurity solution or a cybersecurity threat. It can be both.

For defenders, AI offers the possibility of extending the reach of security teams that are already under pressure. It may help them investigate complex codebases, identify patterns, assess potential vulnerabilities and prioritise remediation.

For attackers, similar capabilities could lower the barrier to conducting sophisticated technical work.

This does not mean that every organisation suddenly faces an equally capable attacker, or that AI can reliably exploit every vulnerability it identifies. Access to suitable models, technical knowledge, infrastructure and the ability to validate results still matter.

Nor does one case prove that AI will consistently outperform experienced security researchers.

What it does show is that some tasks which were previously difficult enough to limit practical exploitation can become more accessible with AI assistance.

That is a shift worth taking seriously.

Discovery is only half the problem

Perhaps the most important part of the PHP2Shell story comes after the vulnerability was found.

PHP is not a single website or a single product. It is a foundational technology used by a vast ecosystem of applications, hosting providers and infrastructure services.

A vulnerability in the underlying runtime can affect systems even when the application code running on top of it is not itself defective.

Once a flaw of this kind is discovered, several things must happen. Researchers need to validate the finding and disclose it responsibly. Maintainers must develop and test a fix. Hosting providers and security vendors may need to prepare mitigations. Organisations then have to identify affected systems, assess their exposure and deploy the appropriate updates.

Each step takes time, and different organisations have different levels of technical capability.

In this case, the response involved collaboration between Wiz, OpenAI, Calif, the PHP maintainers and infrastructure and security providers. PHP released patched versions on 21 October 2026.

Even this carefully coordinated effort did not fully hold. Details leaked the day before the planned release, and security firms reported attack attempts in the hours before the patches were published. Amazon reported a targeting attempt as early as 17 October.

OpenAI described the approach as part of its Patch the Planet initiative, arguing that coordinated preparation can give defenders an opportunity to protect systems before full technical details become public.

This is an important model for responding to vulnerabilities with potentially widespread consequences.

However, coordination before disclosure is only one part of the solution. The work does not end when a patch becomes available. It ends when affected systems have been identified, updated or adequately mitigated, and organisations have confidence that their exposure has been addressed.

That is a much harder operational challenge.

What happens if vulnerability discovery accelerates?

Imagine a future in which AI systems can routinely investigate large codebases and identify complex vulnerabilities at a fraction of today's cost.

That could be a major benefit for security. More weaknesses could be found before attackers discover them, and organisations could improve the quality of their software.

But it could also create a capacity problem.

Security teams already have to prioritise vulnerabilities based on factors such as severity, exploitability, exposure and the value of the affected assets. They cannot treat every finding as an emergency.

If AI dramatically increases the volume of reported weaknesses, organisations may face a growing backlog of findings requiring investigation. Some will be false positives. Some will be theoretical. Others will require urgent remediation.

The challenge will be to distinguish between them quickly and accurately.

This creates three areas where organisations may need to adapt.

1. Vulnerability management needs to become more dynamic.

A periodic scan followed by a long remediation cycle may be insufficient for high-impact vulnerabilities when the time required to develop an exploit is falling. Organisations will need better visibility of their software dependencies, more effective prioritisation and clear processes for emergency patching.

2. Secure software development needs to improve at the source.

Finding weaknesses after software has been deployed is useful, but preventing them in the first place is better. AI-assisted testing should be combined with secure coding practices, memory-safe technologies where appropriate, code review and formal verification for systems where the risk justifies it.

3. Incident response needs to account for faster-moving threats.

Organisations should consider whether their monitoring, escalation and response procedures are equipped to handle vulnerabilities that move rapidly from discovery to exploitation. That includes knowing who is responsible for decisions, how emergency changes are approved and how recovery would work if a system were compromised.

These are not entirely new requirements. AI changes the urgency and potentially the scale at which they need to operate.

What has happened since disclosure

In the days after the patches were released, the story moved quickly from research to real-world attacks, which is exactly the gap this article is about.

  • Exploitation was confirmed. On 26 October, the US Cybersecurity and Infrastructure Security Agency added both flaws to its catalogue of vulnerabilities known to be exploited in the wild.
  • Exploit code became public. Proof-of-concept code circulated within days. Sophos reported attempts to install a likely variant of the Mirai botnet, which its controls blocked.
  • Targeted intrusions followed. Researchers at Dream reported that an attacker combined PHP2Shell with a Linux flaw to take full control of 25 servers, including firewalls and systems in a US government-affiliated environment, observed on 25 October. They tentatively attributed the activity to a China-linked actor, and noted artefacts of AI tooling among the attacker's kit.
  • The patching gap is large. Internet scans reported millions of exposed PHP services, and one estimate found that around four in five of those revealing a version number were running branches that no longer receive official updates. For PHP 7.4, 8.0 and 8.1, no official release was published at all; fixes are available only as source code or from distribution and long-term support vendors.

That last point matters most. A patch existing is not the same as systems being patched, and some of the most exposed systems are the ones least likely to be updated quickly.

Why secure-by-design still matters

There is a risk that the response to AI-assisted vulnerability discovery becomes a race to deploy more AI tools.

That would be an incomplete answer.

AI can help identify and explain defects, but it cannot compensate for every weakness in an organisation's engineering practices. Nor does automated analysis remove the need for independent validation, sound architecture or disciplined change management.

The PHP vulnerabilities involved problems with memory safety and internal state. They illustrate why the design of software and the assumptions built into it matter over the long term.

Where appropriate, memory-safe programming languages can eliminate entire classes of memory-safety defects. Strong isolation can limit the consequences of a compromise. Formal methods and rigorous testing can help establish that critical components behave as intended.

None of these measures guarantees security. But they can reduce the number of defects that need to be discovered and patched later.

The goal should not be to create an endless cycle in which AI finds vulnerabilities and humans race to fix them. It should be to use AI to improve the security of the entire software lifecycle, from design and development to testing, deployment and maintenance.

The wider lesson for organisations adopting AI

For me, the most interesting lesson from PHP2Shell extends beyond cybersecurity.

We often evaluate new technology by asking what it can do, how quickly it can do it and how much it can save us. We spend less time considering whether the systems around it are ready to respond to the consequences.

AI-assisted vulnerability discovery is a clear example.

The capability to identify a weakness is valuable. But its practical value depends on the ability to validate the finding, understand its significance, coordinate a response and implement a fix.

The same principle applies to AI in other areas of business. Faster analysis does not automatically produce better decisions. More automation does not automatically create a more resilient operation. Increasing the speed of one part of a process can expose bottlenecks elsewhere.

In cybersecurity, the consequences can be especially serious because the technology is being used by both defenders and attackers.

The organisations best positioned to benefit from AI may not simply be those with access to the most capable models. They may be those that can connect those capabilities to reliable processes, clear accountability and the ability to act quickly.

A turning point, but not the end of the story

It would be premature to conclude from one disclosure that AI has fundamentally transformed every aspect of cybersecurity. The longer-term balance between defenders and attackers remains uncertain, and the results achieved in this investigation will not necessarily generalise to every type of vulnerability.

But PHP2Shell provides a concrete example of how frontier AI can help turn longstanding, complex software weaknesses into practical exploits.

That is significant in its own right.

The opportunity is to use the same capabilities to make software more secure, identify defects earlier and help organisations respond before vulnerabilities are widely exploited.

The risk is that discovery accelerates while remediation remains constrained by legacy systems, fragmented ownership and slow operational processes.

The question is no longer simply whether AI can find more vulnerabilities.

It is whether we can build the engineering practices, response systems and institutional coordination needed to keep pace with what AI makes possible.

That may prove to be one of the defining challenges of cybersecurity in the years ahead.


Sources and further reading

  1. Wiz Research — PHP2Shell: AI uncovers critical RCE vulnerabilities: technical findings, exploit development and coordinated disclosure.
  2. OpenAI — Patch the Planet: AI-assisted discovery and coordinated response.
  3. PHP — official release information: security releases and remediation.
  4. watchTowr — PHP2Shell: CVE-2026-109618 and CVE-2026-109619: affected versions, configurations and remediation steps.
  5. Recorded Future — PHP2Shell exploitation explained: timeline and internet exposure figures.
  6. The Next Web — PHP knew about one of the flaws in 2024 but could not agree a fix.
  7. Reuters, via The Kathmandu Post — PHP Foundation "under-funded" with one full-time staff member.
  8. The Hacker News — CISA confirms active exploitation of two PHP2Shell flaws.
  9. The Hacker News — PHP2Shell attack roots 25 servers.
  10. Cybersecurity News — PHP2Shell exploit code goes public.
  11. NHS England Digital — PHP2Shell security alert: affected versions and remediation guidance.

This article is an independent analysis of the publicly disclosed research and its broader implications. It is not a technical vulnerability assessment or a substitute for vendor security guidance.