PHP2Shell: Which PHP Versions Need Security Patches?

01 / The story

What is PHP2Shell?

PHP2Shell is a public nickname for two confirmed flaws in the PHP runtime: CVE-2026-109618 and CVE-2026-109619. A CVE is a tracking identifier for a disclosed vulnerability. The name is used in security reporting; PHP’s own advisory describes the individual memory-handling bugs. This is not an invented label for a generic PHP coding mistake. [1] [3]

On October 21, 2026, PHP published an emergency security advisory and four fixed releases. Its team says the flaws can allow unauthenticated remote code execution. In plain English, a request arriving at a vulnerable server can potentially cause it to run attacker-controlled instructions without the attacker first signing into the application. Exploitability still depends on configuration and the request-processing path. [1]

For a site owner, the immediate question is not which marketing name is trending. It is which PHP build actually handles web requests, whether that build contains both fixes, and whether every worker has been replaced after the update.

02 / The story

What the two bugs do at a high level

CVE-2026-109618 concerns out-of-memory handling. A failure can interrupt initialization of internal request data. Cleanup can then mistake partially initialized data for valid data. CVE-2026-109619 concerns stale global state: internal data can survive after the memory backing it is freed, and a later request handled by the same worker can use that stale state. [1]

These are runtime memory-safety problems, not proof that every application has an SQL injection bug or that every upload contains malware. They can sit below normal application logic. That is why changing a WordPress theme or adding an application-level validation rule is not a replacement for the PHP fix.

Google Cloud’s response describes potential remote code execution and memory disclosure and reports a critical severity score of 9.2 for each flaw. A severity score communicates risk under a scoring model; it does not prove that your server was attacked or reveal a probability of compromise. We do not reproduce exploit payloads or procedures here. [2]

03 / The story

Which versions contain the fixes?

The PHP project identifies the following fixed releases. Use the matching supported branch or a later vendor release explicitly containing both fixes. A Linux distribution may backport patches while retaining an older-looking upstream version number; confirm the distribution advisory and package revision, not only the first version string. [1]

PHP’s advisory includes web-serving installations such as PHP-FPM, Apache mod_php, php-cgi, FrankenPHP and LiteSpeed. It identifies mod_php as the highest-risk case, with a demonstration that can trigger before application code runs. Do not infer that a different serving method is safe simply because the most visible demonstration used Apache. [1]

04 / The story

What about PHP 8.1 and older?

PHP says 8.1 and older no longer receive normal PHP-project updates. Some distributions or long-term-support vendors may provide backported fixes. The advisory also links minimal source backports for 7.4, 8.0 and 8.1, aimed at source builders and users without an LTS vendor. Those special patches do not restore normal upstream support. [1]

Ask a managed host for a written patch statement covering both CVEs and the runtime serving your site. “We updated PHP” is less useful than an exact package/build, advisory reference and rollout status. If you maintain an old branch yourself, weigh a supported-version migration alongside immediate containment.

Updating a base container image is not enough when running instances still use the old image. The same problem applies to an updated package with old long-lived workers. Treat replacement and verification of the running service as part of patching, not an optional final step.

05 / The story

Has exploitation been confirmed?

Singapore’s Cyber Security Agency reports widespread exploitation attempts and available proofs of concept in its October 21 alert, updated October 22. We attribute that report rather than treat it as proof that every targeted website was compromised. Attempts and successful intrusions are different evidence. [3]

PHP’s advisory establishes a demonstrated exploitation path and urges immediate updates. Qlauson has not verified an incident affecting a named production organization, measured the global attack rate or inspected a compromised host. Lack of a confirmed incident in this article is not evidence that an exposed server is safe. [1]

If logs, integrity checks or alerts suggest compromise, use your incident-response process. Preserve relevant evidence, involve your security team or host, and consider credential rotation through trusted channels. Patching closes the known flaw; it does not automatically remove an intrusion that already occurred.

06 / The story

How administrators can check patch coverage safely

Build an inventory of PHP deployments: websites, API services, background administration panels, containers and hosted environments. Identify the runtime actually serving each application. A command-line PHP version may differ from the web server’s PHP pool, and different pools can run different builds.

Use trusted local administration tools and your host’s management information. Do not leave a public phpinfo page online to expose paths, settings and software details. Ask the vendor whether its installed package addresses both identifiers, then restart or replace workers using the vendor’s instructions. [1]

After rollout, run normal application checks—login, uploads if used, API requests and background jobs—and confirm that the running process or container uses the patched build. Record who checked each service and when. For larger environments, package inventory and deployment records are safer than ad hoc exploit tests against live systems.

07 / The story

Why temporary mitigations are not a complete fix

PHP explicitly says only an update is a complete solution. Its interim measures reduce particular attack paths without making a vulnerable installation safe. Settings must apply at the correct initialization stage and sometimes require every worker to restart. Copying a setting into application code may act too late. [1]

We link the original advisory rather than present a universal configuration recipe. Some memory-related changes have availability consequences, and individual mitigations do not block every variant. Administrators should apply them only with the advisory, their platform guidance and a clear patch plan.

A web application firewall can be an additional defensive layer, not a substitute for repairing the runtime. Google Cloud provides platform-specific guidance for its customers; those instructions do not automatically describe another hosting provider’s product or protections. [2]

08 / The story

What does AI have to do with these vulnerabilities?

Google states that Wiz Research used a mix of AI models to help identify and remediate the flaws, and attributes a contribution to Gemini 4 Argon. That is an account from participants, not a controlled study proving that one model alone discovered, reproduced and repaired every issue. [2]

The vulnerability exists in PHP’s runtime; it does not require a website to run an AI agent. “AI-assisted discovery” and “an AI vulnerability” are different claims. If you operate PHP without any AI features, the patch question still applies.

For the separate risks of giving AI access to files or browser sessions, read our computer-use agent security guide. Keeping those subjects separate makes both security stories more accurate.

09 / The story

The next step: verify the running service

Start with the official PHP advisory, match your branch or vendor package to both fixes, replace running workers, and verify normal application behavior. Keep an inventory of completed and incomplete rollouts. Do not wait for a perfect public attack count before addressing a confirmed critical runtime flaw. [1]

This article is defensive educational reporting, not an incident-response service or a guarantee that a server is clean. We reviewed public sources on October 22, 2026; we did not test an exploit, audit readers’ servers or independently reproduce the memory bugs.