Black October: Investigating Critical Vulnerabilities- PHP2Shell
Part 1 — PHP2Shell: From an HTTP Request to Remote Code Execution
A critical vulnerability announcement usually starts with a CVE number, a severity score, and an urgent recommendation to patch.
For incident responders, the next question is harder: Could someone have exploited this in our environment, and what evidence would help us find out?
This October investigation series starts with PHP2Shell. Before looking for signs of exploitation, let’s understand how an HTTP request can become a memory-safety problem inside PHP.
What Is PHP2Shell?
PHP2Shell covers two related vulnerability classes in PHP itself:
- CVE-2026–109618: Memory corruption caused by out-of-memory handling.
- CVE-2026–109619: Stale internal state surviving across requests.
They are separate issues, rather than two mandatory stages of one exploit. Their exploitability depends on the runtime, configuration, and reachable application behavior.
First, Imagine an Office Worker
Think of a PHP worker as an office employee processing incoming requests.
Each request is a new assignment. The employee places the necessary documents on a desk, works through them, and clears the desk when finished. The same employee can then handle another assignment.
In this analogy:
Think of a PHP worker as an office employee processing assignments. Each incoming HTTP request is a new assignment, and the documents placed on the employee’s desk represent the request data stored in memory.
To remember where a document is, the employee writes down its location. This note works like a pointer: it tells PHP where to find data in memory. When the assignment is finished, the employee clears the desk, just as PHP releases the memory used by a completed request.
Problems arise if the employee is interrupted halfway through preparing the documents, or clears the desk but keeps an outdated note. During the next assignment, they might follow that note and mistake a new document for the old one.
Two things can go wrong: the employee may be interrupted halfway through preparing the documents, or may clear the desk while keeping an outdated note about where a document is located.
These illustrate the two vulnerability classes.
The First Problem: An Interrupted Assignment
Imagine the employee preparing a folder. They record that it contains a document, but are interrupted before they finish placing that document inside.
Later, someone tidying the desk trusts the folder’s record and tries to process its contents. They assume the preparation was completed.
The mismatch is the problem: the recorded state says the document is ready, while the actual contents are unfinished.
In PHP, an out-of-memory error can interrupt an operation while internal structures are partially initialized. Vulnerable versions can use longjmp() to leave that operation immediately. Cleanup may then trust the unfinished state and act on invalid memory. This is the core of CVE-2026-109618.
How Can an HTTP Request Exhaust Memory?
A short set of instructions can create a large amount of office paperwork. “Create a folder and an index entry for each item” may require far more desk space than the instruction itself.
Similarly, the size of an HTTP request does not equal the RAM PHP needs to represent it. Multipart requests, commonly used for uploads, can generate enough internal structures to exhaust memory while remaining within apparent request limits.
The Second Problem: Keeping an Outdated Note
Now imagine the employee writing:
“The customer’s document is in the top-right corner of my desk.”
The assignment ends, and the document is removed. However, the employee keeps the note.
During the next assignment, a different document occupies that location. The employee follows the old note and treats the new document as the original.
The location still exists, but its contents no longer belong to the previous assignment.
CVE-2026–109619 follows this pattern: a worker retains a reference to request-owned memory after that memory is freed. A later request on the same worker can use the stale reference before initialization resets it. This is a use-after-free.
How Does This Become Code Execution?
The attacker’s challenge is to influence what PHP encounters through the invalid state. In the office analogy, that means influencing which document replaces the old one and how the employee interprets it.
The analogy stops there: actual exploitation involves controlling memory layout and program behavior. A crash alone does not demonstrate that control.
PHP’s advisories confirm remote code execution under demonstrated conditions, with the privileges of the web worker account.
Why the Runtime Matters
Apache mod_php can reach vulnerable cleanup after startup failure, before application code executes. PHP-FPM terminates the worker on startup failure, blocking that sequence.
However, a validated FPM path for the stale-state issue begins during application execution and requires suitable application behavior. Using FPM therefore does not establish immunity.
How I Would Approach an Incident Investigation
Understanding the mechanism helps define the investigation. The following workflow describes how I would assess an environment; it does not claim that a particular system was compromised.
Get Saniye Nur’s stories in your inbox
Join Medium for free to get updates from this writer.
I would organize the investigation around three questions:
- Were we exposed?
- Is there evidence of an exploitation attempt?
- Is there evidence of successful exploitation?
1. Establish the Exposure Window
Start with the PHP runtime actually serving web traffic.
Record its package revision, vendor patch status, execution model, relevant configuration, and application routes. Include containers, secondary pools, and older instances still receiving traffic.
A CLI version check alone does not establish what every web worker is running. A package installation timestamp also does not prove that existing workers were replaced.
Build a timeline covering:
- Deployment of the affected runtime.
- Its accessibility during the review period.
- Deployment of the fixed package or image.
- Restart or replacement of serving workers.
Account for vendor backports rather than judging patch status solely by the upstream version number.
2. Preserve Evidence and Understand Visibility
Collect relevant reverse proxy, web server, PHP, endpoint, and network telemetry before retention limits remove it.
Establish what each source captures. Access logs may contain request metadata without bodies. Error logs may omit relevant severities. Short-lived containers may already have disappeared.
Record these limitations early. They determine which questions the investigation can answer confidently.
3. Correlate Requests with Runtime Failures
Review multipart traffic and unusual request patterns alongside memory errors, fatal errors, worker exits, and crashes.
Compare them with normal application behavior. An upload service naturally receives multipart requests, and an ordinary application defect can cause memory exhaustion.
A multipart request or an OOM message alone does not prove exploitation.
Use candidate events to define investigation windows. Where possible, correlate by timestamp, host, container, route, request identifier, and worker PID. Worker-level correlation is especially useful when assessing behavior spanning multiple requests.
4. Investigate What the Worker Did Next
For each candidate window, examine subsequent activity:
- Unexpected child processes or command interpreters.
- Unusual outbound connections.
- New or modified files in web roots and temporary directories.
- Access to credentials or sensitive configuration.
- Subsequent use of service identities from unexpected sources.
Validate findings against legitimate behavior. Some applications intentionally launch external programs. Process ancestry, command arguments, timing, and surrounding events help distinguish expected activity from suspicious execution.
Do not require a dropped web shell before investigating possible compromise. Process and network evidence may be relevant even when no suspicious file is found.
5. Keep Exposure, Attempts, and Compromise Distinct
An affected runtime establishes exposure. Suspicious requests may support an attempted-exploitation assessment. Evidence linking those requests to unauthorized execution supports a stronger conclusion.
If nothing suspicious is identified, describe the scope accurately:
No evidence of successful exploitation was identified in the telemetry reviewed for the specified period.
Then document material visibility gaps. Missing request bodies, incomplete endpoint coverage, or expired logs should shape the confidence of the conclusion.
For PHP2Shell, the investigation should connect incoming requests, PHP worker behavior, and subsequent host activity. That connection turns a vulnerability review into an evidence-based incident assessment.
References
- PHP advisory: CVE-2026–109618 — RCE via OOM corruption
- PHP advisory: CVE-2026–109619 — RCE via stale global state
