Centraltec

AI ConsultingAI Development

php2shell and the zero-day wave: the security flaws of October 2026

A critical flaw in the PHP core, a series of actively exploited zero-days in perimeter devices, and the first vulnerabilities in AI tooling itself – what is behind it and what companies should do now.

Illustration: an orange glowing crack running through a dark server hall

The past four weeks have been unusually dense for anyone responsible for security. Three developments ran in parallel: a critical flaw in the core of PHP that affects practically every web server. A series of zero-days in exactly the devices that are supposed to protect the corporate network. And the first serious vulnerabilities in the AI tools people now develop with.

This article sorts out what happened, what is genuinely urgent – and why something fundamental is shifting in the speed at which all of this plays out.

php2shell: a flaw below the application

On 21 October 2026 the PHP project released patches for two vulnerabilities known collectively as php2shell: CVE-2026-109618 and CVE-2026-109619, both rated 9.2 out of 10 under CVSS. CVSS is the industry scale for vulnerability severity; anything from 9.0 upwards counts as critical. Both allow an attacker on the internet to execute commands on the web server without credentials and without any user interaction. (CISA, BSI)

What matters is where the flaw sits. PHP processes the data of an incoming request before extensions are initialised and before a single line of application code has been compiled. The vulnerability therefore lives below the application. In practice that leads to an uncomfortable conclusion: a carefully maintained, fully up-to-date application is exactly as exposed as a neglected one. Neither a clean framework nor good in-house code helps here. (CrowdStrike)

In simplified terms the attack works like this: the attacker sends a request deliberately crafted to push PHP into a memory limit while it is being processed. PHP aborts – but the abort skips the cleanup. What remains are global pointers referring to memory that has already been released. A pointer is an address in memory; when the memory behind it has been freed but the pointer survives, the program carries on working with foreign data.

That is exactly what the second step exploits. Web servers handle many requests with the same worker process. The attacker's next request fills the freed memory with content of their choosing – and PHP then treats that content as its own internal structures. The result is arbitrary command execution with the privileges of the web server. CrowdStrike has demonstrated that a single anonymous POST request is enough to make an Apache worker process launch a shell. (CrowdStrike, Wiz)

The two CVEs differ in how far the attack reaches. CVE-2026-109618 plays out within a single request. CVE-2026-109619 needs two requests to the same worker process and mainly affects installations with long-lived processes, classically Apache with mod_php. With PHP-FPM a process that already fails at startup is terminated – but an abort in the middle of a script leaves it alive and therefore exposed. (CrowdStrike)

Why the attack is invisible in the logs

One property makes detection particularly awkward: the attack is almost invisible. The worker process does not crash, the server responds with an ordinary HTTP 200, and the application logs contain nothing – because no application code ever ran.

The only reliable trace on the server is an entry in the web server's error log matching the pattern "Allowed memory size of N bytes exhausted" combined with "in Unknown on line 0". That Unknown on line 0 suffix is the actual signal: it means memory ran out before the script even started. Which is what happens during an exploitation attempt – and rarely otherwise. (CrowdStrike)

Further signals worth watching for:

What to do now

Patching is the only complete remedy. The fixed versions are PHP 8.5.12, 8.4.27, 8.3.36 and 8.2.35. Important: after applying them, all worker processes must be restarted, otherwise the old ones keep running.

Three points are regularly overlooked in practice:

First, the inventory. PHP sits in places you would not think of first. Since the patches were published, manufacturers of network components have also been issuing advisories, because PHP is built into their products. So the question is not only "which web servers do we operate?" but "which appliances, management interfaces and off-the-shelf products contain PHP?". (BSI)

Second, the old versions. PHP 8.1 and earlier are no longer maintained and will not receive a patch. CISA recommends taking such systems offline until they have been upgraded. That sounds harsh, but given the attack surface it is proportionate. (CISA)

Third, the web application firewall. A WAF – a filter placed in front of the application that blocks suspicious requests – can catch some attempts and makes sense as a stopgap. It is not a substitute for the patch, because the attack happens below the application layer and can hide inside legitimate-looking requests.

How the situation actually developed

The timeline of this flaw is more revealing than the flaw itself.

The PHP Foundation had entered the project into a funding programme for open-source security. In late July the security firm Calif began an audit and within days found several paths to code execution. On 11 August, Calif and OpenAI independently reported the same root cause. Wiz Research found further attack paths of its own during August. All of this rested on a problem whose first signs an audit back in 2024 had already seen – at the time nobody found a concrete way to exploit it, and the fix stalled. (Wiz)

Then things moved quickly:

Imperva analysed the first 24 hours: 482,342 requests, 122,311 attack sessions, 21,998 affected websites across 103 countries. Germany ranked fourth among the most targeted locations. The pattern is shallow, though – just under four requests per session on average. That is broad, indiscriminate scanning, not a targeted attack. (Imperva)

And here comes the good news, which deserves to be stated just as clearly: no successful breach via php2shell has been confirmed so far. Sophos reported one successful case on 22 October and retracted that assessment a few hours later. What has been observed is scanning, fingerprinting, attempts to steal credentials from .env files, and attempted delivery of a Mirai variant for DDoS attacks – but no demonstrated takeover. Sophos' own offensive team describes writing a reliable exploit as difficult, even with AI support. That buys time. It is not an all-clear: with enough effort, working exploits will arrive. (Sophos, The Hacker News)

The perimeter devices: where break-ins actually happen

While php2shell draws the attention, something else is running in parallel that makes fewer headlines and is more dangerous in practice. Since late September a whole series of flaws has surfaced in perimeter systems – the devices at the boundary between the internet and the corporate network: VPN gateways, mail gateways, remote support. From an attacker's point of view these are ideal, because by definition they are reachable from the internet and sit deep inside the network.

For this category of device one rule tends to get lost in the rush to patch: check first, then patch. If a flaw has been exploited for weeks, the device may long since be compromised, and an update removes the traces rather than the attacker. For the Citrix devices CISA explicitly recommends looking for indications of compromise before applying the update, preserving forensic evidence, forwarding logs to a central system – local logs are overwritten quickly – and, if compromise is suspected, restoring a clean backup and then rotating all secrets: passwords, keys and certificates. (CISA)

The third front: the AI tools themselves

For anyone developing with AI assistants, October added a new category. On 21 October a vulnerability in the MCP Inspector was published, shortly followed by a matching one in the AI coding tool OpenCode. MCP, the Model Context Protocol, is the now widespread interface through which an AI assistant connects external tools. (GitHub Security Advisory, The Hacker News)

The mechanism is remarkably simple. The remote MCP server answers the connection attempt with "unauthorised" and names a sign-in address of its own choosing. The tool opens that address in the browser automatically. On Windows and WSL the string ends up inside a PowerShell command – and PowerShell evaluates expressions of the form $(...) inside quoted strings. A URL that looks like an ordinary address thus becomes an executed command.

The boundary conditions are what count: this happens on connect. No click, no approval, no tool call, and the language model is not involved at all. The server does not even need to have been malicious when it was added – the payload arrives at runtime in the response, not from the stored configuration. A compromised server, an expired domain or a typo in the name all produce the same result. macOS and Linux are not affected. (GitHub Security Advisory)

The fix: update MCP Inspector to 2.12.0 and OpenCode to 1.18.33. Anyone unable to update immediately should remove all unvetted remote MCP servers from their configuration.

One detail deserves attention because it illustrates a general pattern: the actual root cause lies in a widely used helper library for opening links. The problem is fixed there in the next major version – but the affected projects reference a version range that never automatically includes that major version. A routine update would therefore not have closed the hole. (GitHub Security Advisory)

Separately, research published in mid-October shows how robust the second MCP attack surface is: tool descriptions. Because a model decides which tool to call based on those descriptions, instructions can be hidden there. Across various model–server combinations the study achieves success rates between 63 and 100 percent while the actual task still completes normally – so the user notices nothing. Three tested defences failed to push the rate below 55 percent. (ACM)

The practical consequence: an MCP server is a software supply chain, not a plug-in. It belongs in your inventory, on an approved list, and under version control like any other dependency.

Why the number of vulnerabilities is rising

Behind all of this sits a shift that can be read in the German BSI's figures. In the first quarter of 2026, 10,803 vulnerabilities became known; in the second quarter it was already 17,539 – a rise of a good 60 percent within three months. The BSI explicitly names AI-assisted vulnerability research as a possible reason. (BSI)

php2shell is the case study for this. The underlying problem had already been brushed against in 2024. What was missing was proof that it could actually be exploited – and without that proof the fix stalled. Wiz describes the required proof as an exceptionally complex chain of steps, at the edge of what human researchers can practically achieve; current AI models, it says, substantially lowered that barrier. (Wiz)

That said, one should not turn this into the wrong story. What happened here is first of all a win for the defenders: three groups found a flaw that had lain dormant for years and spent two and a half months coordinating a patch with the PHP project and the major cloud and CDN providers. On the attacker side, what stands against that so far is plenty of automated scanning but no working exploit in the wild.

What has measurably changed is the time window. Forty-five minutes separated the release of the patch from tens of thousands of exploitation attempts. The CVE numbers had leaked a day earlier, and an exploitation attempt was visible four days earlier. Anyone running patch management around a monthly maintenance window is working against a clock that now ticks differently.

What this means for your own approach

Six points to take from this October:

  1. Internet-facing systems first. Reachability, not the CVSS score, should determine the order. A 9.8 on the internal network is less urgent than an 8.6 at the perimeter.
  2. An up-to-date inventory is half the response. The first question after every advisory is "where is this running in our environment?". If you cannot answer that within an hour, you lose the decisive part of the window.
  3. Think in components, not just products. php2shell affects appliances whose manufacturers built PHP in. A software bill of materials (SBOM) is the right tool for that.
  4. With perimeter devices, check for compromise before patching and rotate secrets afterwards. The update alone does not remove an attacker who is already inside.
  5. Build detection where the attack is visible. With php2shell that is not the application log but behaviour on the host: PHP processes spawning shells, and the error message described above in the server log.
  6. Bring AI tools into the patch routine. Coding assistants, MCP servers and agent frameworks are production software with access to source code and credentials. They belong in the same inventory as everything else.

Our view at Centraltec

We advise companies on adopting AI – which is precisely why this October interests us. It shows both sides of the same development: AI finds vulnerabilities that were overlooked for years, and AI tools bring new attack surfaces of their own.

In practical terms, for the projects we support: every assistant that reads files, runs commands or connects external services gets the same treatment as a production component – inventory, approved list, version status, traceable permissions. And every bridge to the outside, whether package cache, browser tool or MCP server, is planned as an attack surface rather than an accessory.

If you are currently assessing your own position, two questions are the place to start: which of our PHP installations are reachable from the internet, and what version are they on? And which MCP servers and AI tools have access to our development environments today?

← Back to news

php2shell and the zero-day wave: the security flaws of October 2026 | Centraltec