AI disclosure: This article was prepared with AI assistance and reviewed against the linked PHP and vendor advisories. Status is as of October 22, 2026, 9:30 a.m. Central.
The PHP project released emergency fixes on October 21 for CVE-2026-109618 and CVE-2026-109619. Each is rated Critical, 9.2 under CVSS v4.0. Both can lead to unauthenticated remote code execution in affected PHP web runtimes. The first fixed upstream releases are PHP 8.2.35, 8.3.36, 8.4.27, and 8.5.12. PHP urges immediate updating and says configuration changes are not complete substitutes. [1]
The response is now a worldwide rollout across operating-system packages, cloud runtimes, hosting platforms, and web application firewalls. There is no reliable public count of sites that have finished patching. Amazon reports exploit attempts against its sensors as early as October 17, before public disclosure, and says attempts broadened after the fixes appeared. Its report does not establish how many real systems were compromised. [2]
The two vulnerabilities
CVE-2026-109618 — out-of-memory corruption. An allocation failure can interrupt PHP while internal request data is only partly initialized. Cleanup may then use invalid data. PHP validated remote code execution over HTTP against Apache mod_php with ordinary input and memory limits. PHP also considers PHP-FPM susceptible through paths reached after startup, although its advisory says a complete FPM exploit for this CVE had not been demonstrated. [3]
CVE-2026-109619 — stale global state. Data owned by one request can remain referenced after its memory is freed. A later request on the same worker may use the stale reference. PHP describes confirmed paths involving early configuration diagnostics and session upload progress, including a validated PHP-FPM path that depends on a suitable application operation. [4]
PHP says all installations serving web requests need assessment, including PHP-FPM, mod_php, php-cgi, FrankenPHP, and LiteSpeed. It places the highest demonstrated risk on mod_php, where an unauthenticated request can trigger an attack before application code runs. That distinction affects triage; it does not make other server arrangements safe to leave unpatched. [1]
Successful code execution runs with the PHP worker’s permissions. The data and systems at risk depend on what that worker can access. A WordPress, Drupal, or other application update alone does not repair the vulnerable PHP runtime. [1] [5]
How the updates are being applied worldwide
- Linux distributions: Debian published a fixed PHP 8.4 package for Debian 13. Ubuntu published fixes for supported releases and extended-maintenance packages for older releases. Package version numbers may remain lower than PHP’s upstream fixed versions because the fixes are backported. Verify the distribution advisory and package revision, not a
php -vnumber alone. [6] [7] [8] - Cloud platforms: Google Cloud says supported App Engine Standard runtimes receive automatic updates. Custom images, App Engine Flexible deployments, and Cloud Run or functions without automatic base-image updates require rebuilding or redeployment. AWS reports an updated Elastic Beanstalk PHP platform; customer-managed PHP instances and images require separate action. A provider platform update does not necessarily update PHP inside a customer-managed workload. [9] [10]
- Hosting panels and providers: cPanel lists patched cPanel/WHM and EasyApache releases, including builds for some older PHP branches. Check the exact product and PHP package in use, and confirm serving workers were restarted. A shared-hosting announcement does not prove a separately managed VPS or custom container was updated. [11]
- Edge defenses: Cloudflare says it enabled default WAF protections before public disclosure and observed attackers changing payloads. These controls add protection, but Cloudflare still directs customers to patch PHP. Confirm the ruleset is active and traffic cannot bypass the protected edge. [5]
PHP 8.1 and older receive no ordinary upstream release. PHP supplied minimal source backports for 7.4, 8.0, and 8.1, and some distribution and long-term-support vendors maintain fixes for older branches. Check the vendor’s exact package status; otherwise move to a supported, fixed branch. [1]
Exploitation and investigation
Amazon’s honeypot telemetry places a suspected exploit attempt on October 17 and further attempts before and after the October 21 release. Cloudflare also reports attack traffic against customers. These are reports of attempted exploitation, not a verified global tally of successful intrusions. For an internet-facing system that remained vulnerable, investigate activity from at least October 17 where logs are available. Review unusual web requests, PHP worker crashes, unexpected processes or file changes, and suspicious upload activity; preserve evidence before rebuilding a host suspected of compromise. Amazon cautions that observed IP addresses include shared anonymization infrastructure and should be investigated in context rather than treated as proof of compromise on their own. [2] [5]
Action plan for operators
- Find every PHP web runtime: public sites, internal applications, containers, managed hosting, appliances, background workers, and staging systems reachable by untrusted users. Record the installed package, update provider, web-serving PHP version, and service owner.
- Patch exposed systems first: install 8.2.35 / 8.3.36 / 8.4.27 / 8.5.12 or the vendor-confirmed backported package. Rebuild custom images and redeploy every affected instance.
- Restart and verify: restart PHP-FPM, Apache, or other PHP-serving workers as appropriate. Confirm the fixed package is installed and loaded by the process handling web requests. Ubuntu notes that automatic package installation may still require an application restart or reboot. [8]
- Handle systems awaiting a fix: reduce exposure or isolate them, and follow PHP’s specific temporary measures only after checking application impact. Those measures address particular attack paths and do not fully mitigate either vulnerability. The UK NCSC advises considering taking systems offline when immediate remediation is not feasible. [1] [12]
- Check for compromise and record exceptions: review available telemetry back to October 17 for exposed systems; document the deployed fix, worker restart, validation result, and any remaining unpatched service.
Current assessment: This has moved beyond a planned release to an active patching and investigation event. The fixed PHP versions are available, major distributors and providers have begun deploying them, and exploit attempts have been observed. Because each hosting and cloud model updates PHP differently, the decisive evidence is the fixed runtime actually serving each application, backed by its vendor advisory and a completed restart or redeployment.