PHP is the unassuming technology behind almost 70% of all websites: blogs, web shops, customer portals. On 21 October 2026, they were all briefly vulnerable – anyone who knew about the php2shell flaw could take over practically any PHP server. A day earlier, the PHP team had tersely announced a release with two critical security vulnerabilities for 16:00 CEST. No details, just 9.2 out of 10 possible points, twice – in IT security roughly what a magnitude 9.2 earthquake is on the Richter scale. In the night leading up to 21 October, @J4ck3LSyN posted on X that he had «successfully recreated & lab/field tested» both flaws.
At insign, where I am co-founder and CTO, that meant: we learned of the date at short notice, the rumours sounded grim, and hosters announced shutdowns. Nothing brings a development team up to operating temperature as reliably as the sentence «two critical flaws, details to follow». My conclusion after this day: without AI, it would have taken us days.
What is behind php2shell (CVE-2026-109618 and CVE-2026-109619)?
In numbers: according to W3Techs, 69.3 % of all websites with a known server-side language run on PHP, and WordPress alone powers 39.6 % of all websites. Add web shop systems such as Magento, Shopware or WooCommerce. Nextcloud, Joomla, Drupal and the web interfaces of many routers and NAS devices also run on PHP.
The nasty part: the flaws are not in a plugin or a sloppily programmed site, but in the core of PHP. Even a perfect website is vulnerable if an unpatched PHP runs underneath. According to Sansec, all versions since PHP 5.4 (2012) are affected, and an attacker needs no login.
| CVE-2026-109618 | CVE-2026-109619 | |
|---|---|---|
| Severity | CVSS 9.2 (critical) | CVSS 9.2 (critical) |
| Technical | Error in cleanup after a memory overflow | Error in the handling of script errors |
| What it means | Attackers can read foreign memory (passwords, sessions) and inject code | Attackers can inject code |
The principle in a picture: when PHP runs out of memory, it aborts and cleans up. This very cleanup can be thrown off balance – the next request walks into a hotel room, so to speak, that was not cleaned after the previous guest. Whoever asks cleverly sees things that should long have been disposed of: passwords, sessions, keys. Whoever asks even more cleverly can leave something in the room themselves – their own code, for example, which the server then executes. According to heise (in German), a few thousand to tens of thousands of requests are enough to take control of the server. In the demo video by the discoverers at Calif, taking over a Laravel server takes 38 seconds.
The flaws are fixed in PHP 8.5.12, 8.4.27, 8.3.36 and 8.2.35.
22 years known, never taken seriously
More interesting than the technology is the backstory: the core of the problem is ancient. There were repeated hints, but never a working attack.
| Date | Event |
|---|---|
| 2004 | Stefan Esser finds the first PHP flaw of this kind and deliberately publishes no exploit |
| 2020 | A PHP bug report (#78876) describes the problem; nobody proves it is exploitable |
| 2024 | An audit by OSTIF and Quarkslab finds a related flaw; exploitability remains unproven |
| 1–24 Aug 2026 | Calif and Wiz Research independently build working exploits and report them to PHP |
| 20 Oct 2026 | PHP announces the release, details leak, watchTowr confirms code execution |
| 21 Oct, 09:43 CEST | Cloudflare reports first attacks and rolls out protection rules |
| 21 Oct, 16:00 CEST | PHP publishes the updates |
The title promises «the hour». Strictly speaking, it was 14 years of vulnerable code and one nervous day between leak and patch – but «the hour» sounds better.
Why did nothing happen for so long? Because a working exploit was very laborious: chain several bugs, rebuild memory layouts, adapt everything per PHP version. That was specialist work for months. This very effort was the hidden protection. Sansec sums it up:
«The underlying bug sat untouched for over a decade. What changed is the cost of weaponizing it.»
AI makes attacks cheaper
AI is cutting exactly this effort drastically. According to Wiz, a single person with frontier models achieved in about a week what previously would have taken a specialist team months. The models analysed failures and adapted the exploit to different PHP versions and applications. Wiz concludes: complexity may no longer be a real barrier.
How that looks in practice is described refreshingly openly by Calif. Searching for relatives of a bug from 2004, the researcher writes: «I asked my LLM companion for help.» After the first find, the team had the AI generalise the pattern, because «the first bug is usually not the best bug, but can be a good indication other juicy bugs hiding nearby». By their own account, no specialised models were needed. And «know your target» still applies. So AI does not replace experts, it makes them dramatically faster. Calif, Wiz and OpenAI built working exploits independently of each other – and according to Sansec, all three name AI as the reason.
AI protects: what we concretely did at insign
insign has been building web projects for Swiss clients since 1999, increasingly e-commerce solutions for well-known Swiss brands. Web shops are the textbook example of PHP applications: many customers, real money and zero tolerance for downtime.
We were not alone in the scramble that day. Uberspace temporarily took PHP services offline; in the Netherlands, Tweakers, the parliament and the national Cyber Security Centre, among others, went offline as a precaution. Hosters such as Maxcluster, one of our major infrastructure partners, also announced at short notice that they would pause all projects and with them our customers' web shops – for about an hour in Maxcluster's case. According to Sansec, PHP core developer Gina Peter Banyard considered it the most sensible option, even before the release, to take PHP servers offline.
And us? We deployed AI as our engine-room crew:
| Task | What the AI took over | What it means |
|---|---|---|
| Inventory | Recording which projects run on which server with which PHP version | We quickly know where we stand |
| Analysis | Checking which measure fits which environment | Fewer nasty surprises |
| Scripts | Preparing hardening automation for several servers | In parallel instead of one by one |
| Configuration | Applying the settings recommended by PHP and Sansec | Fewer typos at 2 a.m. |
| Tests | Checking that the shops still work after the changes | Hardening without lost revenue |
| Communication | Drafting customer information quickly and clearly | Calm instead of guesswork |
Once the vulnerability and countermeasures were known, this let us harden several servers in parallel. Done purely manually, it would have taken days.
I do not want to sugar-coat it: the measures are still in progress, and for older projects the switch to a patched PHP is not trivial. According to the PHP team, the hardening measures are only a «temporary crutch» anyway. AI speeds up the craft. Decisions and responsibility stay with us. Defenders are also using AI on a large scale: Calif conducted the code audit together with the PHP team, sponsored by OpenAI's initiative «Patch the Planet». According to heise, Wiz and OpenAI helped verify the patch using LLMs.
AI sits on the other side too
Attackers have the same tools, and that is no future music: the exploit had already been rebuilt before the release, and Cloudflare saw first attacks at 09:43 CEST, more than six hours before the official publication. The attack needs thousands of requests and, according to heise, lends itself to automated attacks «à la Heartbleed» – the name of the 2014 flaw that hit millions of servers worldwide. How that felt back then, I described at insign at the time (in German): «Heartbleed: Wenn das Herz blutet».
This is our assessment, not that of the sources: anyone who builds exploits with AI can also use it to analyse patches, scan targets and steer attacks. Machines sending thousands of requests against people who need days for an inventory alone: that is not a fair match-up. The window between patch and mass attack shrinks from weeks to hours.
What you should do now
- Ask your hoster: is PHP patched, and when?
- Check your PHP version, including in Docker containers, on NAS devices and routers.
- Update to 8.5.12, 8.4.27, 8.3.36 or 8.2.35. PHP 8.1 and older no longer receive official updates; only backports or a switch will help.
- Use countermeasures only as a stopgap, such as the Cloudflare protection rules or
session.upload_progress.enabled=0. They do not replace an update. - Watch for warning signs: conspicuous file upload requests, a surge of memory errors, unexplained restarts of PHP processes.
Those who practise AI every day are faster in an emergency
php2shell shows: the effort that protected systems for years is disappearing. Anyone who builds AI skills closes the gap that attackers otherwise get for free.
At Evoya and insign, we use AI intensively in our work processes, in development, operations and consulting. This day was the real test. We keep learning and are happy to help other companies do the same. In the 100-Day Introduction Programme, we guide teams from the basics through deepening with internal AI Champions to use case mining. After 100 days, the team works confidently with AI, and its own champions carry the topic forward.
Related reading: AI as Ammunition – why frontier models are treated like weapons, and generative AI agents at Evoya AI – how we use AI in our work processes.