PHP2Shell: the PHP bug that took Europe's websites offline — and how to fix it

On Tuesday afternoon, 20 October, two CVE numbers started circulating on forums and social media with no details attached. By Wednesday, the Dutch government had pulled its DigiD login system offline, Finland had switched off its public-facing government web services, France's Interior Ministry had put sites into maintenance mode, and EU agencies were telling anyone who could not patch to unplug their websites.

The cause was PHP2Shell: two critical flaws in PHP, the language that quietly runs about seven in ten websites. Tracked as CVE-2026-109618 and CVE-2026-109619, they can let an attacker run commands on a web server with a single crafted request. No login. No vulnerable plugin. In the worst case, not even any of your own code has to run.

What is PHP2Shell?

PHP2Shell is the nickname for two separate bugs in the PHP engine itself, both rated CVSS v4.0 9.2 (critical) by the PHP security team. The name says what they do: turn a PHP request into a shell on the server.

Both sit in the parts of PHP that nearly every request touches — memory management and error handling — and both follow the same pattern. A fatal error interrupts PHP halfway through an operation, and PHP later treats the half-finished state as if it were valid.

CVE-2026-109618: out-of-memory corruption during cleanup

When PHP turns a form submission into the $_POST array, it reserves space for each field before filling it in. Datadog Security Labs, which built a working exploit to develop detections, showed that if the request hits PHP's memory_limit at exactly the wrong moment, PHP has already counted a new entry but never initialised it. When PHP then cleans up the failed request, it walks over that uninitialised entry and treats leftover attacker-controlled bytes as real data — all the way to executing a command.

The critical detail: this happens while PHP is parsing the request, before your application starts. Datadog confirmed that application-level authentication cannot block it, and that any PHP script exposes the path, "even one that only prints a response". On Apache with mod_php, full remote code execution was demonstrated with default settings.

CVE-2026-109619: stale state reused by the next request

A PHP worker handles many requests over its lifetime. This bug is a use-after-free: after a fatal error, some worker-wide state can keep pointing at memory that belonged to a previous request. A later request landing on the same worker can then use that freed memory. PHP confirmed two exploitable paths — fatal-error backtraces on PHP 8.5, and upload processing via session.upload_progress, which is enabled by default and runs even if your app never calls session_start(). PHP's advisory also lists memory disclosure as a confirmed impact.

Who is affected?

In the PHP project's own words, every installation that serves web requests is at risk: PHP-FPM, Apache with mod_php, php-cgi, FrankenPHP and LiteSpeed. Risk is highest on mod_php. The earliest affected code path found by researchers dates back to PHP 5.4, released in 2012.

And it is not only websites. PHP is bundled inside WordPress, Drupal, Joomla, Magento and Laravel apps, but also inside hosting control panels like cPanel and Plesk, network appliances, management interfaces and vendor products where you cannot update PHP yourself. The Dutch NCSC is maintaining a public list of affected third-party products — at the time of writing, vendors such as Fortinet still had products marked as under investigation.

The timeline

1. 2024 — during PHP's first external security audit in years (by Quarkslab), a PHP core developer finds the first signs of the out-of-memory problem. An exploit is theorised but not proven, and the fix stalls.
2. 30 July – 24 August 2026 — security firm Calif, auditing PHP under OpenAI's "Patch the Planet" programme, reports a working unauthenticated RCE on 11 August. OpenAI independently reports the same root cause; Wiz follows with further attack vectors.
3. 17 October — Amazon Threat Intelligence records a PHP2Shell exploitation attempt against its MadPot honeypots, from an anonymisation network. Four days before disclosure.
4. Tuesday 20 October, ~15:00 UTC — the two CVE IDs leak online, with a wrong CVSS score of 10.0. PHP publishes an advance notice and pulls the release forward a day. Calif mistakenly posts, then deletes, a proof-of-concept video; copies spread.
5. Wednesday 21 October, 07:41 UTC — Chainguard publishes patched images more than six hours before the embargo lifts, letting anyone diff the fix.
6. Wednesday 21 October, 14:00 UTC — PHP 8.5.12, 8.4.27, 8.3.36 and 8.2.35 are released. CISA, CERT-EU, the UK NCSC and others issue urgent guidance. Governments across Europe take sites offline.
7. 22–23 October — broad exploitation attempts reported by Amazon, Cloudflare, watchTowr and Check Point. Vendors begin shipping patched appliances and images.

Is PHP2Shell being exploited?

Yes — though "attempted" and "successful" are not the same thing, and the numbers so far mostly measure attempts.

• Amazon says PHP2Shell "is now seeing broad exploitation attempts in the wild", with payloads suggesting multiple actors, and that new proof-of-concept exploits were used against its sensors "almost immediately" after release.
• Cloudflare CTO Dane Knecht said the company was "seeing early attacks emerging" and had deployed WAF rules for all customers, including free — while stressing: "This is a STOPGAP only."
• Check Point Research reports that 10% of organisations worldwide have seen exploitation attempts. Europe is at 14%, more than double other regions — and Denmark is the second most-targeted country in the world at 32%, behind only Hungary at 38%. Telecoms (20%) and education (18%) are the most targeted sectors.
• CISA said on 21 October it had not yet observed exploitation, but urged immediate patching and recommended taking unpatchable PHP systems offline.

Security researcher Silas Cutler roughly estimates over 1.3 million internet-exposed hosts may be vulnerable. One caution from Tenable is worth repeating: a lot of "exploit code" is now circulating on GitHub and social media. Some of it does not work, and unverified exploit code is a well-known way to infect the very researchers and admins who run it.

What the experts are saying

The PHP Foundation was unusually candid about the 2024 delay: "We won't pretend otherwise: the delay was a structural failure, caused by both the security team's decision process and its lack of resources." Its message to everyone running PHP was simpler: "If you run PHP, it is imperative that you update now."

AI is the other half of this story. Wiz researchers wrote that "with frontier AI models and the right tools, a single researcher completed in a week what previously would have taken a world-class team months of work." OpenAI called it "one of the most impactful vulnerabilities in recent memory".

Amazon's threat intelligence team drew the operational conclusion: "An embargo protects defenders only until someone else finds the same bug," and for critical internet-facing flaws, "a 7-day or 30-day SLA assumes a delay that no longer exists."

Steve Kerrison, senior lecturer in cybersecurity at James Cook University in Singapore, told AFP that "the moment all the information's out there, people can weaponise it very, very quickly" — and warned that "there are sites, systems and people out there who will have no idea about this and still won't for days, weeks and months." Dimitrios Salampasis of Swinburne University added a useful reassurance: "Taking websites offline does not necessarily mean they have been hacked."

And Charlotte Wilson, Head of Enterprise at Check Point, asked the bigger question: "whether we've become too dependent on technology that can leave so many organisations vulnerable at exactly the same time."

What made this so bad — analysis, not confirmed findings

What follows is our reading of the public facts, clearly labelled as analysis. Treat it as perspective, not as an official post-mortem.

1. Your security controls sit downstream of the bug

Most web defences — login pages, input validation, framework middleware, even many plugin-level security tools — run inside your application. PHP2Shell fires while PHP is still unpacking the request, before any of that exists. That is why secure application code offers no protection here, and why the only reliable defences are the patch itself or something sitting in front of PHP.

2. Known risk, deferred

The root cause was spotted in 2024 and parked because nobody had proven it exploitable and every fix had trade-offs. That is an extremely common pattern in every organisation, not just open source. "Theoretical" is a statement about what you have found so far, not about what an attacker will find.

3. The disclosure window collapsed

A leaked CVE ID, an accidentally published video, and an early-published patched image each handed attackers a head start. Combine that with AI-assisted exploit development and the gap between "advisory" and "working exploit" shrank to hours. Patch processes built around weekly maintenance windows were never designed for that.

4. You probably have more PHP than you think

The hardest part for many organisations will not be patching their main website. It will be the forgotten things: an old intranet, a marketing microsite, a container image built two years ago, a firewall's management panel. As CISA put it, PHP "is often a component of other software and prevalence may not be directly observable."

Red: why attackers love this one

• Pre-authentication, over plain HTTP, against software running on a majority of websites.
• No vulnerable plugin or coding mistake required — a "Hello World" page on an unpatched server can be enough.
• A refined exploit returns HTTP 200 and does not crash the worker, so nothing looks broken.
• A long tail of unpatchable end-of-life PHP and vendor appliances will stay exposed for months.
• Compromised web servers are useful for everything: data theft, web shells, spam, malware hosting and pivoting inward.

Blue: PHP2Shell remediation, step by step

Step 1 — Find every PHP runtime

Inventory first, prioritising anything internet-facing. Check the runtime that actually serves web traffic: the command-line php binary can be a different version from PHP-FPM or mod_php. Include containers, CI-built images, hosting control panels and appliances.

# Debian / Ubuntu packages
apt list --installed 'php*' 2>/dev/null
# RHEL / Alma / Rocky
rpm -qa 'php*'
# The FPM binary, not just the CLI (name varies by distro)
php-fpm8.3 -v
# Inside a container image
docker run --rm --entrypoint php your-image:tag -v

One trap: Linux distributions often backport fixes without changing the upstream version number. An Ubuntu or Debian package can be patched while still reporting, say, 8.1.x. Check your distribution's security advisory for the specific package version rather than relying only on php -v.

Step 2 — Patch PHP itself, then restart everything

• Update to 8.5.12, 8.4.27, 8.3.36 or 8.2.35, or your vendor's patched package.
• Rebuild and redeploy container images. A patched base image does nothing until your app image is rebuilt on it.
• Restart or replace every worker. Long-running PHP-FPM pools and Apache processes keep the old code in memory until restarted.
• On PHP 8.1 or older, treat the system as exposed unless your vendor has shipped a backport. Plan the branch upgrade now.
• On managed hosting, ask your provider directly — in writing — whether the PHP runtime serving your site is patched.
• For appliances and SaaS, follow vendor advisories and the NCSC-NL product list, and push suppliers for dates.

Step 3 — If you cannot patch today: reduce exposure

PHP, CISA, CERT-EU, the UK NCSC and the NSA all give the same order of preference: patch; if not, apply temporary measures; if those cannot be applied quickly, take the system offline or isolate it. The temporary measures from PHP's advisory are:

; CVE-2026-109619 — must load before PHP parses the request
session.upload_progress.enabled = 0
fatal_error_backtraces = 0   ; PHP 8.5 only

; CVE-2026-109618 — enforce at admin level so apps cannot override,
; e.g. in a PHP-FPM pool:  php_admin_value[memory_limit] = -1
; ONLY together with request-body limits at the proxy and a
; container/cgroup memory limit. Then restart every worker.

Read the official guidance before applying the memory_limit change: removing PHP's per-request limit without a front-end body-size limit and a container memory cap trades one problem for a denial-of-service risk. PHP also warns against substituting process limits such as RLIMIT_AS, which can trigger the very allocation failures the bug relies on.

• Put a filter in front of PHP. WAF rules from Cloudflare, AWS WAF and others cover known vectors. Limit request body sizes at the reverse proxy, including chunked requests without a usable Content-Length.
• Consider blocking multipart uploads on apps that do not need them, as Amazon suggests — after testing what it breaks.
• Restrict access to admin panels and internal tools by VPN or IP allow-list.

Step 4 — Assume you might already be compromised, and look

Patching closes the door. It does not evict anyone who walked through it. Amazon recommends starting investigations from 17 October, not from the disclosure date. Signals worth hunting for, drawn from Datadog, Amazon and Check Point:

• PHP error logs: Allowed memory size of … bytes exhausted errors reported in Unknown on line 0 — meaning PHP failed before any script started.
• Web server logs: unusually large form POSTs, form field names that are megabytes long, binary or null bytes in form data, and POST bodies containing PHP_SESSION_UPLOAD_PROGRESS.
• Crashes: bursts of worker segmentation faults (for example Apache's AH00052 … Segmentation fault).
• Processes: a web worker (www-data, apache, nginx) spawning sh, bash, curl or wget — the strongest single sign of success.
• Files and network: new or modified .php files in web roots (possible web shells) and outbound connections from web servers to unknown hosts.

# PHP files created or changed since the first known attempt
find /var/www -name '*.php' -newermt 2026-10-17 -ls
# Pre-script memory exhaustion in PHP logs (paths vary)
grep -R "in Unknown on line 0" /var/log/php* /var/log/apache2 /var/log/nginx
# Shells running under the web server user
ps -eo user,pid,ppid,cmd --forest | grep -E '^(www-data|apache|nginx)'

Correlate rather than react to any single signal — legitimate workloads also run out of memory. And do not rely on a crash or an error code: Datadog's refined exploit returned HTTP 200 and left the worker running. If you find evidence of compromise, isolate the server, preserve logs and disk images, rotate any credentials and keys that lived on it, and rebuild from a known-good source rather than cleaning in place.

If you run a small website or online shop

1. Ask your host one question today: "Is the PHP version serving my site patched for CVE-2026-109618 and CVE-2026-109619, and when were the PHP workers restarted?"
2. Do not assume a WordPress update covered it. It did not. This is a server-level fix.
3. If your site runs on PHP 8.1 or older, upgrading the PHP version is no longer optional. Most hosts let you switch it in the control panel — test your site afterwards.
4. Check for unfamiliar admin users, files and plugins, and change admin passwords once the server is confirmed patched.
5. Turn on your host's or CDN's WAF if it offers one. It is a seatbelt, not a fix.

The lesson for everyone else

Patch timelines are now measured in hours. For critical, internet-facing, pre-authentication flaws, a monthly patch cycle is a policy for being compromised. Decide in advance who is allowed to take an emergency change — or take a site offline — without waiting for a meeting.

Know your runtimes, not just your applications. Most asset inventories list apps and servers. Far fewer can answer "where do we run PHP, which version, and who owns it?" in under an hour. That question will come again for a different language or library.

Detect behaviour, not just CVEs. The first exploitation came before any signature existed. "A web server process just launched a shell" is a rule that would have caught this — and will catch the next one too. We made a similar point about volume alerts in the CPR breach: the controls that matter are the ones watching for things that should never happen.

Unsupported software is a decision, not a default. PHP 7.x and 8.1 sites are now stuck choosing between backports, rushed upgrades and going offline. End-of-life dates are published years in advance; treat them like the deadlines they are.

PHP2Shell FAQ

What is PHP2Shell?

Two critical vulnerabilities in the PHP engine, CVE-2026-109618 and CVE-2026-109619, rated CVSS v4.0 9.2. They can let an unauthenticated attacker execute code on a PHP server, in some setups before any application code runs.

Which PHP versions fix PHP2Shell?

PHP 8.5.12, 8.4.27, 8.3.36 and 8.2.35. PHP 7.4–8.1 received source backports only; 5.4–7.3 received no fix. Distribution packages may be patched under different version numbers — check your vendor.

Does updating WordPress, Drupal or Joomla fix it?

No. The bug is in PHP, not the CMS. PHP must be updated on the server and the workers restarted.

Is there a workaround if I cannot patch?

Only partial ones: disable session.upload_progress, set fatal_error_backtraces=0 on 8.5, apply PHP's memory_limit guidance with front-end and container limits, use WAF rules, and restart workers. If you cannot patch, the official advice is to isolate the system or take it offline.

Is it being exploited?

Yes. Exploitation attempts were seen from 17 October 2026, before disclosure, and broad attempts have been reported since. Start any investigation from 17 October.

Sources

• PHP — Security advisory: critical remote code execution vulnerabilities, update now
• PHP GitHub advisory GHSA-w8hw-w9fx-j79w (CVE-2026-109618) and GHSA-6wmf-4rv5-p3rp (CVE-2026-109619)
• The PHP Foundation — Today's PHP security release and how we're strengthening PHP security
• CISA — Critical vulnerabilities in PHP require immediate patching
• CERT-EU — Security Advisory 2026-018
• NCSC-NL — php2shell operational information and affected-software list
• Amazon Threat Intelligence — PHP2Shell exploitation prior to public disclosure in MadPot
• Datadog Security Labs — PHP2Shell: critical vulnerabilities in PHP
• Tenable — php2shell frequently asked questions
• Check Point — PHP2Shell: one in ten organisations impacted as Europe bears the brunt
• Euronews — PHP security flaw: why websites across Europe went dark
• Wikipedia — PHP2Shell