PHP2Shell Explained: How Critical PHP Runtime Flaws Put Websites and Infrastructure at Risk

06 November 2026
Jonathan Aquilina - Eagle Eye T
Cybersecurity , Open Source Software , Server Security , Vulnerability

A website can have its latest application updates installed and still be exposed to a runtime vulnerability underneath it.

That is the uncomfortable lesson behind PHP2Shell.

The name covers two critical vulnerabilities in PHP itself:

CVE-2026-109618 and CVE-2026-109619.

They concern memory handling and internal state, with the potential of unauthenticated remote code execution.

For administrators, developers and managed service providers (MSP), the response needs to extend beyond checking a WordPress dashboard.

It requires knowing where PHP runs, who maintains it and whether the running service actually received the fix.

The Singularity observes:

A patching process is only as complete as its knowledge of the software beneath the application.

What Is PHP2Shell?

The researchers’ PHP2Shell disclosure describes two related classes of memory safety vulnerabilities in the PHP runtime.

Researchers demonstrated unauthenticated remote code execution against WordPress, Drupal and Joomla in a test environment, alongside application independent memory disclosure.

Those applications were demonstration targets. Their presences is not a requirement for the underlying PHP flaws.

The affected component sits beneath the application.

Updating a theme, removing an unused plugin or installing the latest CMS release does not establish that the PHP runtime has been patched.

How The Two Vulnerabilities Work

Both issues involve PHP handling request memory incorrectly, but they arise through different mechanisms.

CVE-2026-109618: Out Of Memory Corruption

The PHP project’s advisory explains that an out of memory failure can interrupt processing while internal request data is only partially initialized.

PHP can then enter cleanup with invalid state and act on that data.

Under exploitable conditions, the result can be a remote code execution rather than a clean request failure.

The deployment model matters. The advisory describes a demonstrated Apache mod_php path occurring before application code begins. PHP-FPM handles failed startup differently, but the advisory still identifies susceptibility through other paths; it does not establish FPM as safe.

A failed request is not necessarily a harmless request.

CVE-2026-109619: Stale Global State

The second PHP advisory describes internal worker state retaining references to memory belonging to an earlier request.

After that memory is released, a later request handed by the same worker can encounter the stale reference before normal initialization resets it.

This creates a use after free condition.

The precise exposure depends on which operations leave the stale state behind and which later operations consume. It should not be reduced to the claim that every request against every deployment produces the same outcome.

Which PHP Versions Contain The Fixes?

The upstream releases fixing the original two PHP2Shell vulnerabilities are:

PHP branch	First upstream release containing both fixes
PHP 8.2	8.2.35
PHP 8.3	8.3.36
PHP 8.4	8.4.27
PHP 8.5	8.5.12

These are minimum fixed releases for these two vulnerabilities, rather than a permanent recommendation to remain on those exact versions.

Use the latest appropriate security update from your supported package provider.

The PHP project’s security announcement also directs administrators using distribution or long term support packages to their vendors.

A backported package may retain an older upstream version number while incorporating the fixes.

For older branches, establish whether a vendor actually supplies security maintenance. An old installation continuing to function is not evidence that it remains supported.

This Is Now An Active Exploitation Issue

Early exploit demonstrations and scanning reports need to be distinguished from confirmed attacks against operational systems.

By 3rd November 2026, Singapore’s Cyber Security Agency reported active PHP2Shell exploitation against internet exposed management interfaces on affected Palo Alto Networks firewalls.

The alert also described attackers chaining PHP2Shell with separate Linux kernel vulnerabilities to obtain root privileges.

That distinction matters: initial PHP code execution and subsequent privilege escalation are separate stages.

The advisory also identifies affected products across other vendors. Administrators should check their exact models and software releases against vendor guidance rather than assume every product from a named vendor is vulnerable.

Your PHP inventory needs to include appliances and administrative interfaces as well as websites.

Why Updating WordPress Alone Is Insufficient

A PHP application depends on several layers:

Application code and extensions.
The PHP runtime.
The web server and service configuration.
Operating system packages.
Container images or vendor firmware.

Each layer may have a different update owner.

For a hosted website, the site owner might maintain WordPress while the hosting provider maintains PHP. For a container deployment, the application team might own the image while another team operates the platform.

A useful question is therefore:

Who can demonstrate that the PHP process serving this application is running a fix build?

An application level security plugin should not be assumed to stop an attack path that can execute before the application starts.

A Practical PHP2Shell Response Plan

1. Find Every Relevant Runtime

Begin with internet facing services, then review internal applications and management interfaces.

Include hosting panels, forgotten staging sites, older customer deployments containers and appliances.

Record the owner, package source, exposure and remediation route for each asset.

An external scan can help identify exposure, but us it along side internal inventory and vendor information.

2. Apply The Correct Update

Use the remediation channel appropriate to the deployment:

Operating system packages: Install vendor’s fixed package.
Managed hosting: Obtain confirmation covering the affected account and PHP handler.
Containers: Deploy an image containing the fixed runtime.
Appliances: Install the vendor approved firmware or hotfix.
Unsupported installations: Arrange supported maintenance or migration and reduce exposure while doing so.

Do not replace an appliance’s embedded PHP manually unless its vendor explicitly supports that procedure.

3. Verify The Running Service

A package installed on disk and a process currently handling requests are different things.

Restart or replace affected services according to the deployment’s update procedure then verify the active runtime.

A command such as:

php -v

checks the PHP executable selected by the shell. It does not prove that a website uses that same binary or version.

A server may have multiple PHP branches, separate FPM pools or containers with independent runtimes.

Confirm the version and package build serving each relevant application. Avoid leaving diagnostic pages publicly accessible.

4. Rebuild And Redeploy Containers

Docker’s PHP2Shell guidance confirms that PHP images and packages are affected and that updated official and hardened images were released.

For your own deployments, verify the deployed image rather than merely checking that an updated image exists in the registry.

Refresh the base image, rebuild where required, redeploy and confirm the running workload.

Also check rollback images. Otherwise, a later recovery operation could reintroduce the vulnerable runtime.

5. Reduce Access To Administrative Interfaces

Review whether management interfaces need public internet exposure.

Prefer restricted management access, strong administrator authentication and clear separation from public application traffic.

These measures reduce reachable attack surface. They do not replace the runtime or firmware update.

The principle discussed in Zero Trust vs Traditional Security apply here: access to a sensitive service should be deliberate and limited.

6. Assess Whether Compromise Occurred

Patching prevents the fixed vulnerability from being used again. It does not remove an existing attacker foothold.

Where exposure or suspicious activity warrants investigation review:

Unexpected files, scheduled tasks or services.
Unusual web worker child processes.
Outbound connections inconsistent with the application.
Administrative access and configuration changes.
Relevant application, operating system and security logs.

Crashes or memory errors alone do not prove exploitation, and missing alerts do not prove that a system was untouched.

If compromise is suspected, preserve evidence and follow the incident response process. Consider credentials accessible to the affected service when determining the scope.

What About Temporary Mitigations?

PHP states that configuration changes reduce particular attack paths, but do not comprehensively fix the original vulnerabilities.

Its published guidance includes disabling session upload progress for confirmed session related paths.

This is not a universal PHP2Shell fix.

Likewise, request filtering or a WAF should be treated as an additional layer while remediation proceeds. Do not use the existence of a protective rule as evidence that the underlying runtime is safe.

Where patching is blocked, document the residual risk and consider restricting or suspending the affected serivce.

Keep The Follow Up Session Advisory Separate

On 23rd October 2026, PHP published an additional session upload progress advisory concerning CVE-2026-115560.

It describes a narrow combination of serializer configuration and runtime changes. PHP recommends disabling session upload progress pending the relevant bug fix release, while noting that applications which never change their serializer at runtime can retain the feature.

This is a separate issue from the original two PHP2Shell CVEs

Check the PHP advisory for its current resolution rather than assuming that every subsequent PHP report describes the same flaw.

The MSP Lesson: Record Evidence Of Remediation

For an MSP, this becomes a coordination exercise across customers, hosting companies, application owners and appliance vendors.

A useful closure record should answer:

Which asset was affected?
What fixed package, image or firmware was deployed?
Were the relevant services restarted or replaced?
How was the running version verified?
Was investigation necessary?
Who owns any remaining exception?

This is the same discipline behind avoiding common Zero Trust mistakes: controls need evidence and continued review.

The Singularity's Perspective

PHP2Shell exposes the importance of the layers users rarely see.

A website may appear current while its runtime is old. A replacement container may still use an outdated base image. A firewall my protection application traffic while its managmeent interface remains unnecessarily reachable.

The Singularity asks:

Can you identify the running component, prove it received the fix and explain what an attacker could access if it failed?

Those questions turn a vulnerability headline into a practical security response

Final Thoughts

PHP2Shell requires attention across the PHP ecosystem, including websites, container workloads and affected vendor products.

Identify the runtime. Apply the appropriate fix. Verify the running service. Investigate where the evidence and exposure justify it.

Treat unsupported installations and unresolved exceptions as owned remediation work.

Remember The Singularity is always watching.

Call To Action

Do you know which PHP versions are actually serving your websites and internal applications?

Leave your thoughts and comments down below and follow EagleEye Technology for practical cyber security analysis, and infrastructure lessons and guidance for building more resiliant systems.

Sources