Skip to main content
Start freeLog in
← Back to blog
Vulnerabilities and Threat Intelligence5 min read

CISA Confirms PHP2Shell Exploitation: How Researchers Traced Attacks From HTTP Requests to Shell Execution

CISA has added the two PHP2Shell flaws to its known-exploited catalog. Public honeypot evidence connects malicious HTTP requests, leaked PHP memory, and Apache-spawned shells. Here is how researchers confirmed execution, what the evidence does not establish, and which PHP updates defenders should deploy.

#PHP2Shell#CISA#KEV#PHP#ThreatIntelligence#IncidentResponse
CISA Confirms PHP2Shell Exploitation: How Researchers Traced Attacks From HTTP Requests to Shell Execution

October 27, 2026

The PHP2Shell vulnerabilities have moved beyond laboratory demonstrations. According to The Hacker News, CISA added CVE-2026-109618 and CVE-2026-109619 to its Known Exploited Vulnerabilities catalog on October 26, confirming active exploitation. The report identifies October 29 as the federal remediation deadline.

The clearest publicly available evidence comes from instrumented honeypots: researchers connected incoming HTTP requests, leaked process memory, and unexpected shell execution into a documented sequence. However, that evidence has a narrower scope than some headlines suggest.

What Is PHP2Shell?

PHP2Shell covers two critical vulnerabilities in PHP's handling of interrupted requests, both rated CVSS v4.0 9.2:

  • CVE-2026-109618: memory exhaustion can interrupt initialization, leaving invalid internal data that request cleanup subsequently uses.
  • CVE-2026-109619: internal request state can remain accessible after its underlying memory has been freed, potentially affecting later processing.

The PHP security advisory warns that affected web deployments include PHP-FPM, Apache with mod_php, php-cgi, FrankenPHP, and LiteSpeed. It identifies mod_php as the highest-risk environment, with demonstrated exploitation that can begin before application code executes.

These are runtime vulnerabilities. Updating a CMS plugin alone does not repair them.

How Exploitation Was Detected

Adel Karimi, identified by The Hacker News as Perplexity's detection and response lead, published a packet-to-process investigation of October 24 activity.

The honeypots recorded traffic in both directions, Apache requests and worker identities, PHP errors, and Tetragon process events. Researchers correlated these records using timestamps, source ports, request sequences, and worker identity. No single alert or HTTP status was treated as proof.

The resulting evidence established three important links:

  1. Suspicious requests reached the PHP runtime. Multipart requests coincided with memory-exhaustion errors during request startup, before the application's own code ran.
  2. Memory disclosure actually reached the client. Oversized PHPSESSID cookies decoded to 800 KiB each and contained pointer-like data rather than ordinary session identifiers. Packet reconstruction established complete delivery and client acknowledgment for 51 of 52 recorded disclosure-sized responses.
  3. Later requests were followed by shell execution. Tetragon recorded /bin/sh processes directly parented by Apache workers. In several cases, additional child processes independently confirmed that commands ran.

The report correlates 35 execution-stage HTTP requests with 35 Apache-parented shell starts across three honeypot targets. These are repeated observations on three systems, not 35 compromised organizations.

Researchers also found that values in later execution payloads tracked the memory addresses disclosed by individual targets. That supports a leak-guided exploitation technique adapting to randomized memory layouts, rather than merely sending a generic request that happened to crash PHP.

What CISA's Confirmation Does Not Explain

CISA's catalog addition and the public honeypot investigation are related developments, but they should not be presented as a documented intelligence-sharing chain.

The reviewed public sources do not establish exactly what evidence CISA received, who supplied it, or whether Karimi's report was the decisive basis for inclusion. The defensible account is that public exploitation evidence preceded the reported catalog addition.

There is also an important CVE distinction: Karimi's detailed report says the observed chain is consistent with CVE-2026-109618 and does not establish a separate CVE-2026-109619 exploitation path. CISA reportedly listed both vulnerabilities, but this individual dataset should not be used to claim that it independently proves both.

Limits of the Evidence

The successful attacks targeted PHP 8.4.26 under single-worker Apache mod_php, with a 128 MiB PHP memory limit. The researcher explicitly describes this as an intentionally favorable configuration. It does not measure reliability across other worker counts, PHP builds, or applications.

The recorded shells ran with the Apache worker's privileges, not automatically as root. Commands attempted identity checks, file writes, and outbound retrievals, but the reviewed evidence contained no observed downloaded second-stage file.

Two source-address clusters appeared in successful activity. That does not establish two separate attackers, a shared operator, or nation-state attribution.

Reporting also requires attention to corrections. In an updated article, The Hacker News records Unit 42's withdrawal of an earlier assessment linking a European government intrusion specifically to PHP2Shell. A compromised application running vulnerable PHP is not, by itself, proof of the initial-access vulnerability.

What Defenders Should Do

PHP released fixes for the two original vulnerabilities on October 21:

  • PHP 8.2: 8.2.35.
  • PHP 8.3: 8.3.36.
  • PHP 8.4: 8.4.27.
  • PHP 8.5: 8.5.12.

Deploy these or newer patched releases, or vendor-confirmed backported packages. Restart affected workers and verify the runtime serving web requests, not merely the command-line PHP installation.

Also review PHP's October 23 follow-up advisory concerning CVE-2026-115560, a separate issue involving an unusual session-serializer configuration. Its guidance should not be confused with the fixes for the two KEV-listed vulnerabilities.

For investigation, correlate abnormal multipart traffic, startup memory errors, oversized session-cookie responses, worker crashes, and unexpected child processes. A crash alone does not prove execution, and a missing completed access-log entry does not exclude it: the honeypot report documented workers that started shells before crashing.

The central lesson is evidentiary as well as operational. Scanning shows interest; crashes show failure; correlated network and process records can demonstrate exploitation. PHP2Shell now warrants urgent patching alongside investigation for both memory disclosure and unauthorized execution.

Sources

This article reflects sources reviewed on October 27, 2026. CISA's catalog addition and deadline are attributed to The Hacker News; the technical evidence and PHP remediation guidance were checked against the original researcher report and vendor advisories.