PHP2Shell: The PHP Vulnerability That Put Linux Web Servers on Alert

How two critical PHP bugs were found, how they were fixed, and what Linux administrators should do about them

Published November 12, 2026

If you run a Linux web server, there is a good chance PHP is on it. WordPress, Drupal, Joomla, Nextcloud, Roundcube, phpMyAdmin, Magento, and Laravel applications all depend on it, and most of them run on Linux. That is why the October 2026 disclosure of two critical flaws in PHP itself, nicknamed PHP2Shell, deserves attention from anyone who administers Linux systems.

This article covers what the flaws are, how researchers discovered them, how the PHP project and the Linux distributions fixed them, and what you should check on your own systems.

What Is PHP2Shell?

PHP2Shell is the name given to two vulnerabilities in the PHP engine: CVE-2026-109618 and CVE-2026-109619. Both are rated 9.2 (Critical) on the CVSS v4.0 scale. Both are use-after-free bugs, meaning PHP continues to use a piece of memory after it has already been released.

Because the flaws live in PHP’s core rather than in any one application, a site can have perfectly clean code and still be exposed. The vulnerable code dates back to PHP 5.4, released in 2012, so essentially every unpatched PHP version since then is affected, on both Apache mod_php and PHP-FPM.

CVE	Class	Impact
CVE-2026-109618	Upload-progress unserializer use-after-free	Remote memory disclosure and remote code execution
CVE-2026-109619	Fatal-error backtrace use-after-free, OPcache type confusion	Remote code execution

In plain terms: when PHP runs out of memory at just the wrong moment while setting up a request, it can leave half-built internal data behind. Cleanup code, or a later request handled by the same worker process, then trusts that stale data. A carefully crafted multipart upload request can steer this into leaking server memory (potentially including passwords, session tokens, and TLS keys from other requests) or executing attacker-chosen code. The trouble starts before the application’s own code ever runs.

How the Vulnerabilities Were Discovered

A long trail of clues

The story of PHP2Shell is unusually long. According to the researchers’ own write-up, the first PHP memory-limit remote vulnerability was documented by security researcher Stefan Esser in 2004. In 2020, a seemingly harmless bug report (PHP bug #78876) noted that long variables in multipart requests could cause an out-of-memory condition and leave temporary files behind. In 2024, an OSTIF and Quarkslab audit of PHP rediscovered a related out-of-memory issue, but exploitation was not proven, so it was not treated as a security fix.

Patch the Planet and an AI-assisted audit

In 2026, researchers at Calif joined OpenAI’s Patch the Planet initiative and chose PHP as a high-impact target, bringing in the PHP Foundation. Researcher Ryan Austin began an audit on July 30 and, within days, found the first exploitable path (August 1). His approach was deliberate rather than magic. He had a background in PHP internals and knew its vulnerability history, so he used an AI model to hunt for ways to exceed PHP’s memory_limit on demand, the same idea behind Esser’s 2004 bug.

Two findings made that practical. First, PHP checks post_max_size against the declared Content-Length but does not enforce it against the bytes it actually consumes, so requests with no meaningful declared length could slip past it. Second, an empty file-upload part with a nested field name makes PHP build a large hierarchy of internal hash tables, so a small request body can consume far more than the default 128 MiB heap.

With a controllable out-of-memory fatal in hand, the next question was what could be interrupted in a harmful state. The AI agent flagged a code ordering in PHP’s hash-table insertion routine: the element counters are incremented before the new bucket is fully initialized, so if the key allocation fails, teardown later treats stale bytes as a live entry. The team then generalized this into a reusable pattern (publish state, do fallible work, then commit, with the commit skipped if a fatal intervenes) and used it to find a second weakness in the session upload-progress feature, plus a path that works against PHP-FPM through PHP’s generic unserializer.

The researchers stressed that no special harness or unreleased model was used. Their conclusion was that knowing your target and its history still matters, even in the age of AI-assisted research.

Independent discovery

Wiz Research (Sagi Tzadik, Shir Tamari, Nir Ohfeld, and Tomer Schwartz) and OpenAI also found and reported the vulnerabilities independently, which is why the credit line names Calif, Wiz, and OpenAI. Wiz reported to PHP on August 24.

Timeline

Sources differ slightly on a few early dates, so the table below follows Calif’s own account and Sansec’s summary.

Date (2026)	Event
August 1	Calif finds the first RCE paths
August 11	Calif reports the first bug to PHP; coordinated disclosure begins
August 14 to 15	Calif shares a working proof of concept; PHP confirms it
August 21	Calif reports a second bug
August 24	Wiz Research reports the vulnerabilities to PHP
October 20	Details leak on social media ahead of the planned October 22 disclosure; watchTowr confirms code execution
October 21	Cloudflare reports early attacks at 07:43 UTC; PHP releases fixes at 14:00 UTC and researchers disclose
October 26	CISA adds both CVEs to its Known Exploited Vulnerabilities catalog

The leak forced the issue. Attacks were observed before the patches were even released, which is the nightmare scenario for coordinated disclosure.

How It Was Fixed

The PHP security team coordinated the fix and shipped it in the October 2026 security release on October 21. The patched versions are:

• PHP 8.5: 8.5.12 or later
• PHP 8.4: 8.4.27 or later
• PHP 8.3: 8.3.36 or later
• PHP 8.2: 8.2.35 or later

End-of-life PHP and the Linux distributions

PHP 8.1 and older no longer get official releases from the PHP project, yet a great many Linux servers still run them. This is where the Linux ecosystem did much of the heavy lifting. The PHP security team published source patches for 7.4, 8.0, and 8.1, and distributions and vendors backported the fix into older packages. A backported package keeps its original version number (for example 8.1.34) and only gains a new package release, so you cannot judge your exposure by running php -v alone.

Platform	Where the fix comes from
Debian and Ubuntu	Ondřej Surý’s deb.sury.org repository and PPA (5.6, 7.4, 8.0, 8.1); Ubuntu’s own updates, including 8.1 on 22.04; Ubuntu Pro for older releases
Debian 9 to 11	Freexian Extended LTS (paid)
RHEL, AlmaLinux, Rocky, Fedora	Remi’s repository (free); AlmaLinux fixes for every PHP stream it ships; Red Hat updates for subscribers
cPanel on CloudLinux	CloudLinux packages covering ea-php52 through ea-php85
Any distribution	TuxCare Extended Lifecycle Support and ZendPHP LTS (paid)

Coordination through the Dutch NCSC’s operational repository showed AlmaLinux 8 and 10 fixes marked as available as of November 9. Check your distribution’s security tracker for the specific CVE rather than comparing version numbers.

Confirming the fix on your system

Look for the CVE in your package changelog:

# Debian, Ubuntu (substitute your PHP version)

zgrep CVE-2026-109618 /usr/share/doc/php8.1-common/changelog.Debian.gz

# RHEL, AlmaLinux, Rocky Linux

rpm -q –changelog php-common | grep CVE-2026-109618

After updating, restart PHP-FPM or Apache so the running workers pick up the fixed code.

Impact on Linux and Linux Users

Web servers and hosting

The most direct impact falls on Linux servers running Apache with mod_php or nginx with PHP-FPM, which is the classic LAMP and LEMP stack. Calif confirmed unauthenticated code execution against current releases of WordPress, Drupal, Joomla, MediaWiki, Roundcube, Magento, phpMyAdmin, Nextcloud, Laravel, and Symfony. The Linux-hosted applications many of us self-host are in that list. Shared hosting and control panels such as cPanel, Plesk, and DirectAdmin deserve a second look because PHP is updated through the panel, not always through the system package manager.

Not quite Log4Shell

Early headlines warned that a large share of the web was at risk, and the exposure is indeed broad. But Sansec and others found that real-world exploitation is harder than the headline suggests. Unlike Log4Shell or Shellshock, no single request has been shown to work against any vulnerable server. Public proof-of-concept exploits reportedly fail against a default PHP installation, and many need an additional flaw in the target application, such as local file inclusion. Reliable attacks require knowledge of the target’s memory configuration and application state. That is a reason to patch calmly and promptly, not a reason to skip patching: CISA’s catalog listing and in-the-wild activity show attackers are using it.

Appliances and embedded Linux

PHP also runs inside products you may not think of as PHP servers. Check Point Research documented attackers using PHP2Shell against the Mobile Access portal of unpatched Check Point Security Gateways beginning October 30. After gaining initial access, they escalated to root through a separate local privilege-escalation flaw (CVE-2026-123039), then deployed web shells and a persistent backdoor. A second, broader wave followed on November 2 across multiple countries and sectors, with no evidence of destructive activity. The lesson for Linux admins is to inventory PHP everywhere, including appliances, hosting panels, and bundled binaries.

Operational disruption

Several Dutch organizations, including the national cybersecurity center NCSC and the House of Representatives, took sites offline as a precaution on disclosure day. Whether or not that was necessary, it shows how seriously defenders treated the risk.

What it does not affect

This is not a flaw in the Linux kernel or in core distribution tooling. A Linux desktop that does not serve PHP web requests faces little direct exposure. The risk is concentrated in systems that accept web requests handled by PHP.

What To Do Right Now

• Patch. Update PHP to a fixed release or a distribution package that lists the CVE in its changelog, then restart PHP-FPM or Apache.
• Inventory. Find every PHP install: containers, hosting panels, appliances, and old test servers. Note that the official Docker php image receives no fix for 8.1 or older.
• Plan the upgrade off EOL PHP. Backports and paid support buy time, but the durable fix is moving to a supported branch.
• Watch for signs of exploitation. Look for unexpected child processes spawned by php-fpm or apache2 workers, and for PHP error-log entries about memory exhaustion in “Unknown on line 0”, which indicates the failure happened before any application code ran.

If you cannot patch immediately

These mitigations are partial and temporary. PHP core developers noted that disabling upload progress alone is not enough.

• Block multipart/form-data requests at the web server. Every known trigger uses that content type, but this breaks file uploads and some forms, so test it.
• Set session.upload_progress.enabled = 0.
• Calif also suggested memory_limit = -1, which removes PHP’s memory cap. That lets a single request consume all server memory, so monitor usage and restore the limit after patching.

For PHP-FPM, set these per pool (for example with php_admin_flag and php_admin_value in the pool configuration) and verify the values from a request served by PHP-FPM, not from the command line.

An Open Item

A third issue, CVE-2026-115560, was named on October 23. PHP describes it as an unlikely route to remote code execution in an unusual configuration. As of November 2 it was waiting for PHP’s next regular release, and the guidance in the meantime was to keep session.upload_progress.enabled set to 0. Check php.net for the current status before relying on this.

Takeaways

PHP2Shell is a reminder of three things. Old, “harmless” bugs can become critical when someone finds the right primitive, as a 2020 bug report and a 2024 audit finding eventually did. AI-assisted research is now finding serious flaws in heavily audited code, though it works best in the hands of researchers who know their target. And the Linux ecosystem’s backporting culture, from distribution security teams to community repositories, is what protects the many servers that cannot move to the newest PHP overnight.

Patch, restart, verify, and then take a hard look at how much PHP 8.1-and-older you are still running.

Sources

Calif Research, “PHP2Shell: A tale of two PHP remote vulnerabilities”; Sansec Forensics Team, “PHP2Shell: PHP RCE”; watchTowr, PHP2Shell FAQ; OffSec, “PHP2Shell: Critical Vulnerabilities in PHP Core”; SOCRadar, “PHP2Shell” advisory; Check Point Research, “PHP2Shell Exploitation on Check Point Gateway”; NCSC-NL, php2shell operational information. Details were current as of November 12, 2026 and may change as vendors update their advisories.