Truvo Incident Tracker

PHP2Shell: CVE-2026-109618 and CVE-2026-109619

Two critical flaws in the PHP engine allow remote code execution without a login. PHP fixed them on October 21, 2026. This page tracks what is confirmed, what is still unknown, and what to do, with each fact dated and sourced.

Status: ActiveSeverity: CriticalUpdated Oct 22, 2026, 12:46 UTC

Talk to incident response

Share what happened and a consultant will follow up to book a call.

PHP2Shell key facts

CVEsCVE-2026-109618 (memory exhaustion corrupts request state), CVE-2026-109619 (use-after-free across requests)
SeverityCVSS v4.0 9.2 Critical (PHP). No authentication or user interaction needed
Fixed inPHP 8.5.12, 8.4.27, 8.3.36, 8.2.35 (released October 21, 2026)
No official fixPHP 8.1, 8.0, 7.4 and older (end of life). Fix depends on the OS vendor or host
Most exposedApache with mod_php (exploitable with default settings). PHP-FPM, FrankenPHP, LiteSpeed and php-cgi also affected
ExploitationAttempts seen October 17 (before disclosure) and October 21. No compromised organization named yet
CISA KEVNot listed as of October 21, 2026

Check a site for PHP2Shell exposure

The checker reads the PHP version a site advertises in its response headers and compares it with the fixed releases. It sends one normal request and no exploit traffic. A hidden or patched-looking version still needs the internal checks below, because headers do not show distribution backports. The same check is available as a standalone PHP2Shell checker and is part of the full domain security scan.

What is confirmed and what is still unknown about PHP2Shell

Confirmed

  • Both CVEs are in PHP itself and trigger before application code runs, so WordPress, Drupal, Magento, Laravel and custom apps are all exposed on an unpatched PHP (PHP advisories)
  • Fixed releases: 8.5.12, 8.4.27, 8.3.36, 8.2.35 (PHP advisories, October 21)
  • Apache mod_php is exploitable with default settings. CVE-2026-109619 is confirmed on PHP-FPM through session upload progress (PHP advisories)
  • Amazon honeypots logged an exploitation attempt on October 17, four days before disclosure (Amazon Threat Intelligence)
  • Cloudflare enabled WAF rules for all plans on October 21 and reports attack traffic, including payloads altered to evade rules (Cloudflare)
  • Over 100 public proof-of-concept repositories appeared within a day. Some contain malware (JFrog, ASEC)

Not yet known

  • How widespread successful exploitation is: Amazon reports broad exploitation, while CISA, Huntress and national CERTs had not observed it
  • Whether CVE-2026-109618 is exploitable end to end on PHP-FPM (assessed susceptible, not demonstrated)
  • Whether every version back to PHP 5.4 is affected (claimed by Wiz, not confirmed by PHP)
  • Package status for Debian 12, RHEL 8 and RHEL 10 (sources disagree)
  • Indicators of compromise such as hashes, IPs or domains (none published)

What to do about PHP2Shell, step by step

Remediation first, then an incident response check using the NIST SP 800-61 phases, because exploitation began before the patch. Preserve the logs before anything else, because patching and redeploying can wipe them.

1. Evidence preservation

  • Copy web, PHP-FPM and PHP error logs from October 17 onward to storage the web servers cannot write to

2. Remediation

  • Upgrade to a fixed release or the vendor package carrying the fix
  • Restart every PHP worker and rebuild container images
  • If patching must wait: session.upload_progress.enabled=0, fatal_error_backtraces=0 (8.5), request size caps, WAF rules

3. Detection and analysis

  • Look for web workers starting shells or outbound connections, memory-exhaustion errors before scripts ran, and worker crashes
  • Record per server: no evidence, inconclusive, or compromised
  • No evidence: close the vulnerability record. Compromise: declare an incident and make the breach determination

4. Containment, eradication and recovery

  • Only for compromised servers: isolate and rotate the credentials the server held
  • Rebuild from a known-good image with patched PHP
  • Restore data from a clean backup and confirm the service works

5. Post-incident activity

  • Set an upgrade date or a formal risk acceptance for PHP 8.1 and older
  • Compare remediation time with policy and add any PHP servers the inventory missed

PHP2Shell obligations under SOC 2, ISO 27001, GDPR, HIPAA and Canadian privacy law

A vulnerability is not a breach. Investigating whether it was exploited is incident response under SOC 2 and ISO 27001. Privacy laws apply only if personal data or PHI was compromised.

Framework or lawWhen it appliesWhat it asks forClock
SOC 2
Framework		Always, for systems in scopeDetect and patch (CC7.1), evaluate the event (CC7.3), respond and recover if exploited (CC7.4, CC7.5)None set by SOC 2. Your policy and customer contracts
ISO 27001:2022
Framework		Always, for systems in scopeTechnical vulnerability management (A.8.8), event decision (A.5.25), incident response (A.5.26-A.5.28)None set by ISO. Your procedure
GDPR
Law		Exploitation led to personal data being compromisedNotify the supervisory authority unless unlikely to result in risk. Tell individuals if high risk. Document every breach72 hours from reasonable certainty of a breach
HIPAA
Law		Attempted access is a security incident. PHI accessed is a presumed breachDocument incidents. Four-factor risk assessment. Notify individuals, HHS and media as requiredIndividuals within 60 days of discovery
PIPEDA
Law		Breach of security safeguards with real risk of significant harmReport to the OPC and notify individuals. Record every breachAs soon as feasible. Keep records 24 months
Quebec Law 25
Law		Confidentiality incident with risk of serious injuryNotify the CAI and affected people. Register every incidentPromptly

Not sure if you were exploited?

Truvo's incident response team scopes PHP exposure, reviews the logs and makes the incident and breach determination with you, then leaves the evidence your auditor and customers will ask for.

Talk to incident response

PHP2Shell: questions and answers

Check the PHP that serves web traffic, using phpinfo() from a protected page, since php -v reports the command-line build. Then check the package changelog for the CVE IDs, because Linux distributions patch without changing the version number. On managed hosting, ask the host to confirm both CVEs are patched for the exact PHP version each site uses.

PHP 8.5.12, 8.4.27, 8.3.36 and 8.2.35, released October 21, 2026, fix both CVE-2026-109618 and CVE-2026-109619. PHP 8.1 and older are end of life and receive no official release. Restart every PHP worker and rebuild container images after upgrading.

For any internet-facing PHP server that was unpatched after October 17, 2026, yes: treat it as a security event and investigate whether it was exploited. A compromised server is a security incident for the company even when no personal data is involved, and a breach under privacy law only when personal data or PHI was compromised.

GDPR applies only if exploitation led to personal data being compromised. In that case, GDPR Article 33 requires notifying the supervisory authority within 72 hours of reaching reasonable certainty of the breach, unless it is unlikely to result in risk to individuals. Every breach must be documented either way.

Under 45 CFR 164.304 an attempted exploit against a system holding PHI is a security incident to identify, respond to and document. If PHI was accessed, HIPAA presumes a breach unless a four-factor risk assessment shows low probability of compromise, and individuals must be notified within 60 days of discovery.

A WAF reduces risk while patching. Cloudflare enabled rules for all plans on October 21, 2026, and has seen attackers alter payloads to evade them. PHP states that patching is the only complete fix.

Change log

  • Oct 22, 2026, 12:46 UTC: PHP2Shell checker published as a free tool and added to the domain security scan. No change to the confirmed facts.
  • Oct 22, 2026: Tracker published. Facts as of 04:00 UTC.