AI vulnerability discovery: software flaws are now found faster than teams can patch them

AI vulnerability discovery illustrated by a series of falling concrete blocks representing rapidly identified software flaws, while engineers work to patch vulnerabilities.

AI vulnerability discovery has changed the arithmetic of software security. Flaws are now being found faster than the teams responsible for the software can patch them.

On 21 October, PHP shipped an emergency release to fix two critical remote code execution flaws that researchers found with the help of AI models. A day later, Anthropic showed Claude being used to formally verify security properties across 123 open-source libraries. AI security testing now cuts both ways: the same models that help defenders prove code safe help attackers find a way in.

The PHP release came with OpenAI's account of how it coordinated the disclosure. Anthropic published its formal verification research on 22 October, and on 23 October Sam Altman was reported as saying he no longer thinks "we're going to be able to just patch all the bugs".

Our argument is that AI-assisted secure development, an inventory of open-source dependencies and faster patching are no longer optional extras. A bespoke development partner should provide them as standard.

This article is for CTOs, engineering leads and boards. It covers what happened with PHP, the defensive uses of AI code review and formal verification, dependency hygiene and patch SLAs, and the questions to ask your development partner.

What happened with PHP

PHP is one of the most widely used languages on the web. Wiz estimates it powers about 70% of websites, including those built on WordPress, Drupal and Joomla. A critical flaw in PHP itself is therefore a flaw in a large share of the internet.

Two critical flaws, found with AI

The PHP Foundation's release note describes two flaws in how PHP handles memory and errors. The first, CVE-2026-109618, lets memory become corrupted when a request hits PHP's memory limit at the wrong moment. The second, CVE-2026-109619, lets a later request reuse memory freed by an earlier one. Under the right conditions, both allow an attacker with no login to run their own code on the server. Both are rated 9.2.

Calif began auditing PHP on 30 July under OpenAI's Patch the Planet programme and reported a remote code execution flaw on 11 August. OpenAI says Calif found it using GPT-5.6 Sol. Wiz reported on 24 August, and according to The Neuron, "Wiz reports using its Atlas system alongside Google Gemini 4 Argon and OpenAI GPT-5.6 Sol during the investigation." Wiz demonstrated attacks against vulnerable WordPress, Drupal and Joomla deployments.

A weakness first seen in 2024

The memory-limit problem was not new. The PHP Foundation says it first surfaced during a 2024 external audit by Quarkslab, and that the fix then stalled for months over competing approaches. AI-assisted research turned a known weakness into a demonstrated attack. The bottleneck was never finding the flaw. It was fixing it.

The workload is growing. Since 1 July, the Foundation's security team has published 15 CVEs and worked through more than 100 reports that were invalid, duplicated or could not be reproduced.

A coordinated disclosure that leaked

OpenAI spent two months coordinating the response with PHP's maintainers, researchers and security providers, and published a five-stage framework for coordinated disclosure alongside the release. The plan did not hold. According to the PHP Foundation:

  • On 20 October, the CVE numbers leaked online with the wrong release time and a wrong severity score of 10.
  • The release was brought forward from 22 October to 21 October at 14:00 UTC.
  • Calif mistakenly published a video of its proof of concept. It was deleted, but copies spread and sped up proof-of-concept development.
  • Chainguard published fixed images more than six hours before the coordinated release.

The Foundation reported no working exploits at the time of release. OpenAI says that, to its knowledge, frontier AI found these flaws before attackers did, but warns that AI "can also help attackers rapidly develop offensive tools and exploits", and expects "similar findings to increase sharply in the coming months." The AI news site dentro.de summed up the episode as "a crisis both discovered and amplified by AI".

What to do now

If any of your systems run PHP, update to 8.5.12, 8.4.27, 8.3.36 or 8.2.35, depending on your branch. That includes servers, containers and hosting you do not manage directly. The PHP Foundation's advice is that it is "imperative that you update now".

Defensive uses: AI code review and formal verification

The capability that found the PHP flaws is also available to defenders. Speaking at Stanford Graduate School of Business, Sam Altman said, as reported by Gizmodo, "I think we're going to have to completely switch the defense model to using the same technology for a new kind of defense shield". Two defensive uses are ready now.

AI code review

PHP's own maintainers already use it. Earlier in 2026, the Alpha-Omega project scanned PHP with Anthropic's Claude Mythos, and the security team has since added OpenAI's Daybreak Red to validate incoming reports and exploits. The Foundation is clear about the division of labour: AI helps validate and group reports, and people make every decision.

For your own software, the same pattern applies. AI review runs on every change alongside human review, can catch flaws that people miss under time pressure, and helps sort a growing volume of reports into what matters. A person still approves every fix. As we set out in our piece on agentic engineering, "every AI-generated line that reaches production should still be reviewed." We looked at what AI code scanning means for the security market in our piece on Claude Code Security.

Formal verification

Testing checks the inputs you try. Formal verification proves, mathematically, that code behaves as specified for every input in scope. It has long been too expensive for most software. Anthropic's research, published on 22 October, suggests that is changing.

Claude proved that compiled programs from 123 open-source libraries, covering 239 entry points, cannot suffer memory-safety errors or failed assertions for inputs up to 64 MB. The proofs were checked by the Rocq proof checker, and the libraries include libexpat, libcups and FreeRDP. Along the way, the process uncovered hundreds of bugs that, in Anthropic's words, "had eluded detection for years" despite extensive fuzzing. Claude patched them as it went.

Anthropic is candid about the limits. "Formally verified" does not mean "bug-free", the proofs rest on specific assumptions about the hardware and operating system, and a single proof can need hundreds of millions of tokens. Even so, the authors expect formal verification to "soon be as practical as fuzzing is today for almost all production software."

For most businesses, the practical step today is narrower: identify the components where a flaw would do the most damage, such as code that parses untrusted input or handles authentication, and ask whether deeper verification is worth the cost there.

The trap

Treating AI as a threat to defend against, but not as a tool to defend with.

The fix

Build AI review into the development pipeline, with a person approving every fix.

Dependency hygiene and patch SLAs

Finding flaws faster only helps if fixes ship faster too. At the moment they do not. By 22 May, Anthropic had disclosed 1,596 vulnerabilities found by its Claude Mythos Preview model across 281 open-source projects, and the Cloud Security Alliance found only 97 of them confirmed as patched, about 6%. Sam Altman told Stanford students that people "didn't really intuit the exponential", and The Neuron's 23 October digest reported him questioning whether patching every newly found weakness will stay feasible.

Know what you run

Most modern software includes open-source components, and each of those depends on others. When a flaw like PHP's is announced, the first question is whether it affects you, and the answer is only quick if you already have an inventory of every dependency, direct and indirect, and where each one runs. A software bill of materials, or SBOM, is the standard format for that inventory. AI-written code makes it more important, because an AI coding agent may choose a dependency your team would not approve, as we noted in our piece on moving beyond vibe coding.

The UK Government's Software Security Code of Practice asks software vendors to understand the composition of their software and assess the risks of third-party components, to have processes for "proactively detecting, prioritising and managing vulnerabilities", and to "provide timely security updates, patches and notifications to customers." The Cloud Security Alliance advises organisations to audit both their direct and transitive dependencies against the projects named in published disclosures, starting with internet-facing components and those that handle authentication, cryptography or protocol parsing.

Patch to an agreed clock

A patch SLA is an agreed maximum time to apply a security fix, set by severity and exposure. The UK already has a baseline. Under the April 2026 Cyber Essentials requirements, high-risk or critical security updates must be installed within 14 days of release, and IASME confirms that missing that deadline is now an automatic fail.

The PHP release shows why 14 days is a ceiling, not a target. A proof-of-concept video was circulating the evening before the fix was published. The Cloud Security Alliance recommends treating available fixes "as emergency changes rather than scheduled maintenance items", and for internet-facing systems that is the only safe reading.

What to agree for dependency hygiene and patch management
What to agree Why it matters
A dependency inventory You can tell within hours, not days, whether a new flaw affects you
Patch SLAs by severity and exposure Critical fixes for internet-facing systems do not wait for the next maintenance window
An emergency change route A critical fix can be tested and released as soon as it is available
Advisory monitoring Someone is watching security advisories for every component you run
Interim controls Where a patch cannot go in yet, segmentation, least-privilege access and logging limit the damage

The trap

Patching on a monthly maintenance cycle and finding out what you run only when a flaw is announced.

The fix

Keep the inventory current and agree an emergency route that can ship a critical fix as soon as it is released.

Questions to ask your development partner

If a partner builds or maintains your software, these are its responsibilities as much as yours. A partner that takes security seriously should be able to answer each of these questions clearly.

  • How do you use AI in code review?Which tools run on our code, at what stage, and who approves the fixes they suggest?
  • Do you keep an inventory of our dependencies?Does it include indirect dependencies and where each one runs, and can we see it?
  • What are your patch SLAs?How quickly do critical and high-risk fixes reach production, and what did you do on 21 October?
  • How do you hear about new vulnerabilities?Who monitors security advisories for the components in our systems?
  • What happens when a patch cannot go in straight away?Which interim controls do you use, and how do you tell us?
  • Do you publish a vulnerability disclosure process?The Software Security Code of Practice expects vendors to have one.
  • Which security standards do you meet?For example, ISO 27001 or Cyber Essentials.
  • Where would deeper verification be worth it?Which parts of our system would justify formal verification or extra testing?

A partner that cannot say what is in your software cannot tell you when it needs patching.

Faster finding needs faster fixing

AI vulnerability discovery is not going to slow down. OpenAI expects more findings like PHP's, Anthropic expects formal verification to become routine, and maintainers are already working through more reports than they can fix.

The organisations that come through this well will be the ones whose software is built and maintained with AI-assisted review, a current inventory of what it depends on and an agreed clock for patching. Those should be standard parts of any bespoke development engagement, not extras added after the next emergency release.

Could you patch a critical flaw as soon as it is announced?

If you cannot say which open-source components your systems use, or how quickly a critical fix would reach production, start there.

At Imobisoft, we build and maintain bespoke enterprise software, and we have completed three consecutive years of ISO 27001 accreditation.

Talk to us about secure development

Frequently asked questions

What is AI vulnerability discovery?

AI vulnerability discovery is the use of AI models to find security flaws in software. Researchers used it to find two critical flaws in PHP in 2026, and the same capability is available to attackers.

Which PHP vulnerabilities were fixed on 21 October 2026?

CVE-2026-109618 and CVE-2026-109619, two critical remote code execution flaws rated 9.2. They are fixed in PHP 8.5.12, 8.4.27, 8.3.36 and 8.2.35.

Did AI find the PHP vulnerabilities?

AI models helped. OpenAI says Calif found a flaw using GPT-5.6 Sol, and Wiz used its Atlas system with Gemini 4 Argon and GPT-5.6 Sol. One root cause was first spotted in a 2024 audit.

What is formal verification?

Formal verification is a mathematical proof that code behaves as specified for every input in scope. Anthropic used Claude to verify security properties across 123 open-source libraries in 2026.

What is a patch SLA?

A patch SLA is an agreed maximum time to apply a security fix, set by severity and exposure. Cyber Essentials requires high-risk or critical updates within 14 days of release.

What should I ask my development partner about security?

Ask how it uses AI in code review, whether it keeps an inventory of your dependencies, what its patch SLAs are, and how it handled the PHP emergency release.

Sources

Have a project in mind? Let’s get to work.

Let’s chat about how we can help you. Fill in the details and we’ll get back to you as soon we can.