PHP2Shell: Three Critical Vulnerabilities, One Uncomfortable Lesson

On October 21, 2026, the PHP project shipped an emergency patch for two bugs rated 9.2 out of 10. Two days later, a third one landed. Both of the first two can let an attacker execute code on your server without ever logging in and the fix came out a day earlier than planned because the CVE numbers leaked onto social media.

This is PHP2Shell, and it is the kind of story that quietly affects a very large slice of the internet. WordPress, Drupal, Magento, Laravel apps, countless custom back-ends ,they all sit on top of PHP. A flaw in the language itself can bypass application-level security entirely.

What happened

PHP is the server-side programming language that powers an estimated three out of four websites with a known server-side language. A vulnerability in PHP therefore affects many applications, even when their developers have written secure code.

The October 21 security release addressed two critical vulnerabilities, CVE-2026–109618 and CVE-2026–109619, each rated CVSS 9.2 under CVSS v4.0. Both allow unauthenticated remote code execution.

The patched versions are PHP 8.5.12, 8.4.27, 8.3.36 and 8.2.35. Vulnerable code goes back as far as PHP 5.4, so end-of-life branches (5.x, 7.x, 8.0, 8.1) remain exposed unless a distribution has backported a fix.

On October 23, a third vulnerability, CVE-2026–115560, was disclosed. It is configuration-dependent and the PHP Security Team describes it as an unlikely RCE vector, but it still has an official CVE and an official mitigation.

The vulnerabilities affect every PHP deployment that serves web requests: PHP-FPM, Apache with mod_php, php-cgi, FrankenPHP and LiteSpeed. The PHP team considers mod_php the highest-risk configuration , exploitation there can be triggered by a single unauthenticated request before any application code runs. In other words, your application's own security checks never get the chance to intervene.

A demonstrated exploit shows one unauthenticated HTTP request can trigger the attack before any application code runs. — PHP Foundation

How the vulnerabilities work

CVE-2026–109618 — when running out of memory becomes dangerous

PHP enforces a user-configurable memory_limit to stop any one request from consuming the server. When a request hits the limit, PHP aborts it. The vulnerability is in what happens when that abort fires at exactly the wrong moment,for example, while PHP is still parsing a file upload and internal data is only partially initialised. Request cleanup can then treat that invalid state as valid and free memory that was never properly set up. That memory may still contain attacker-controlled data from an earlier allocation.

Think of a worker assembling a package who runs out of workspace halfway through the job. If the cleanup process assumes every component was recorded correctly, it will mishandle incomplete information and in software, mishandled memory is often all an attacker needs.

The lesson: error handling is a security boundary. Software must stay safe not only when everything works, but also when operations fail unexpectedly.

CVE-2026–109619 — when old memory state survives

The second vulnerability is a use-after-free in PHP's global request state. When a fatal error occurs at the wrong point, internal state owned by that request can keep pointing at memory that has already been freed. A later request handled by the same worker then picks up that stale state before normal initialisation resets it.

Imagine a hotel room reassigned to a new guest while an old key card still works. If the front desk trusts the stale record, it will act on information that is no longer valid.

The reporter demonstrated remote code execution against a real-world application running on Apache with mod_php ,this is not a theoretical exploit.

The lesson: memory must be managed correctly across the entire request lifecycle, including failures and the transitions between requests on long-lived workers.

The latest update: a third vulnerability

On October 23, the PHP Security Team disclosed CVE-2026–115560, a remote code execution path through session upload progress combined with runtime changes to session serialization. Unlike the first two bugs, this one requires an uncommon combination of configuration and application behaviour.

The documented attack path requires an application that:

· sets session.serialize_handler to php_binary or php_serialize in its configuration,

· switches it to php at runtime using ini_set() before calling session_start(),

· and leaves session upload progress enabled.

Applications that never change the serialize handler at runtime are not exposed. The PHP team is shipping the full fix in the next regular bugfix release rather than a second emergency release.

Until that release, the recommended mitigation is to disable session upload progress:

session.upload_progress.enabled = 0

Apply it in php.ini, an FPM pool, or your server configuration, then restart every worker. Do not rely on ini_set() or .user.ini — those apply too late to help here. If you already applied this mitigation after October 21, keep it in place: no further action is needed for the third CVE.

This mitigation does not replace the original security updates. You still need to patch CVE-2026–109618 and CVE-2026–109619.

Why this matters

Remote code execution means an attacker can run commands with whatever permissions the compromised process has. Realistic consequences include:

· Data exposure: access to application data, configuration files and stored credentials.

· Website tampering: modification of content or application files.

· Persistence: installation of backdoors to regain access later.

· Lateral movement: using a compromised server to pivot into internal systems.

· Disruption: interrupting services or destroying data.

These are possible consequences, not evidence that every vulnerable server has already been compromised. It is worth distinguishing between a vulnerability existing, an exploit being technically possible, and an attacker successfully breaching a real system. Public assessments differ on whether successful in-the-wild exploitation has been confirmed, though proof-of-concept code and exploitation attempts have been widely reported.

Do not panic, but do not wait for confirmed breaches before acting.

Why this happened

The incident is worth looking at as more than just a patch cycle.

Vulnerabilities can remain unresolved for years

The PHP Foundation has confirmed that the earliest signs of CVE-2026–109618 were spotted in 2024 during PHP's first external security audit in years, carried out by Quarkslab and organised by OSTIF with funding from the Sovereign Tech Agency. A potential OOM exploit was theorised at the time, but no concrete attack vector was found and other issues took priority. In August 2026, researchers at Calif rediscovered the problem and built a working RCE.

A flaw that looks theoretical today can become exploitable tomorrow once someone finds a new trigger point.

Applications inherit risk from their dependencies

You can secure every line of your own code and still be exposed through the runtime, framework, operating system, library or container underneath it. That is why software inventories and dependency monitoring matter: you need to know where PHP runs, which versions are deployed, and who is responsible for updating them ,including inside third-party appliances and vendor products that bundle PHP.

Releasing a patch is only half the job

A fix must be developed, tested, released, deployed and verified. A patch that exists but has not reached production does not protect anyone. The gap between a vulnerability being identified and every affected asset being remediated is still one of the hardest problems in security.

What organisations should do now

Identify affected systems

Check internet-facing applications, servers, containers, build images, managed hosting environments and third-party products that may bundle PHP. Do not assume an asset is safe just because PHP is not explicitly listed in its documentation.

Patch and verify

Upgrade to PHP 8.5.12, 8.4.27, 8.3.36, 8.2.35 or a vendor-supported backport for 8.1 and earlier. Confirm the runtime actually serving requests is the patched one and that all workers have been restarted.

Apply the third-CVE mitigation

Review whether the configuration conditions for CVE-2026–115560 apply to any of your applications. Where recommended, disable session upload progress (session.upload_progress.enabled = 0) until a fixed release ships.

Contain exposure if patching is delayed

If a critical, exposed system cannot be patched immediately, follow vendor guidance and consider restricting or isolating public access until remediation is complete. A web application firewall or configuration workaround is not a substitute for patching.

Investigate possible compromise

Review web server and application logs for suspicious activity, unexpected processes, unexplained file changes, unusual outbound connections, and signs of backdoors. If you suspect compromise, preserve evidence and follow your incident-response process. Patching does not automatically remove an attacker's existing persistence.

What this means for everyday users

If you use websites built with PHP, there is no reason to assume your accounts have already been compromised. Your real risk depends on whether a service you use was vulnerable, whether it was successfully exploited, and what information that service could access.

Keep doing the basics: unique passwords, multi-factor authentication, up-to-date devices, and an eye on unusual account activity. Beyond that, securing the servers is the website operator's job, not yours.

The bigger lesson

PHP2Shell is a reminder that cybersecurity is not just about suspicious logins, malicious IPs or application code. It is also about memory management, error handling, software supply chains, and the ability to respond quickly when new weaknesses appear.

Open-source software is not inherently insecure ,its transparency is exactly what let researchers find and fix these bugs. But widely used projects need sustainable funding, security expertise and effective vulnerability management to match the responsibility they carry.

The third vulnerability drives the point home: security work does not end when the first patch is released. New information can change the assessment, and organisations must keep reassessing their exposure.

Security is not achieved when a patch is announced. It is achieved when vulnerable systems are identified, fixes are applied, and the possibility of prior compromise is taken seriously.

The most important question is not whether your organisation uses PHP. It is whether you know where it runs, whether it is patched, and whether you can verify that it is safe.