Updated 26 October 2026. Technical guidance and source status reflect information available on this date.
The PHP2Shell disclosures have produced a complicated picture for defenders: urgent engine-level patches, evidence of AI-assisted discovery, confirmed execution on research honeypots, and exploitation claims that vendors later corrected. These developments belong in the same analysis, but they answer different questions.
For CTI and SOC teams, the immediate priority is to close vulnerable execution paths. The investigation then needs to connect the exposed runtime and reachable conditions to suspicious requests, execution evidence and resulting artifacts. Keeping that chain intact is how an urgent vulnerability alert becomes a defensible assessment of what happened.
Start with the right patch baseline
On 21 October, PHP released 8.2.35, 8.3.36, 8.4.27 and 8.5.12, fixing CVE-2026-109618 and CVE-2026-109619. On 23 October, it disclosed a separate session-upload-progress issue, CVE-2026-115560, pending the next regular bugfix release. This requires an unusual combination: configuration selects php_binary or php_serialize, application code switches to php using ini_set() before session_start(), and upload progress remains enabled. PHP recommends session.upload_progress.enabled=0 until the next regular bugfix; applications that never change the serializer at runtime can retain the feature.
On 26 October, Windows packages 8.2.35-1, 8.3.36-1, 8.4.27-1 and 8.5.12-1 incorporated Brotli 1.2.1 for CVE-2026-111497. The PHP runtime version remains unchanged. The relevant path is cURL automatic response decompression, disabled by default but potentially enabled by applications or HTTP clients. These are distinct remediation items. The supported-branch versions above are patch baselines; use later applicable security releases where available. PHP’s official notices
This sequence makes a single “PHP upgraded” ticket too coarse. Record the source release, vendor package or container digest, dependency rebuild and configuration decision separately. A version-only dashboard can miss the difference between an updated runtime and a fully remediated deployment.
Why request lifecycle behavior changes exposure
Both vulnerabilities have a CVSS v4.0 base score of 9.2, according to their OOM-corruption and stale-state advisories.
CVE-2026-109618: unsafe cleanup after memory exhaustion
An out-of-memory exit can interrupt PHP while request state is incompletely initialized. Shutdown may then consume that invalid state. The advisory documents unauthenticated, pre-application exploitation against Apache mod_php. PHP-FPM terminates its child when startup fails, interrupting that particular sequence, but application-stage susceptibility remains; the advisory does not demonstrate a complete FPM exploit for this vulnerability.
The fix replaces the abrupt OOM jump with deferred handling at a VM-safe point, backed by immediate process exit at a higher memory threshold. Normal request-size limits do not remove this lifecycle defect. Official OOM-corruption advisory
CVE-2026-109619: stale state crossing request boundaries
Here, a worker retains pointers to memory owned by a completed request. A later request reaching the same worker can use that state before initialization resets it, creating a use-after-free. Exploitation requires a suitable producer of stale state and a subsequent consumer.
Session-lifecycle exploitation is confirmed for both mod_php and PHP-FPM; the validated FPM path depends on an appropriate application operation after successful startup. The complete state-reset patch is the reliable remedy. Configuration changes cover particular paths, not the entire vulnerability. Confirmed execution occurs with web-worker privileges, rather than automatically providing root access. Official stale-state advisory
These differences make deployment architecture part of the exposure assessment. Inventory the actual web-serving runtime and server application programming interface (SAPI) for each route, including virtual hosts, FPM pools, alternate containers and vendor-maintained packages. A command-line php -v result may describe a different installation from the worker handling internet traffic.
What AI contributed to the discovery
The discovery accounts describe specific tasks performed by AI agents. Calif reports that its agent identified a HashTable ordering problem: an entry becomes visible to cleanup before initialization finishes. It then traced reachability through automatic POST processing. Generalizing that lifecycle pattern helped uncover session-related variants. The researcher supplied the direction, informed by PHP’s vulnerability history. Calif’s technical account
OpenAI identifies GPT-5.6 Sol as a tool Calif used in the discovery. OpenAI’s disclosure Wiz separately describes using Wiz Atlas, Gemini 4 Argon and GPT-5.6 Sol for research spanning discovery, exploit development and patch validation. Wiz’s research
This was expert-led, AI-assisted research. The PHP Foundation says signs of the OOM problem were recognized in 2024, without a concrete RCE path, and emphasizes human responsibility for security decisions and patches. The advance was in establishing practical exploitability and finding additional variants. PHP Foundation’s account
For defenders, this raises a practical concern: faster code review, variant searches and test-driven adaptation can also reduce the effort required for misuse. Our assessment is that response windows may narrow as these capabilities spread. Investing in AI-assisted defense therefore needs to go alongside support for maintainers, testing and deployment. AI’s documented role in discovery does not establish its use by attackers. None of the cited exploitation reports confirms that the observed attackers operated AI agents.
Read the exploitation reports in context
The public record includes attempts, demonstrated execution and revised assessments. Reading the updates in sequence prevents an early claim from becoming a permanent intelligence conclusion:
- 17 October: AWS dates an exploitation attempt in its MadPot telemetry to this day, before disclosure, while leaving success against real-world systems unresolved. AWS analysis
- 22 October: Sophos corrected an earlier success claim to scanning and a small number of failed attempts in its customer telemetry, with the attempted payload delivery blocked. Sophos correction, 21:21 UTC
- 24 October: Researcher 0x4D31 reported 35 execution-stage POSTs correlated with 35 Apache-child
/bin/shstarts, UID 33, across three PHP 8.4.26 single-workermod_phphoneypots. The reported chain is consistent with CVE-2026-109618; it does not establish a distinct CVE-2026-109619 path. This researcher-reported result was not independently reproduced for this article and does not measure production compromise prevalence. Honeypot evidence report - 25 October: Unit 42 retracted its earlier association between a government-agency compromise and PHP2Shell, because it could not confirm these CVEs as the initial-access mechanism. Unit 42 update
Carry the same distinctions into internal reporting: exposure, attempted exploitation and confirmed compromise deserve separate fields. An exploit-shaped request may support an attempt assessment; a process execution chain, recovered malicious artifact or independently validated post-exploitation effect provides stronger evidence of compromise. Record missing telemetry and plausible alternative explanations.
Campaign attribution is a further step. Shared hosting, proxies and compromised infrastructure can serve unrelated operators, so a common source IP needs behavioral or infrastructure corroboration.
Turn the mechanisms into a hunt
The lifecycle mechanisms suggest a hunt that connects requests to workers and then to host activity. The steps below are defensive hunting hypotheses, not observed behavior attributed to a particular PHP campaign. Validate them against local baselines before creating blocking rules.
1. Establish the exposure window. Identify when an affected runtime became reachable and when patched workers replaced it. Retain deployment and package evidence. Where telemetry permits, look back at least to 17 October, consistent with the AWS observation, and extend earlier if local evidence warrants.
2. Reconstruct the request-to-worker timeline. Join reverse-proxy and web-access records with PHP errors, service events and worker identifiers. Useful fields include timestamp, request ID, host, route, response status, worker PID and restart reason. Worker identity matters for sequences spanning requests. If PID linkage was never collected, record the gap; it limits what the timeline can establish.
3. Correlate failures with other activity. Compare upload or multipart traffic, memory-related errors, process exits and response failures with normal application behavior. Legitimate imports, broken integrations and deployments can produce similar symptoms. Prioritize clusters accompanied by unexpected child processes, new files or outbound connections. A crash alone establishes neither successful exploitation nor the CVE involved.
4. Follow execution beyond HTTP. Examine EDR or host-audit evidence for unexpected descendants of web workers, changes in application-writable directories, altered startup mechanisms and unusual DNS or network activity. These are generic post-compromise possibilities. An absence of findings is meaningful only within the monitoring coverage available.
5. Preserve evidence before remediation changes the host. Retain logs, file hashes, process ancestry, network observations and available forensic material under the organization’s evidence-handling procedures. Memory captures may contain credentials or personal data. Collect what the investigation requires, rather than retaining full request bodies indiscriminately.
Build detections around this sequence: identify an unusual request or worker event, seek corroboration on the same workload within a justified time window, then attach exposure context and analyst findings. Test against benign upload failures and planned service restarts. Document correlation gaps so analysts know where a rule’s conclusions stop.
Use enrichment to decide what to investigate next
Suppose a suspicious web-worker process creates a file and contacts an unfamiliar domain. The immediate questions are whether the file has known behavioral characteristics and whether the destination connects to other relevant artifacts. VirusSign’s intelligence platform can help investigate files, URLs, domains and IP addresses through behavioral evidence, relationships and historical context. Those connections guide the next investigative step; local telemetry remains essential to determining whether exploitation occurred and how access was gained.
Keep the original observation alongside the enrichment: when and where the artifact appeared, its role in the suspected chain, the source and assessment time. A download location, command-and-control endpoint and incidental shared-hosting address should receive different treatment.
Give operational indicators an owner, confidence level and review or expiry date. Revisit blocks when infrastructure changes hands, observations become stale or a source retracts its assessment. A malware hash match can strengthen an investigation without resolving initial access. A lookup with no match remains unknown, particularly for new or short-lived infrastructure. Apply these provenance and confidence requirements to automated enrichment as well as manual work.
Verify remediation and investigate existing access
Start with internet-facing workloads and verify that running workers have actually been replaced. Retest service health and relevant application functions after changes. For backported builds, retain vendor patch evidence rather than relying entirely on upstream version comparisons.
If compromise is supported, patching is only one part of recovery. Scope accessible secrets and downstream systems, remove unauthorized persistence, rebuild affected workloads where warranted and rotate exposed credentials through the incident-response process. Closing the vulnerable path does not remove an attacker’s existing access.
A useful PHP2Shell assessment should leave the next responder able to verify the runtime, follow the incident timeline and understand the remaining evidence gaps. That is the foundation for deciding what to detect, contain and remediate next.