Both flaws can allow unauthenticated remote code execution, meaning an attacker could run code on the server without a password. The PHP Foundation advisory rates the risk highest for Apache with mod_php, where a crafted request can trigger the attack before any application code runs.
Update, October 22, 2026
According to a CloudLinux post tracking the rollout, three Imunify360 firewall ruleset releases on October 21 (8.83, 8.84 and 8.85) add rules for these CVEs, and servers with the WAF enabled receive them automatically. Ruleset 8.83 (09:08 UTC) blocks the publicly circulating exploit request on ModSecurity (Apache and Nginx) and Coraza. Ruleset 8.84 (13:07 UTC) blocks the public exploit tool by its signature and blocks upload progress requests that do not come from the site own pages, including on LiteSpeed. Ruleset 8.85 (17:17 UTC) blocks further variants of the tool and logs other unusual upload requests. CloudLinux calls this a virtual patch because it stops known request patterns at the server edge while the vulnerable PHP code stays as it is. CloudLinux states that Imunify360 with the WAF enabled receives rulesets 8.83 to 8.85 automatically.
CloudLinux also notes that fixed ea-php packages for cPanel EasyApache 4 (ea-php52 through ea-php85) are released for CloudLinux 7, 8, 9 and 10. According to CloudLinux, PHP 8.1 and older get no release from the PHP project. Its security team published minimal source backports for 7.4, 8.0 and 8.1. For servers that have not been updated, the firewall rules are an interim mitigation, not a fix.
What happened
According to WIRED, the PHP project released emergency updates just before 10 AM ET on October 21, 2026. Wiz Research says its researchers found the flaws partly with AI tools, and OpenAI and the security firm Calif say they found the issues independently and worked together. Cloudflare reported it was "seeing early attacks emerging" before the fixes, and Sansec wrote ahead of the release that it expected mass attacks to start within 15 minutes of the release. The PHP Foundation’s release notes state: "There are no complete mitigations, updating is the only safe choice."
Are you affected?
Any website, intranet, e-commerce store, CRM portal, or other PHP-based application on a network may be at risk, because the UK NCSC says all versions of PHP may be affected and advises not to limit discovery to outdated PHP versions. The PHP Foundation lists PHP-FPM, Apache with mod_php, php-cgi, FrankenPHP and LiteSpeed as in scope, and rates mod_php as the highest-risk configuration. Wiz Research says every PHP version released in the last decade, going back to 5.4, is affected by at least one of the flaws. Sansec reports that Calif showed an attacker without a login can run code on Magento 2.4.9, WordPress 7.1.2, Drupal 11.4.3, Joomla 6.1.4, MediaWiki 1.46.2, Roundcube 1.7.4, phpMyAdmin 5.2.3, Nextcloud 35.0.1, Laravel 13.11, Symfony 8.1 and WHMCS.
To check exposure right now, ask the IT team or hosting provider three questions:
- What PHP version is the production server running? Check whether it is one of the patched versions (8.2.35, 8.3.36, 8.4.27 or 8.5.12) or consult the applicable vendor advisory for distribution-specific fixed versions.
- Does the server process web requests with PHP-FPM, Apache with mod_php, php-cgi, FrankenPHP or LiteSpeed?
- Does any appliance, network device, management interface or line-of-business product on the network embed PHP? The UK NCSC advises watching those vendors for updates.
According to the UK NCSC, organisations should continuously monitor for security updates from third-party software vendors, including for appliances and services that may bundle PHP as a component, and apply relevant updates as they become available. According to the PHP Foundation, PHP 8.1 and older no longer receive updates from the PHP project. The PHP security team provided minimal source-backports for PHP 7.4, 8.0 and 8.1 to help people building from source or without access to an LTS vendor. Otherwise, PHP’s advice is to contact the vendor or upgrade to a supported version.
What to do now
- Follow vendor guidance for applying the update and confirming the PHP version the site reports.
- Check third-party appliances and any line-of-business software that bundles PHP, and apply the vendor’s update as soon as it is available, as the UK NCSC advises. Cisco’s advisory cisco-sa-php-october26-Jj384Daq lists Cisco products under investigation for PHP exposure.
- Treat these as stopgaps, not fixes.
- The UK NCSC says that, if you are unable to apply the temporary mitigations, or applying them would take too long, you should consider taking the system offline until it can be fully mitigated.
- If signs of compromise are found, Brett Leatherman, the FBI’s cyber assistant director, advised to "isolate the system, preserve your web server and PHP logs, and report it to your local FBI field office," WIRED reported.
Why this one is different from a normal PHP patch
According to the PHP GitHub security advisories, this pair is in the PHP engine itself, in how PHP handles out-of-memory errors and how it resets state between requests on the same worker. According to the same PHP advisories, CVE-2026-109618 is described as out-of-memory handling that can interrupt PHP while internal request data is only partially initialized, with request cleanup then treating the invalid data as valid, and CVE-2026-109619 is described as request-owned internal state that can survive after its backing memory has been freed, with a later request handled by the same worker potentially using that stale state before normal initialization resets it. The PHP GitHub advisories rate both critical at CVSS v4.0 9.2. According to the Wiz write-up, the flaws had been present for decades and that frontier AI models substantially reduced the barrier to showing they could be exploited.
Wiz Research notes that a successful exploit could allow attackers to take control of affected servers, steal sensitive data, and deface the websites running on them. Wiz also reports that exploitation could allow reading sensitive process memory, which may contain passwords, authentication tokens, API keys and certificates belonging to other requests or the server itself.
What the security agencies are saying
The UK National Cyber Security Centre tells organizations to identify PHP systems, with priority on internet-facing hosts, update to the latest fixed version, and consider taking a system offline if it cannot be mitigated in time. Before the release, the EU’s CERT and Australia’s cybersecurity agency warned IT teams to be ready to update, WIRED reported. Ubuntu has published fixed packages for all supported releases, including ESM backports for older LTS lines through Ubuntu Pro.
For cloud and hosting environments, Microsoft’s Azure Network Security team has published WAF custom rules and a managed response rule (MS-ThreatIntel-Response-CVEs, rule 99006001) rolling out to Azure Front Door WAF, expected to complete by October 28.
FAQ
What PHP versions are affected by CVE-2026-109618 and CVE-2026-109619?
According to Wiz Research, every PHP version released in the last decade, going back to 5.4, is affected by at least one of the two flaws. Patched versions are PHP 8.5.12, 8.4.27, 8.3.36 and 8.2.35. According to the PHP Foundation, PHP 8.1 and older no longer receive updates from the PHP project. The PHP security team provided minimal source-backports for PHP 7.4, 8.0 and 8.1 to help people building from source or without access to an LTS vendor.
Can an attacker exploit these PHP flaws without a password?
Yes. The PHP Foundation advisory and the GitHub security advisories state both vulnerabilities can allow unauthenticated remote code execution, meaning no login or credentials are required. Sansec reports that researchers confirmed unauthenticated RCE against Magento 2.4.9, WordPress 7.1.2, Drupal 11.4.3, Joomla 6.1.4, MediaWiki 1.46.2, Roundcube 1.7.4, phpMyAdmin 5.2.3, Nextcloud 35.0.1, Laravel 13.11, Symfony 8.1 and WHMCS.
Do the Imunify360 firewall rules fix the flaws?
No. CloudLinux describes the Imunify360 WAF rulesets 8.83, 8.84 and 8.85 as a virtual patch: they stop known request patterns at the server edge while the vulnerable PHP code stays as it is. CloudLinux states that Imunify360 with the WAF enabled receives rulesets 8.83 to 8.85 automatically, and that PHP itself should be updated as soon as possible.