CVE-2026-109618 and CVE-2026-109619 (PHP2Shell): Two Critical PHP Remote Code Execution Flaws

The PHP security team has announced an emergency security release for Wednesday, October 21, 2026 at 14:00 UTC. It addresses two critical vulnerabilities, both rated CVSS v4.0 9.2. The vulnerabilities are tracked as CVE-2026-109618 and CVE-2026-109619. Both bugs are described as remote code execution issues, meaning an attacker could get their own commands running on a vulnerable server.

The route to disclosure was messy. On October 20, an unverified claim began circulating on social media that an announcement about two PHP vulnerabilities was due on October 22. The message also listed the two reserved CVE IDs, and it spread quickly. PHP then issued its own advance notice and brought the release forward by a day.

Security researchers then moved quickly to test the claims. At least one security firm said it had reproduced CVE-2026-109618 in its lab, and other researchers are reported to have reproduced the flaws as well. That means code execution has reportedly been demonstrated by more than one party before any official fix existed. A leaked exploit tool, known as PHP2Shell, has also been circulating, and the name is now widely used for these two vulnerabilities.

Our continuous internet-wide scans show that only about a third of the PHP instances where we could identify the version run a branch covered by this security update (8.2 through 8.5). The rest are on older branches that did not receive one, and the most common branch by far is PHP 7.4, with more than 2 million observations. The chart shows the 20 most commonly detected branches. Many other PHP deployments are likely exposed but not shown, because they do not expose version information.

According to Bitsight Threat Intelligence

Bitsight Threat Intelligence assigns CVE-2026-109618 a Dynamic Vulnerability Exploit (DVE) score of 9.91 out of 10, and CVE-2026-109619 a score of 9.84, driven by significant discussion of these vulnerabilities across open and dark web sources, with one dark web exploit forum user noting: “[the] Internet will be on fire.” DVE estimates how likely a vulnerability is to be exploited over the following 90 days.

CVE-2026-109618 and CVE-2026-109619 technical overview

Why this matters

PHP runs a very large portion of the web, from content management systems and online shops to bespoke internal tools. A flaw in the runtime can’t be repaired by changing application code, and a web application firewall or plugin update won’t remove it. Only updating PHP on the host itself closes the gap.

Attackers are likely to move the moment the fix is public. By comparing the patched PHP source against the previous release, and using AI tooling to speed up the analysis, they can locate the flaw and produce a working exploit in a fraction of the time this once took. Organizations should therefore plan for a likely incident, not a routine patching cycle.

CVE-2026-109618 and CVE-2026-109619 impact to organizations

Organizations running exposed PHP versions may face:

• Unauthenticated command execution on web-facing servers
• Web shells planted for long-term access
• Theft of credentials, API keys, database passwords and session data held by the application
• Defaced sites, stolen customer data, or tampered payment pages on e-commerce platforms
• Movement from a compromised web server deeper into internal networks
• Lingering risk from legacy applications stuck on unsupported PHP
• Third-party and supply chain exposure when vendors, agencies or hosting providers operate vulnerable PHP stacks that serve you

Recommendations

1. Map where PHP runs

No official guidance on scope or required configuration existed when this was written, so assume every production PHP instance is in play. Locate servers, containers, base images and managed hosting plans, including PHP embedded in appliances, control panels and vendor products. Get your update process ready so the fix can be deployed on release day.

2. Update as soon as possible

Move each system to the corrected release for its branch: PHP 8.5.12, 8.4.27, 8.3.36 and 8.2.35. Rebuild container images as well as hosts, and check with php -v that the running process reports the new version, not just the installed package.

3. Decide what to do about unsupported versions

If any system runs a PHP branch outside the support window, ask your OS vendor or host whether they will backport the correction, or schedule a migration. Until then, limit how reachable those systems are.

4. Check your vendors and third parties

Reach out to the vendors and third parties that support your business and ask about their PHP usage and patching status.

How Bitsight CTI and TPRM support you

• Threat monitoring: Bitsight Threat Intelligence follows shifts in exploit activity, proof-of-concept availability, attacker interest and underground chatter as events unfold. Access early-warning signals, dark web chatter, and active exploitation trends surrounding CVE-2026-109618 and CVE-2026-109619.
• Vulnerability prioritization: DVE complements CVSS with a forward-looking estimate of exploitation likelihood, so teams can concentrate on what attackers are most likely to use.
• External exposure detection: Bitsight Continuous Monitoring draws on externally observable data to help spot and prioritize vendors with relevant exposure, support outreach on critical vulnerabilities, and follow remediation over time. Track public-facing PHP installations across your vendors and third-party footprint.
• Supply chain exposure management: Bitsight Beacon watches critical vendors more closely, covering exposure before an incident, active intrusion and evidence left after a compromise. Validated, enriched alerts with remediation guidance flow into existing security workflows.
• Vendor response and remediation: Beacon’s optional managed services can handle vendor notification, evidence sharing, SLA tracking and escalation until the issue is resolved.

Conclusion

CVE-2026-109618 and CVE-2026-109619 are critical weaknesses in the PHP runtime itself and a lab reproduction has already been reported, so the gap between disclosure and attacks may be very small. Organizations should map their PHP footprint, deploy the corrected release the moment it is available, and decide how to handle versions that will never be patched upstream. The same urgency should extend to the vendors and hosts who run PHP on your behalf.