Executive Summary:

  • Two faults in PHP, the software behind roughly seven out of ten websites, let a stranger on the internet run commands on a web server. A repair was published on 21 October.
  • We downloaded an attack tool that a stranger had published on GitHub and ran it, unchanged, against our own test server running an ordinary, unrepaired installation of PHP and it successfully took control.
  • We then built our own exploit with AI, starting from the published fix. Within hours, it ran commands on a standard PHP server – and worked against an ordinary WordPress site too.

What are CVE-2026-109618 and CVE-2026-109619?

Why PHP vulnerabilities put most of the web at risk

When you open a web page, something has to build that page before it reaches you. For roughly seven out of ten websites, the software doing that job is PHP. It sits on the web server, assembles the page, and sends it to your browser. It is underneath WordPress, Drupal, Magento and a great many ordinary company websites.

What went wrong

CVE-2026-109618 leaves PHP’s internal state corrupted when its memory limit is reached, allowing attackers to hijack execution during cleanup. Its companion, CVE-2026-109619, causes a double free that exploit chains use to leak memory and defeat ASLR. Together, they can enable unauthenticated code execution and expose secrets; the fixes make allocation failures safe.

What we did

The question we wanted to answer was a practical one. How easy is it to create a working exploit with AI? And the answer is, it can get challenging. The guardrails of the modern models are strong and prevent the creation of a full-chain RCE exploit. But at the same time, they can always be bypassed. And none-the-less successful attack tools for this were still circulating within hours of the repair. The publishers are skilled hackers, and they were probably relying on local / non-guardrailed AI models.

How far AI got us

We tried to build the attack ourselves, with AI, working only from the published repair and our own test servers. AI found a way to make an ordinary web request use up all the memory PHP is allowed, on a server with entirely normal settings, before the website’s own code has even started. On the repaired version the same request is handled normally.

We then ran into tiring guardrails when attempting to ask for a full-chain RCE together with a memory leak primitive, and decided to switch to a different agent at this point. Once changed to another less restricted agent, it broke into a standard PHP server and ran commands in a matter of hours. Same attack then worked against an ordinary WordPress site.

successful exploit on 8.4.26

failed exploit on 8.4.27

Are AI-generated PHP exploits on GitHub a real threat?

The argument going round is that there are thousands of attack tools on GitHub, almost none of them work against a normal server, so the whole thing is overblown.

Most of those tools really are junk, written with AI by people with no way to tell whether they worked. Both things are true at once, though: the junk exists, and so do real attacks built with the same tools by people who check their results.

The speed is what to notice. When a similar flaw was found in another widely used program years ago, researchers were handed a full explanation of it and still took about three days to produce one working attack, against one specific version. Here nobody outside the disclosure knew what the flaw even was, and working attacks appeared within a day.

What made the difference was not a cleverer AI. It was the setup. That is the part to plan around. The flaw is still fiddly, and each version of PHP needs its own adjustments – but that is now a matter of leaving an AI to work through them, rather than a specialist’s week. The step from one broken server to several hundred has become a short one.

Why repairs help attackers too

A public fix also gives attackers a map of the flaw. PHP’s patch changed 300 files and included 127 regression tests designed to trigger the bugs – giving attackers expert-written examples to study. This is the same exact problem we’ve re-iterated with BGH. With vulnerable versions still available, anyone can compare behavior before and after the fix, just as we did. Publication starts the race: defenders must patch while attackers turn those clues into working exploits.

An unexpected finding

Working attacks existed before the flaw was public at all, with AI and nothing but the scraps already circulating. AI closed the gap between knowing a flaw exists and having a one-command tool, and that the internet then improved that tool for free. The window defenders assume they have, between a repair appearing and attacks following, can close before the repair is announced. This is a true game-changer in patch security.

How to protect PHP servers from CVE-2026-109618 and CVE-2026-109619

  • Update PHP wherever you run it. We verified that the repair stops this attack. Versions 8.2.35, 8.3.36, 8.4.27 and 8.5.12 and later contain it.
  • Find out where you run it. The harder half of the problem for most organisations is not patching, it is knowing which servers to patch. Old marketing sites, acquired brands, forgotten test machines and suppliers’ systems are where this will land.
  • If a server cannot be updated, take it off the public internet. Older versions of PHP have no repair available at all. For those, removing public access is the only real answer.
  • Assume that anything exposed and unpatched may already have been reached, and check it rather than hoping. Attempts against this were seen before the repair existed.