PHP2Shell: the patch closes the flaw, detection closes the window

On 21 October 2026, the PHP project fixed CVE-2026-109618 and CVE-2026-109619, nicknamed PHP2Shell: unauthenticated remote code execution on installations that serve web requests. Details leaked before the agreed date, and Amazon reports an exploitation attempt four days before the fix. The patch answers whether the flaw is still open. It does not answer the other question: did anyone get in while it was?

This article summarises the threat brief Network Secure published on the case. Because the event is still unfolding, we separate what is confirmed by a primary source (PHP announcement, GitHub advisories, CVE/NVD records) from what is still a report by whoever observed it. The material is defensive: it contains no payloads or exploitation instructions.

What PHP2Shell is

PHP2Shell is the informal name for two vulnerabilities in the PHP core — in the runtime, not the application. Updating WordPress, Drupal or plugins does not fix it. Both abuse how exceptional conditions are handled: when memory runs out or a fatal error occurs, PHP abandons the operation without normal cleanup, and internal structures are left partially initialised or pointing to memory already freed.

• CVE-2026-109618 (GHSA-w8hw-w9fx-j79w) — RCE via out-of-memory corruption. An allocation failure interrupts PHP while internal request data is only partially initialised, and cleanup treats that invalid state as valid. With Apache mod_php, the attack runs before any application code.
• CVE-2026-109619 (GHSA-6wmf-4rv5-p3rp) — RCE via stale global state. State from one request survives after its memory is freed and is used by the next request on the same worker (use-after-free). Validated cases include session upload progress, enabled by default, on mod_php and PHP-FPM. There is also memory disclosure: data that passed through the process can be exposed even without code execution.

PHP assigned each a CVSS v4.0 score of 9.2 — high complexity, but no authentication or user interaction required. To learn how to read that score, see our CVSS guide.

What is confirmed and what is still a report

On 23/10, neither CVE was in CISA's KEV catalog, and EPSS stood at 11.6% and 6.0%. These indicators change fast, so check again. If prioritisation is your topic, see how to prioritise vulnerabilities with CVSS, EPSS and KEV.

Who is exposed

PHP considers every installation serving web requests at risk. The execution mode changes the urgency:

• Apache with mod_php — top priority. RCE validated over HTTP for both CVEs, before any application code.
• PHP-FPM — high. CVE-2026-109619 validated in the session cycle; CVE-2026-109618 susceptible by code analysis, with no complete exploit demonstrated.
• FrankenPHP, LiteSpeed and php-cgi — treat as exposed. They are on PHP's list, but there is no public validation per mode.

New on 23/10: CVE-2026-115560. PHP published an informational advisory about another session upload progress flaw that affects even fixed versions, but only under an unusual combination of configuration and code. PHP does not classify it as part of PHP2Shell. The mitigation is the same already given for CVE-2026-109619: session.upload_progress.enabled=0.

Three inventory traps come up often:

• php -v misleads. The command-line binary may differ from the one running in FPM or Apache.
• Workers in memory keep the vulnerable code until restart, even with the new package installed.
• Third-party PHP. NVD already links appliances from other vendors to the CVEs; hosting providers and control panels count too.

Four days before the patch

Between 17 and 21 October there was no CVE, no patch and no signature. In that interval, only behavioural detection and threat intelligence could see the attack. Amazon itself recommends investigating from 17/10.

Why the patch alone does not close the window

The exposure window opens when someone other than the defender can exploit the flaw, and closes when the organisation proves two things: that the asset is no longer exploitable and that nobody exploited it in the meantime. Vulnerability management handles the first; detection and response, the second.

• A log with no errors is not proof of safety. PHP itself warns the flaw can trigger before the message is written.
• “Fixed” may be temporary. Old workers stay in memory until restart, and CVE-2026-115560 affects fixed versions.
• There are two clocks. Time to patch measures how long the flaw stayed open. The SOC's MTTD and MTTR measure how long an intruder would stay unnoticed and how long until containment. Neither replaces the other.
• External intelligence is not internal evidence. Honeypot attempts prove the flaw is being attacked in the wild, not that your server was — nor that it wasn't.

Where the attack leaves traces

The exploitation itself may not produce a log. What the attacker does next almost always does. Conceptually, the chain is:

1. Request to PHP
2. Out of memory or fatal error
3. Inconsistent state in the worker
4. Code execution on the server

The code runs with the privileges of the web worker account. That is not administrative access by itself, but this account usually reads configuration files, database credentials and integration keys, and can reach internal services. The strongest signal for the SOC is in post-exploitation.

What to hunt since 17 October

With no published IoCs, hunting starts from behavioural hypotheses. The six below were written for Linux servers running PHP; record what could not be checked for lack of telemetry.

1. Web worker spawning processes. apache2, httpd, php-fpm or lsphp launching shells, interpreters or download utilities (ATT&CK T1059.004, T1505.003). Source: EDR, auditd or Sysmon for Linux.
2. New files where the web server writes. Scripts or binaries created after 17/10 in web, upload, cache or /tmp directories (T1505.003, T1105). Source: FIM, EDR, comparison with the repository.
3. Unseen outbound traffic. Connections started by the web server user to destinations with no history (T1071, T1105). Source: firewall, NDR, egress proxy, flow logs.
4. Clustered fatal errors. “Memory exhausted”, timeouts and restarting workers, grouped by route, content type or origin (T1190). Source: PHP, PHP-FPM, web server and WAF logs.
5. Server credentials used elsewhere. Reads of .env and configuration files followed by service-account logins from new origins (T1552.001, T1078).
6. Abnormal CPU use by processes tied to the web server, with no matching rise in traffic (T1496).

If there is any sign, treat it as an incident, not a patch. Preserve memory, disks and logs from the period before fixing: restarting or updating before collection erases exactly what the investigation needs. Given the confirmed memory disclosure, consider rotating credentials, tokens and keys used by exposed servers. If you need support, see Incident Response.

Technical recommendations

Patching is the only complete solution; everything else buys time. When in doubt about a parameter, PHP's official advisory prevails.

1. Inventory all PHP — parallel branches, containers, hosting panels and appliances — with version, execution mode, exposure and owner.
2. Update to 8.5.12, 8.4.27, 8.3.36 or 8.2.35, or to the vendor's fixed package; on branches 7.4 to 8.1, backport or migrate. Rebuild container images.
3. Restart every process that loads PHP and confirm the running workers use the fixed build — not php -v.
4. Disable session upload progress with session.upload_progress.enabled=0 in php.ini, the FPM pool or the server configuration (not via ini_set()), and keep it off after updating, until the release that fixes CVE-2026-115560.
5. On PHP 8.5, set fatal_error_backtraces=0 administratively, which removes the producer of the confirmed RCE case.
6. Limit requests: a conservative post_max_size, multipart limits at the frontend, and blocking multipart where the application does not use it.
7. Cover exposed PHP servers with process and network telemetry (EDR or auditd, firewall or NDR), not just access logs, integrated into the SIEM or XDR.
8. Use the WAF as a stopgap, not a solution: Cloudflare saw attempts to bypass its rules, and direct-to-origin traffic skips the WAF altogether.

For assets that can be neither fixed nor compensated, CERT-EU and the Canadian Centre for Cyber Security recommend isolating them from public networks until the fix is applied and verified.

Questions leadership should ask

• How many internet-facing assets run PHP, and how many already have remediation validated at runtime?
• Have we reviewed signs of exploitation since 17/10? With what telemetry coverage, and what was left uncovered?
• If a server had been compromised on 18/10, when would we have known?
• Who can decide to isolate a service at 3 a.m. on a Saturday?
• Which risks were accepted, by whom, with which compensating control and until when?

The first proofs of concept appeared around 02:00 UTC on a Tuesday. Building that coverage in-house takes shift rotas, SIEM, SOAR, threat intelligence and a team that is hard to hire and keep. Many companies combine both models: the internal team keeps the context and business decisions, and SOC as a service provides continuous watch and first response. The comparison is in SIEM, MDR or SOC as a Service.

How Network Secure's SOC and MDR act in a case like this

A flaw with no IoCs produces weak, scattered signals: a fatal error here, a child process there, a new connection somewhere else. On their own, none justifies an alarm; correlated on the same host and in the same time window, they tell a story. In Network Secure's 24×7 SOC and MDR, the Open-XDR platform collects telemetry from endpoint, network, cloud, identity and firewalls; AI handles triage and correlation; the analyst validates what is critical, maps the attack to MITRE ATT&CK, leads containment and delivers a notification your team can act on. The SOC is ISO/IEC 27001:2022 certified, audited by Bureau Veritas.

To be clear about the limits: we do not claim to have detected PHP2Shell exploitation at customers, nor that any service identifies the flaw automatically. Patching and restarting services remains the responsibility of whoever operates each asset, unless a specific contract says otherwise.

Frequently asked questions

What is PHP2Shell?

It is the informal name for two critical vulnerabilities in the PHP core, CVE-2026-109618 and CVE-2026-109619, fixed on 21/10/2026. They allow unauthenticated remote code execution on installations that serve web requests.

Which PHP versions fix PHP2Shell?

PHP 8.5.12, 8.4.27, 8.3.36 and 8.2.35. Branches 8.1, 8.0 and 7.4 have no official release, only minimal source backports or LTS vendor packages; 7.3 and earlier have no fix.

Does updating WordPress or plugins fix it?

No. The flaw is in the PHP runtime, not the application. You need to update PHP and restart every process that loads it.

I already patched. Is there anything else to do?

Yes. Confirm the running workers use the fixed build, keep session.upload_progress.enabled=0 until CVE-2026-115560 is fixed, and investigate signs of exploitation since 17/10/2026, when the first reported attempts appeared.

Are there indicators of compromise (IoCs) for PHP2Shell?

As of 23/10/2026, no primary source had published IoCs, actors or campaigns. Detection depends on behaviour: processes spawned by the web worker, new files in web directories and unseen outbound connections.

Sources consulted up to 23 October 2026: PHP security announcements of 21/10 and 23/10; advisories GHSA-w8hw-w9fx-j79w and GHSA-6wmf-4rv5-p3rp; NVD records; CISA KEV catalog (version 2026.10.23); FIRST EPSS; CERT-EU advisory 2026-018; Canadian Centre for Cyber Security, AL26-026; publications by Wiz Research, Amazon Threat Intelligence, Cloudflare, Qualys, watchTowr and Field Effect. KEV status, EPSS and indicators change often. The hunting hypotheses are Network Secure's technical derivation, not published indicators.

Official references

• Security advisory: critical remote code execution vulnerabilities (21/10/2026) — The PHP Group
• Informational advisory: session upload progress, CVE-2026-115560 (23/10/2026) — The PHP Group
• GHSA-w8hw-w9fx-j79w — RCE via OOM corruption (CVE-2026-109618) — PHP/GitHub
• GHSA-6wmf-4rv5-p3rp — RCE via stale global state (CVE-2026-109619) — PHP/GitHub
• CVE-2026-109618 Detail — NIST NVD
• CVE-2026-109619 Detail — NIST NVD
• CISA — Known Exploited Vulnerabilities Catalog
• Security Advisory 2026-018 — Critical Vulnerabilities in PHP — CERT-EU
• PHP2Shell: AI uncovers critical RCE vulnerabilities — Wiz Research
• PHP2Shell exploitation prior to public disclosure in MadPot — Amazon Threat Intelligence
• Cloudflare deploys protections against php2shell — Cloudflare