TL;DR
- PHP released emergency fixes today for two critical flaws in PHP itself. Both can allow unauthenticated remote code execution (RCE) over the web.
- Word of the flaws leaked before the planned disclosure, and Cloudflare reported early attacks before the fixes shipped. We haven’t confirmed exploitation in any customer environment.
- If you run internet-facing PHP, patch to 8.5.12, 8.4.27, 8.3.36, or 8.2.35, then restart every PHP worker. Updating and restarting PHP workers is the only complete fix.
What happened
On October 20, PHP gave advance notice of emergency patches for two critical flaws. Details leaked before the planned disclosure, and PHP shipped the fixes today, October 21. Cloudflare’s CTO said they were “seeing early attacks emerging” before the patches landed, but haven’t published details as of this time.
Both flaws are memory-safety bugs in how PHP handles web requests, and both are rated critical (CVSS v4.0 9.2):
- CVE-2026-109618 abuses out-of-memory handling during request handling, such as parsing uploaded form data.
- CVE-2026-109619 abuses leftover state from one request that a later request on the same worker reuses.
An attacker who succeeds can run code with the privileges of the web server’s PHP worker, with no login required.
Who’s at risk
PHP says every installation serving web requests is affected, including PHP-FPM, Apache with mod_php, php-cgi, FrankenPHP, and LiteSpeed. It rates the risk highest for Apache mod_php, where its demonstrated exploit triggers while PHP is still processing the incoming request, before any site code runs. That means a site doesn’t need a flaw of its own to be exposed.
PHP validated full RCE over HTTP against Apache mod_php with default input and memory limits. It also validated CVE-2026-109619 against PHP-FPM, in a scenario that depends on how the application behaves.
That’s a big pool. PHP runs on roughly 69% of websites with a known server-side language (W3Techs), including WordPress, Drupal, and Magento.
What’s confirmed and what isn’t
Confirmed by PHP:
- Fixed versions are 8.5.12, 8.4.27, 8.3.36, and 8.2.35.
- PHP 8.1 and older don’t get official releases. PHP published minimal source backports for 7.4, 8.0, and 8.1, and some Linux distributions and LTS vendors offer backported fixes.
- There’s no complete workaround. Updating is the only full fix.
Not confirmed:
- In-the-wild exploitation. Cloudflare reported early attacks but hasn’t published attack details, or said whether any succeeded. As of this morning, neither CVE is in CISA’s Known Exploited Vulnerabilities (KEV) catalog.
- Public exploit code. Code claiming to exploit these flaws is circulating. Code claiming to exploit these flaws is circulating. We haven’t verified any of it, and some may be malicious. Don’t run it.
- PHP published backports for 7.4, 8.0, and 8.1, but hasn’t said anything about 7.3 or earlier. Early reports said PHP 5 through 8 are affected. Assume any end-of-life PHP serving web traffic is at risk.
Where our coverage stands
When the leak broke, there were no technical details. PHP has since published those details, and we’re using them to help identify opportunities to bolster our detection strategy.
Our coverage targets what attackers do after they get in, and that’s still our main approach until confirmed IOCs exist. Existing detections already cover web server processes launching command shells and webshell activity, both common signs of a successful web server exploit.
Here’s what we’ve done since the leak:
- Tracked vendor advisories, researcher findings, and attack reports since October 20.
- Reviewed our customer alert and investigation history for internet-facing PHP and prior PHP-related activity, to decide where to look first.
- Started reviewing PHP’s technical details to sharpen detections. We’ll share any confirmed IOCs with customers.
- Kept watching new threat intel and PHP-related activity across customer environments.
We can only see what’s connected to us. PHP sites on managed hosting, servers without an endpoint agent, and infrastructure that isn’t integrated with Expel are outside our view, and that’s often where internet-facing PHP runs. PHP also notes that some exploit paths may not leave a predictable log entry, so an empty log doesn’t prove you’re safe.
Detection doesn’t replace patching. We can catch and respond to successful exploitation, but only patching but only patching and restarting PHP workers prevents it. We can’t prevent exploitation of an unpatched, internet-facing system.
Worst case
If attackers exploit these flaws at scale now that technical details are public, expect automated attacks against internet-facing PHP applications. A successful attacker runs code as the web server’s account, which typically lets them:
- Read application configuration, including database credentials and API or cloud keys.
- Install webshells for persistent access.
- Steal or tamper with application data.
- Use the server as a foothold into internal networks.
Earlier PHP flaws (CVE-2024-4577 and CVE-2019-11043) are in the KEV catalog and have known ransomware use. End-of-life PHP that never gets patched will stay exposed long after today.
What to do now
- Patch internet-facing PHP first. Update to 8.5.12, 8.4.27, 8.3.36, or 8.2.35, or install your distribution’s patched packages. Distro packages may not show a new PHP version number, so check the vendor’s security advisory.
- Restart every PHP worker after patching. That includes PHP-FPM, Apache (if it runs mod_php), and long-running PHP processes like queue workers. Running processes keep the old code until they restart.
- Find all your PHP. Check CMS and e-commerce platforms (WordPress, Drupal, Magento), hosting control panels, container images, and vendor products that bundle PHP.
- Deal with end-of-life PHP (8.1 and older). Upgrade, use a vendor backport, or take it off the internet or put it behind a VPN until you can.
- If you can’t patch right away, PHP’s advisory lists partial mitigations. They reduce exposure to specific attack paths but don’t make a system safe. Test them before production, since some change how your applications behave:
- Set session.upload_progress.enabled=0 in php.ini, the FPM pool, or server configuration, and restart every worker. Don’t rely on ini_set() or .user.ini.
- On PHP 8.5, set fatal_error_backtraces=0 and restart every worker.
- Apply PHP’s memory and request-size settings (memory_limit, post_max_size, and limits at the web server or proxy) exactly as the advisory describes. One of these removes PHP’s memory cap, so read the caveats first.
- Block multipart (file upload) requests at the web server or WAF for applications that don’t need them.
- If you use a cloud WAF like Cloudflare, make sure your origin servers only accept traffic through it. Otherwise attackers can go around it.
- Watch for signs of compromise:
- PHP or web server processes (php-fpm, php-cgi, httpd, apache2) launching shells, scripting interpreters, or download tools.
- New or changed PHP files in web directories.
- Unexpected outbound connections from web servers.
- Spikes in PHP fatal errors, memory-exhaustion errors, or crashing workers.
- If you find something, isolate the server, preserve web server and PHP logs, and contact us right away.
What’s next?
We’ll update this post as exploitation activity becomes clearer and once our detection updates are in place. If you’re a customer and have questions, or want help assessing your exposure, reach out to our team.
