Cybersecurity

PHP2Shell: Which PHP Security Update Does Your Site Need?

PHP’s maintainers explain the memory bugs, the demonstrated attacks and why configuration workarounds leave some paths to code execution open.

22 October 20262 min read4 min listen

Listen to the audio analysis

Create your own

Written for builders and creators.

PHP's security team has released fixes for two critical memory bugs known as PHP2Shell. In a demonstrated attack against Apache's mod PHP, a malicious web request can lead to code execution before the application's own code starts.

Editor's note

Why this matters now

PHP’s 21 October security releases fix PHP2Shell, 2 memory bugs that can let an attacker run code on a web server. In the maintainers’ Apache mod_php demonstration, the attack happens before application code runs. Even a login check at the top of the application starts too late to intercept it.

PHP-FPM terminates a worker when request startup fails, stopping that particular sequence. A separate, confirmed PHP-FPM attack requires application code to create session state that survives a fatal error, then a later upload request to reach the same worker. Changing the server setup changes how an attack can work. Both flaws are fixed by updating PHP itself.

The source

What it says

Distilled from the original. The notes above and below are the editor's own.

Two Ways Request Handling Can Go Wrong

CVE-2026-109618 involves out-of-memory handling. If an allocation fails while PHP is setting up request data, cleanup can run on data that was only partly initialized. An attacker can exploit that broken cleanup to run code.

CVE-2026-109619 involves state carried between requests. A worker retains pointers to data from a finished request after PHP has freed the memory. A later request reaching the same worker can use those pointers before PHP resets them, allowing code execution or memory disclosure.

For the out-of-memory flaw, PHP-FPM can still be susceptible after startup, although the maintainers have yet to demonstrate a complete exploit there. FrankenPHP’s cleanup behavior makes it likely susceptible to attacks before application code runs. LiteSpeed’s LSAPI may permit application-specific attacks, which remain unvalidated.

Fixed Releases and Older Branches

PHP released 8.2.35, 8.3.36, 8.4.27 and 8.5.12 to fix both vulnerabilities. Its notice identifies all PHP installations serving web requests as potentially at risk. A successful attacker acts with the web worker’s privileges.

Linux distributions and long-term-support vendors received patches in advance and may supply fixed packages under their own version numbers. PHP also made exceptional minimal source backports for 7.4, 8.0 and 8.1 available to people building from source or without an LTS vendor. Regular upstream support for those older branches has ended.

Why a Settings Change Can Leave an Attack Possible

PHP’s configuration workarounds interrupt particular attacks. Removing PHP’s controllable per-request memory limit still leaves underlying allocation failures possible. Disabling session upload progress blocks the confirmed session attacks while other uses of stale state remain vulnerable.

Timing matters too. The session setting has to apply before request parsing, and every worker needs restarting. Changing it inside application code comes too late. The full PHP notice gives the conditions for each workaround. Updating PHP supplies the complete fix.

Editor's note

What to do with this

An older-looking PHP version may already contain a vendor’s backported fix. An exceptional source patch for 7.4, 8.0 or 8.1 can also address PHP2Shell while leaving the branch outside regular upstream support. The supplier’s security notice identifies its patched package release, which can differ from PHP’s upstream release numbers.

With managed hosting, there is a further question: when does the patched runtime reach the running application? Google Cloud’s guidance shows why some services update automatically and others need a redeployment.

The original

Security advisory: Critical remote code execution vulnerabilities, update now

The PHP Group · 21 October 2026