PHP2Shell After the Patch: The FAQ for Verification, Detection and Response

Follow-Up to Our October 22 Analysis

Our earlier post, PHP2Shell: Two Critical Core PHP Flaws Enable Unauthenticated RCE Across the Web, explained how the two flaws work, what researchers demonstrated, and the first round of mitigation steps. This post focuses on the follow-through: verifying fixes, assessing mitigations, investigating earlier compromise, and tracking the third CVE.

Patch Verification: Confirming Remediation Across Your Environment

PHP is rarely deployed in a single location. Each layer below has a different owner and a different verification method.

A repeatable verification process follows these steps:

Why does php -v report an outdated version after patching?

Linux vendors often backport a security fix without changing the upstream version number, so a patched package can report an older version. Confirm the fix through your vendor’s advisory or the package changelog, and look for both CVE identifiers. The upstream fixed releases are 8.5.12, 8.4.27, 8.3.36 and 8.2.35, but distribution packages may be numbered differently.

Does patching the host also remediate containers?

No. A container carries its own PHP interpreter, so patching the host changes nothing inside it. Every running container built from the old image remains vulnerable until it is rebuilt and redeployed.

Is a restart required after updating?

Yes. Restart or replace every long-running worker, including web server modules and PHP-FPM pools. A server that has installed the fix but not restarted is still running the old code in memory.

What should be confirmed with a hosting provider or vendor?

Ask your provider or software vendor the following four questions, and obtain the answers in writing:

• • Which PHP version or package is running now, and when was it applied?
• • Were all workers restarted or replaced afterwards?
• • How does your plan cover PHP 8.1 or earlier?
• • Has the environment been checked for exploitation activity back to the earliest reported attempts?

The written responses also serve as audit evidence. Record when each system was identified, patched and validated.

What options exist for PHP 8.1 and earlier?

PHP made no official release for these branches. It published minimal source backports for 7.4 through 8.1, which help if you build from source. Otherwise, check whether your distribution or long-term-support vendor supplies a fixed package, or upgrade to a supported branch. Independent analysis warns that vendor fixes for older branches may be slower, because vendors have more validation work to do. CISA’s guidance is that systems that cannot be updated quickly, or that still run PHP 8.1 or earlier, should be considered candidates for being taken offline until fixed.

Is PHP 8.2.35 suitable as a long-term target?

It fixes these flaws, but PHP has said 8.2 reaches end of life on December 31, 2026 and will receive no security fixes after that. Treat it as an interim step toward a newer branch.

Mitigations: Effectiveness and Limitations

PHP’s position is clear: there are no complete mitigations, and updating is the only safe choice. Interim controls still have a role, provided their tier and limitations are understood.

What are the limitations of the partial-mitigation tier?

Setting memory_limit=-1 shifts memory exhaustion to the operating system, and allocation failures can still occur. Do not substitute process limits such as RLIMIT_AS or RLIMIT_DATA, because they can trigger the same failure path. Independent analysis also found that the upload-progress setting does not fully protect a system on its own. Treat both as risk reduction while patching is completed.

Should session upload progress remain disabled after patching?

Yes, for the time being. PHP’s advisory for CVE-2026-109619 recommends keeping it disabled even after patching, and PHP recommends keeping it off until the next release to block the vector behind CVE-2026-115560. This is hardening, not a substitute for the fix. The side effect is that progress bars built on this feature stop working, so confirm whether your application uses session-based upload progress before disabling it. Many applications do not.

Do WAF or CDN protections mitigate the risk?

Partially, and only as a temporary measure. A major CDN provider described its rules as a stopgap and said it kept updating them as attackers changed their payloads. Two practical limitations apply. First, a rule cannot inspect what the engine truncates, discards or handles differently, such as oversized bodies, dropped fields or chunked requests, so confirm what your inspection engine actually evaluates. Second, protection applies only to traffic routed through the service. If your origin server can be reached directly, attackers can bypass the edge.

Should affected systems be taken offline?

That is a business decision, but the guidance from government agencies is consistent: if an internet-facing system cannot be patched, restricting or isolating it is a legitimate response. If a system is taken offline, define what “restored” means before it returns to service: runtime verified as fixed, workers restarted, and the lookback below completed.

The Third CVE: CVE-2026-115560

On October 23, PHP published an informational advisory for another remote code execution issue. The October 21 releases do not fix it. A fix is planned for PHP’s next regular release.

Is CVE-2026-115560 part of PHP2Shell?

Some media coverage refers to it as a third PHP2Shell vulnerability. PHP treats it as a separate issue and is handling it in the normal release cycle because it considers the required setup unlikely in practice. Until PHP says more about the root cause, we describe it as reported alongside PHP2Shell, not as part of it.

What action is recommended now?

Keep session upload progress disabled, and add PHP’s next regular release to your patch calendar. Do not assume it will be minor: the severity and affected versions have not been published. Plan for the next release as a scheduled patch rather than an unplanned event.

Detection and the Lookback Window

No single signal proves exploitation, so correlate three layers. These signals come from independent analysis of public proofs of concept:

Example log patterns (values vary by configuration):

Some of these fields can appear in legitimate traffic. PHP documents the upload-progress field in browser forms, and session handling can add session identifiers to forms. Build a baseline from your normal submissions and investigate departures from it.

Does the absence of crashes or error responses indicate a system is unaffected?

Not necessarily. In a documented reproduction, the request returned HTTP 200 and the same worker continued running after the command executed. A complete attack can generate as few as two to four memory-exhaustion errors and then generate no further errors. A worker that launches a shell is the most direct sign of successful exploitation.

How far back should log review extend?

The earliest reported activity comes from AWS. Amazon Threat Intelligence said its MadPot honeypot network logged a PHP2Shell exploitation attempt on October 17, four days before public disclosure, and noted it was unclear how the attacker obtained exploit information. AWS recorded further attempts on October 21, with payloads and infrastructure suggesting more than one actor, and said it was unclear whether those attempts would have succeeded against real systems. These are observed attempts from a single source, not confirmed compromises. AWS recommends starting investigations from at least October 17 rather than from the disclosure date.

The right window depends on your risk tolerance and how far back your retained logs go. We suggest three tiers:

The green line marks the October 21 patch release. Bars show where each window starts, not log volume, and positions are illustrative.

For most internet-facing systems, we recommend the conservative window where log retention allows it, and the maximum window for high-value systems. The October 17 date rests on AWS’s honeypot observation, so treat it as a prudent boundary rather than an established fact. If your logs do not reach back far enough, record the gap so that it remains visible in any later review.

Does patching remove an existing attacker foothold?

No. The fix closes the vulnerability but does not undo access gained earlier. If you find evidence of exploitation, treat the host as compromised rather than merely exposed: preserve web server and PHP logs, follow your incident response process, and rebuild from a known-good image.

Which credentials should be rotated after patching?

That depends on how likely exposure was, but these flaws can allow an attacker to read memory from a worker. For internet-facing PHP hosts that ran unpatched during the exposure window, consider rotating:

• • Database credentials and API keys available to PHP workers
• • Session secrets and authentication tokens
• • Private keys and certificates on the host
• • Cloud or CI credentials stored in environment variables or configuration files the application can read

This is a precaution, not a requirement from the advisories. Weigh it against the cost of rotation and the sensitivity of what the worker could reach.

Risk Context and Trends

Is PHP2Shell being exploited in the wild?

Exploitation attempts have been reported. Confirmed compromises have not been publicly reported. AWS reported that PHP2Shell is now being broadly exploited, with attempts beginning before disclosure. As of October 26, public reporting had not confirmed any successful compromise, and neither CVE had been added to CISA’s Known Exploited Vulnerabilities catalog. Absence of public confirmation is not proof that no one was compromised, so treat internet-facing, unpatched systems as potentially exposed.

Why is the score 9.2 rather than 10, and does it affect prioritization?

PHP rates both PHP2Shell flaws CVSS v4.0 9.2. A score of 10.0 circulated early and was incorrect. The number describes the severity of a successful attack, not how widely it can be attempted, and the first reported attempt predated disclosure. The difference between 9.2 and 10 is not a reason to delay remediation.

Why do exposure estimates vary so much?

Public estimates range from roughly a million exposed hosts to more than twenty million. The gap comes from what each method counts: hosts that reveal a PHP version, hosts with open ports, or all exposed PHP instances. The number that matters for your organization is your own count of web-serving PHP runtimes, including undocumented or forgotten deployments.

Have threat actors exploited PHP vulnerabilities before?

Yes. CISA’s catalog already lists three PHP vulnerabilities, and two of them are known to have been used in ransomware campaigns. That history indicates that ransomware operators have targeted PHP flaws before.

Should further vulnerabilities of this type be expected?

Independent analysis expects so. Even the patched code still updates a hash table’s counters before allocating the memory they describe. The fix changes the surrounding error handling instead, so the same pattern could appear elsewhere. A further PHP issue was disclosed within two days of the emergency release. That is consistent with this expectation, although PHP has not said the two are related. The researchers credited with the discovery have also said AI models contributed to their work, which suggests exploit development timelines may continue to shorten.

Instantly Fix Risks with Saner Patch Management

Saner patch management is a continuous, automated, and integrated software that instantly fixes risks exploited in the wild. The software supports major operating systems like Windows, Linux, and macOS, as well as 550+ third-party applications.

It also allows you to set up a safe testing area to test patches before deploying them in a primary production environment. Saner patch management additionally supports a patch rollback feature in case of patch failure or a system malfunction.

Experience the fastest and most accurate patching software here.