php2shell: two flaws in PHP's core force emergency patching and take public websites offline across Europe

In 30 seconds

Two critical vulnerabilities in PHP itself, not in any particular application, let an attacker without credentials execute code or read the web server's memory; the only complete fix is to update the interpreter and restart every worker process.

• What happened: on 21 October PHP fixed CVE-2026-109618 and CVE-2026-109619 (both CVSS 9.2) in versions 8.5.12, 8.4.27, 8.3.36 and 8.2.35, one day earlier than planned because the details leaked.
• Who is affected: every PHP installation serving web requests (Apache with mod_php, PHP-FPM, php-cgi, FrankenPHP, LiteSpeed), including WordPress, Drupal, Joomla, Magento or Laravel sites and the PHP embedded in control panels, appliances and containers. Branches 8.1 and older get no official release.
• What to do now: inventory every PHP runtime, update to your distribution's fixed package, restart workers or rebuild images and, if you cannot do it today, isolate the system from the internet. Review logs from 17 October onwards.

What happened

On 21 October at 13:30 UTC the PHP security team released versions 8.5.12, 8.4.27, 8.3.36 and 8.2.35 to fix two critical vulnerabilities in the interpreter, now known as php2shell. According to PHP's advisories, both allow unauthenticated remote code execution with the web worker's privileges, and the highest-risk case is Apache with mod_php: PHP demonstrated an exploit in which a single request executes code before any line of the application loads.

CVE-2026-109618 lives in out-of-memory handling. When a request exceeds the memory limit, PHP aborts it with an abrupt jump; if that happens while the request data is half initialised, shutdown treats invalid memory as valid. A crafted multipart request is enough to trigger it while staying within apparent limits. CVE-2026-109619 is stale global state: after a fatal error, a worker process keeps pointers into the previous request's memory, already freed, and a later request can use them before they are reset. The confirmed paths run through session upload progress, enabled by default even when the application never uses sessions, and on PHP 8.5 through fatal-error backtraces.

The memory-disclosure path is what worries analysts most. According to Wiz Research, it can read live worker memory, including passwords, tokens, API keys and certificates from other requests, without executing anything. Wiz and the firm Calif demonstrated unauthenticated code execution against the latest official WordPress, Drupal and Joomla images; Calif adds Magento and MediaWiki. The oldest vulnerable code dates back to PHP 5.4.0, released in 2012.

Two teams found the flaw independently: Calif, within OpenAI's Patch the Planet programme, and Wiz Research, which reported to PHP on 24 August. Both say they used AI models to find the bugs and adapt the exploits to different versions and memory layouts. According to the PHP Foundation, the first signs of CVE-2026-109618 appeared in 2024 during an external audit, but the fix stalled for months, something the Foundation itself describes as a structural failure of decision-making and resourcing.

• 2024: an external audit spots signs of the first flaw; the fix does not progress (PHP Foundation).
• 24 August 2026: Wiz Research reports to PHP; Calif had made its first discovery in early August.
• 17 October: Amazon's honeypot network records an exploitation attempt, four days before disclosure.
• 20 October: an anonymous Hacker News post leaks that two critical flaws are coming; the identifiers circulate with a CVSS 10.0 that PHP calls incorrect. PHP moves the release up a day.
• 21 October, 03:02 UTC: Cloudflare enables web application firewall rules for all plans.
• 21 October, 13:30 UTC: PHP publishes the patches and advisories; CISA, CERT-EU and INCIBE-CERT issue alerts the same day.
• 21 and 22 October: public bodies in the Netherlands, Germany, France, Belgium, Finland and the Czech Republic take portals offline as a precaution.

What is confirmed and what is not

The available data point to exploitation attempts, some of them before disclosure, but as of today no source has confirmed a successful intrusion.

• Confirmed: both flaws allow unauthenticated remote code execution; PHP validated it against mod_php with default settings (PHP advisories).
• Confirmed: on 17 October there was an attempt against Amazon's honeypots from a commercial anonymisation network; on the 21st, several different proof-of-concept exploits from 02:00 UTC. Amazon recommends investigating from the 17th and admits it does not know whether any would have worked against a real system.
• Confirmed: Cloudflare sees attack traffic and attackers changing payloads to evade its rules; it publishes no figures and names no compromised customers.
• Confirmed: VulnCheck documented five source addresses against its honeypots on 21 October, with a scanner identified in its user agent, and one attempt to plant a web shell through session upload progress that failed.
• Confirmed: Arctic Wolf observes attempts that download commodity malware binaries; watchTowr reproduces both flaws and sees attempts against both.
• Not confirmed: any successful intrusion. Huntress had seen no exploitation across its customer base at 20:30 UTC on the 21st; CISA had not observed any when it published its alert.
• Not confirmed: neither CVE appears in CISA's KEV catalogue as of 22 October.
• Not confirmed: the reliability of public exploit code. PHP says it identified no functional exploits at release time and Tenable warns that some circulating code may carry malware.
• Contradiction: INCIBE-CERT's advisory mentions attacks before the patches, yet its table marks exploitation as "No" for both CVEs.

Why it matters

The flaw sits in the layer almost all of the dynamic web shares. Wiz and Cloudflare note that PHP powers close to 70% of websites with a known server-side language. VulnCheck detects PHP on 2.6 million internet-exposed IP addresses and considers almost all of them vulnerable or likely vulnerable; around 42%, more than 1.1 million, run unsupported branches from 3.x to 8.1 with no official release, and only about 403,000 are on the patched 8.2 to 8.5 branches. Other estimates range from 1.3 to 5.1 million servers depending on methodology.

The reaction has been unusual: instead of waiting for the patch, dozens of organisations switched their websites off. According to Reuters, Germany's federal IT provider ITZBund took several sites offline in a "purely preventive" move, France's Interior Ministry took down prefecture websites, Belgium's foreign ministry did the same even though the Belgian national cybersecurity centre recorded no attacks, Finland's state IT centre Valtori shut the government's public web services, the Czech government took its website offline and the Wikimedia Foundation disconnected several systems. In the Netherlands, after the NCSC's advisory, Overheid.nl, the Port of Rotterdam, the KNVB football association, the websites of the five largest parties and numerous hospitals went dark. In Germany, the Charité hospital pulled its entire web presence; the BSI recommended the measure and CISA backs it: anyone who cannot update, or still runs PHP 8.1 or older, should take PHP systems offline until patched.

In Spain, INCIBE-CERT published advisory INCIBE-2026-762 on 21 October with the top rating on its scale. No precautionary shutdown of Spanish websites is on record, nor, at the time of writing, an advisory from CCN-CERT. WordPress, PrestaShop, Drupal, Joomla and Moodle underpin much of the web presence of Spanish SMEs, town councils and online shops, often on shared hosting where the provider is the one who updates PHP.

Precedent weighs here: CVE-2024-4577 (php-cgi) and CVE-2019-11043 (PHP-FPM) entered the KEV catalogue and were used in ransomware campaigns. And the current fix closes the known paths, not the underlying pattern: Datadog and PHP itself warn that variants may appear, including in branches that will remain unpatched.

How to know if you are affected and what to do

Dozens of free URL checkers have appeared, including one published by OpenAI. Almost all of them only read the version the server advertises in its headers, so they see nothing if it is hidden and flag as vulnerable a server whose distribution backported the fix without changing the version number, as Ubuntu 22.04 does. OpenAI acknowledges this in its own tool: an "unknown" result does not mean safe. Besides, sending company domains to a third-party service hands over an inventory of targets.

Assetnote's active scanner does test behaviour by triggering memory exhaustion, but it moves about 29 MiB per path and can crash workers: only against your own systems and outside service hours. The reliable check is local: query the installed package version and compare it with your distribution's fixed one (Debian 13: php8.4 8.4.27-1~deb13u1; Debian 12: php8.2 8.2.35-1~deb12u1; Ubuntu: USN-8948-1 and USN-8948-2 of 21 October for every LTS, including extended-support releases back to PHP 5.5) or look for both CVEs in the package changelog; verify that the version serving the website (mod_php, FPM or container) is the same as the command-line one; and confirm that workers were restarted or the image rebuilt. A new package with the old process still in memory remains vulnerable.

• Inventory every PHP runtime, including the ones embedded in hosting panels, appliances, containers and CI images; CISA stresses that its presence is not always obvious. For large fleets, Rapid7 publishes a Velociraptor inventory artifact and the Dutch NCSC maintains lists of products that embed PHP.
• Update to 8.5.12, 8.4.27, 8.3.36 or 8.2.35, or to your distribution's package, and restart every worker; rebuild container images. Updating WordPress or plugins does not help: the flaw is in the interpreter.
• Unsupported branches: PHP published minimal source patches for 7.4, 8.0 and 8.1; for 5.x to 7.3 there is nothing. Migrate or isolate.
• If you cannot patch today: isolate from the internet, or at least disable session upload progress (and fatal-error backtraces on 8.5), set the memory limit to unlimited from administrator-level configuration, lower the maximum request size and nesting depth, reduce requests per worker, cap size and multipart parts at the proxy and apply SELinux or AppArmor profiles that stop the web process from spawning shells. PHP warns that none of this makes a system safe and that RLIMIT_AS and RLIMIT_DATA limits can trigger the very vulnerable failure.
• After patching: the fix adds a hard memory ceiling that kills the process without running shutdown handlers, so review memory limits and watch for new errors in logs. Wiz also recommends no longer advertising the PHP version in headers.
• If compromised: isolate, preserve logs, hunt for web shells and persistence, rotate the server's credentials and notify your national CERT; where personal data is affected, GDPR gives 72 hours to notify the data protection authority.

What to watch now

The useful signals sit below the application, so WordPress or Drupal logs will say little. According to Datadog and Wiz, correlate unusually large multipart requests with memory-exhaustion errors at "Unknown on line 0" or repeated HTTP 500 responses, abnormally long or malformed PHPSESSID cookies in responses, worker crashes and, above all, PHP processes spawning shells or download tools. The absence of these signals does not prove a system is clean.

• Whether CISA adds the CVEs to the KEV catalogue: it would confirm real exploitation and set deadlines for US federal agencies.
• The first confirmed intrusion: so far there are only attempts; with public exploits and 1.1 million servers that cannot be patched, watchTowr says it is a matter of time.
• New variants: PHP and Datadog warn that the fix closes the known paths, not the underlying pattern.
• The response of shared-hosting providers, who update PHP for most SMEs and local councils.
• The process changes announced by the PHP Foundation after acknowledging the flaw had been known since 2024.

Sources

• Aviso de seguridad de PHP GHSA-w8hw-w9fx-j79w (CVE-2026-109618)
• Aviso de seguridad de PHP GHSA-6wmf-4rv5-p3rp (CVE-2026-109619)
• CISA: Critical Vulnerabilities in PHP Require Immediate Patching
• INCIBE-CERT: Múltiples vulnerabilidades en PHP (INCIBE-2026-762)
• php2shell.com: página de divulgación de Wiz, Calif y OpenAI
• VulnCheck: PHP2Shell Vulnerabilities
• Cloudflare: protections against php2shell
• Reuters: Websites taken offline over PHP risks
• NCSC-NL: repositorio php2shell (productos con PHP embebido)
• Assetnote: php2shell-scanner

Vulnerabilities (4)