PHP2Shell Aftermath: Risks, Fixes and False Positives

The original PHP vulnerabilities require somewhat prompt action. However, identifying an older PHP version in an HTTP response does not establish that a website remains vulnerable.

That distinction matters when findings become public shaming lists, supplier warnings or urgent demands for remediation. Security reporting should help organisations make better decisions. Overstating the evidence as so many appear to be doing, makes that considerably harder.

What's happened since the disclosure....

On 21 October, PHP released fixes for CVE-2026-109618 and CVE-2026-109619 in versions 8.2.35, 8.3.36, 8.4.27 and 8.5.12. The vulnerabilities concern memory exhaustion and internal state surviving between requests, with potential for unauthenticated remote code execution.

Attack activity has inenitably followed. Amazon reported an exploitation attempt in their honeypot telemetry dated 17 October, before the public disclosure, followed by a significant rise in attempts after the release. They  stated that it was unclear whether those attempts would have actually succeeded against the majority of real-world systems as opposed to the staged honeypots.

An exploit attempt, successful code execution and confirmed compromise are different things. Reports have been muddying those distinctions.

Why an older version number may still contain the fix

Consider a response containing:

X-Powered-By: PHP/8.3.6

A scanner compares that with the upstream fixed release, PHP 8.3.36, and raises an alert.

While that's is a reasonable starting point, it's is insufficient evidence for the inevitably predictable 'definitive' public claim of vulberability.

Operating-system distributions and long-term-support providers commonly backport security fixes into their maintained packages. The upstream version number can remain unchanged while the package revision advances and the vulnerable code is actually corrected.

ProjectDiscovery’s own PHP2Shell guidance explicitly states: distribution, hosting and LTS packages can contain the fixes under an older version string. They recommend confirming package details and vendor fixes with the host.

An HTTP header will often omit the package revision needed to make that assessment. It cannot reveal the installed patch set, and even if it could most good setups would not.

The reverse also matters here. A reassuring header doesn't establish that every backend, container or worker has been updated.

Headers describe only what a response advertises, nothing more

Web infrastructure adds further uncertainty. A CDN, reverse proxy or cache may remove, replace or retain headers. One hostname can serve traffic from several backends with different deployment states. A homepage check may miss another application elsewhere on the same host.

The operators of one PHP2Shell checker document these limitations directly: headers cannot establish whether backports are installed, and a fixed version reported in one response does not prove the state of every server behind that URL. That doesn;t establish security assurance or a lack thereof.

When assessing make sure you understand and rightly distinguish between:

• An advertised version associated with affected upstream releases.

• A package confirmed to lack the relevant vendor fixes.

• An application confirmed to meet an exploit’s prerequisites.

• Evidence of successful exploitation or compromise.

Collapsing these into a single 'vulnerable' label loses information that operators need.

Active checks need qualification

Sending a test request does not automatically settle the question either.

Assetnote demonstrate this well by documenting circumstances in which its own PHP2Shell scanner can produce false positives. Good on them! A patched PHP instance reaching its memory limit can return the same empty HTTP 500 response used as a detection signal. They rightly advise that verifying findings against installed versions and vendor backports is required.

That is what I call a responsible disclosure of a tool’s limitations. Anyone using their tool and republishing its findings should carry those limitations forward too.

Before naming and shaming an organisation as vulnerable, a report should explain what was observed, when it was observed, the detection method and what remains unverified.

The aftermath includes a separate issue

I already wrote about this on the day of the patches. On 23 October, PHP published an informational advisory for CVE-2026-115560.

This concerns an unusual combination: an application configured with php_binary or php_serialize changes its session serialisation handler to php at runtime before starting the session, while session upload progress remains enabled.

PHP recommends disabling session.upload_progress.enabled pending its next regular bugfix release. Applications that never change the handler at runtime are not exposed through this particular path.

This deserves some serious attention but 'without' turning it into a claim that every installation running the emergency releases is exploitable. Configuration and application behaviour determine exposure to this newer issue.

What companies should be doing now

Start with an inventory of the PHP runtimes actually serving requests. Include customer-selected versions, containers, control panels and less visible applications.

Verify the full package revision against the relevant vendor advisory covering both original CVEs. Confirm that updated binaries are loaded by running services and that workers have restarted. A command-line version check alone may inspect a different runtime from the website so be sure to check properly.

Where immediate patching is difficult, apply PHP’s temporary controls: disabling session upload progress, frontend request restrictions and carefully planned memory controls. PHP remains explicit that configuration changes do not completely remediate both original vulnerabilities though, so be concious of that reality.

Investigate suspicious activity as well as patch status. Review web logs, unexpected process execution and file modifications, with investigation extending back to at least 17 October if you can. Patching prevents future exploitation of the corrected flaws; it does not resolve an earlier compromise.

The potential fallout of this extends beyond compromised servers

Successful exploitation could expose application data and credentials, disrupt services or provide a foothold for further attacks - something nation state threat actors are very adept at.

The poorly validated reporting we are seeing is creating additional harm. Public accusations can damage supplier relationships, generate unnecessary incident response resources and divert engineers from genuinely exposed systems. Repeated false alarms can also weaken confidence in subsequent warnings.

At ThreatPrevent, we believe high-confidence intelligence requires a clear connection between evidence and conclusion. A version header is useful evidence for investigation. Publishing a definitive vulnerability claim requires more.

Organisations need urgent, accurate guidance, and security companies should be able to show how their findings support the claims they make.

Be vigilant.