DEV Community

Ioneyrezende
Ioneyrezende

Posted on

PHP2Shell: a patch-verification and hunting plan for the four days before disclosure

#php #php2shell #cve2026109618 #cve2026109619

PHP2Shell: a patch-verification and hunting plan for the four days before disclosure

On 17 October 2026, four days before PHP published fixes for PHP2Shell, Amazon's MadPot honeypots recorded the first exploitation attempt. The source traffic came from an anonymised IP address. That observation resets the response. Somebody outside the embargo already had enough detail to try, so this is not a patch-and-close-the-ticket cycle.

What the two flaws are

PHP2Shell is a pair of remote code execution bugs published as CVE-2026-109618 and CVE-2026-109619, both rated 9.2 under CVSSv4. Researchers from Calif, OpenAI and Wiz are credited with the findings. The two flaws share a root cause: PHP can leave memory corrupted when a request ends abnormally.

  • CVE-2026-109618 chains weaknesses into an out-of-memory condition that leads to code execution as the web worker account.
  • CVE-2026-109619 relies on stale global state, producing a heap use-after-free, memory disclosure and remote code execution. Neither requires authentication. Both affect every PHP 8.2 through 8.5 release before the fixed versions, and the reach spans PHP-FPM, Apache mod_php, php-cgi, FrankenPHP and LiteSpeed. PHP's own team rates mod_php as the highest-risk configuration, because an unauthenticated request can trigger the attack before any application code runs. The ordering matters. Application-layer guards and framework middleware sit behind the vulnerable code path. Fixed releases are PHP 8.5.12, 8.4.27, 8.3.36 and 8.2.35. PHP 8.1 and older receive no official updates, although the project published minimal source backports for 7.4, 8.0 and 8.1. Backports are source material rather than a binary fix, and each distribution or LTS vendor decides whether its packages carry them. One fact is unresolved. Amazon traced the earliest attempt to 17 October, but it remains unclear how the actor obtained exploit details during the embargo. Treat that gap as a reason to hunt.

The exploitation timeline

Public proof-of-concept code appeared around 02:00 UTC on 21 October, roughly twelve hours before the embargo lifted. More PoCs followed within hours of the patch release, and Amazon reported seeing them used against its sensors almost immediately. Payload variety suggests multiple actors rather than a single operator.
Cloudflare measured the same surge from the network side. Its CEO described volumes moving from thousands of attempts before the announcement to tens of thousands within 45 minutes, hundreds of thousands within two hours, and millions by the time of the statement. Independently, the source material cites VirusTotal estimates of more than 5.1 million exposed PHP hosts. Both figures come from vendor statements; neither is a substitute for your own inventory.

Verifying the patch actually landed

The gap between "we updated the package" and "the vulnerable process is gone" is where most organisations will fail this cycle.

  1. Enumerate the server API per host. PHP-FPM, mod_php and php-cgi have different process models and different restart steps. A host can run an updated CLI binary while an old FPM master keeps serving requests.
  2. Check the binary the service actually executes, not the one on the default PATH. Containers pinned to an older image digest keep the vulnerable build even after the host is patched.
  3. Restart every worker after the upgrade. For FPM, that means the master process; for Apache with mod_php, the web server workers. Confirm the new process start time.
  4. Prove the result with a version query issued through the web SAPI, not from a shell that may resolve a different binary.

Interim reductions while the patch waits

If a change freeze blocks the upgrade, several configuration changes lower exposure. The source material recommends setting memory_limit=-1 and a low post_max_size, disabling session.upload_progress.enabled, and on PHP 8.5 disabling fatal_error_backtraces. Blocking multipart uploads is a further option after testing the impact on legitimate features.
Each of these reduces exposure. None of them blocks the attack. With working public exploits, the patch remains the only complete fix, and a configuration workaround is a timer, not a solution.

Hunting from 17 October

Set the start of the hunting window to 17 October, not to the disclosure date. Look for processes spawned by web workers that do not match the application's normal pattern, file changes under document roots, new files in temporary upload paths, and outbound connections initiated by the PHP user toward hosts outside your expected egress set. Web-server access logs alone rarely settle the question, because the triggering request may look ordinary.
Keep a record of which hosts were restarted, when, and by whom. If a later incident review asks whether a host was exposed on 20 October, that record answers it faster than a vulnerability scanner report.

What remains uncertain

The source material does not explain how the pre-disclosure actor obtained exploit details, does not describe the specific payloads used against honeypots, and does not establish how many internet-facing hosts were compromised rather than merely probed. The backport status for individual Linux distributions is also outside what the reporting establishes. Plan for those unknowns rather than assuming them away.

References

Top comments (0)