Php2Shell PHP vulnerabilities: Unauthenticated RCE and fixes

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.

Php2Shell is the name for two critical PHP remote code execution vulnerabilities, CVE-2026-109618 and CVE-2026-109619, patched October 21, 2026. Both memory-safety flaws let unauthenticated attackers run code on any PHP installation serving web requests, including PHP-FPM, Apache mod_php, and php-cgi. Fixed versions are PHP 8.5.12, 8.4.27, 8.3.36, and 8.2.35.

How does Php2Shell work? 

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 on October 21, 2026. 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.

Which PHP versions and servers are affected by Php2Shell?

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.

Is Php2Shell being exploited in the wild? 

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. 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.

How Expel detects Php2Shell exploitation

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 and restarting PHP workers prevents it. We can’t prevent exploitation of an unpatched, internet-facing system.

What can attackers do with Php2Shell? 

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.

How to patch and mitigate Php2Shell

1. 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.
2. 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.
3. Find all your PHP. Check CMS and e-commerce platforms (WordPress, Drupal, Magento), hosting control panels, container images, and vendor products that bundle PHP.
4. 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.
5. 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.
6. 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.
7. 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.

References

• PHP security advisory
• PHP advisory, CVE-2026-109618
• PHP advisory, CVE-2026-109619
• PHP advance notice
• CERT-EU Security Advisory 2026-018
• Tenable FAQ, including Cloudflare CTO statement
• The Hacker News
• Huntress rapid response
• BleepingComputer