CYBUNKR

PHP2Shell:what to do now

Published

Two critical PHP flaws, CVE-2026-109618 and CVE-2026-109619, can let an attacker run code on a web server without logging in. What is affected, what has been seen so far and what to do.

On 21 October 2026 PHP released fixes for two critical vulnerabilities, known together as PHP2Shell. PHP says both can allow unauthenticated remote code execution: someone who can send requests to a PHP website may be able to run their own code on the server, without logging in.

What is affected

PHP says all PHP installations serving web requests are at risk, including PHP-FPM, Apache with mod_php, php-cgi, FrankenPHP and LiteSpeed. It considers the risk highest for mod_php, where a request can trigger the attack before any application code runs. The flaws are in PHP itself, so keeping WordPress or another application up to date does not help on its own.

  • CVE-2026-109618, RCE via out-of-memory corruption: running out of memory can interrupt PHP while internal request data is only partly set up, and the clean-up that follows may treat that data as valid.
  • CVE-2026-109619, RCE via stale global state: internal state from one request can outlive the memory behind it, and a later request on the same worker may use it.

PHP rates both 9.2 out of 10 (CVSS v4.0); NIST's National Vulnerability Database rates both 9.8 (CVSS v3.1). PHP is also built into appliances, network devices and management interfaces, where you may not be able to update it yourself.

What has been seen so far

Reports differ on how much of the activity is succeeding, so treat this as a snapshot from 22 October:

  • Amazon Threat Intelligence saw an exploitation attempt against its honeypots on 17 October, four days before the fix, and says PHP2Shell is now being broadly exploited in the wild.
  • Cloudflare says it saw attack traffic against its customers while the details were leaked, and had WAF protection in place about 9 hours before public disclosure: customers on its free and paid plans were protected by default from 03:02 UTC on 21 October.
  • watchTowr has observed exploitation in the wild through its honeypot network since 21 October.
  • Sansec says the public exploits do not work against a default PHP installation and most need the application to have a separate file inclusion flaw. Sophos has seen scanning and failed attempts, but no successful compromise.
  • The UK's NCSC is encouraging UK organisations to take immediate action. CISA had not yet added either flaw to its Known Exploited Vulnerabilities catalog.

Code claiming to exploit PHP2Shell is circulating publicly. Unverified exploit code is sometimes laced with malware, so don't run it to test your own systems.

What to do

  • Update PHP to 8.5.12, 8.4.27, 8.3.36 or 8.2.35, or install your Linux distribution's patched package. Distributions often backport the fix without changing the version number, so check the vendor advisory rather than relying on php -v.
  • PHP 8.1 and older get no official release. Use a distribution or long-term support vendor package, PHP's source backports for 7.4, 8.0 and 8.1, or move to a supported version.
  • Find the PHP you don't manage directly: hosting, containers, appliances and vendor products that bundle it. Apply vendor updates as they arrive. NCSC-NL keeps a list of affected products.
  • Put a web application firewall in front: Cloudflare's WAF blocks known PHP2Shell attacks by default, and other WAF providers may have rules too, so check with yours. It buys time while you update, but only if attackers can't go around it to your server directly. See If you use Cloudflare below for how to lock that down.
  • If you can't update straight away, PHP's temporary measures in its advisory reduce exposure but don't make an installation safe. NHS England advises considering taking vulnerable systems offline until they are patched.
  • Look back to 17 October: check logs and internet-facing systems for signs of compromise from at least that date, not just from the day you patched.

If you use Cloudflare

Cloudflare says customers using its free or paid WAF have been protected by default since 03:02 UTC on 21 October, and its Managed Ruleset now has seven blocking rules for PHP2Shell. It has also seen attackers changing their payloads to try to get past those rules, so treat the WAF as a way to buy time, not a replacement for updating. It only helps if attackers can't reach your server directly:

  • Proxy every record: make sure the DNS records for your site are proxied (orange cloud), and check DNS-only records such as mail, SPF and old subdomains don't give away the server's real IP address. Cloudflare suggests changing the origin IP after moving behind it, because old DNS records stay public.
  • Only accept Cloudflare at the origin: set the server or cloud firewall to accept HTTP and HTTPS only from Cloudflare's published IP ranges and drop everything else, so nobody can bypass the WAF by connecting to the server's IP. The ranges change from time to time, so update the list automatically from cloudflare.com/ips rather than copying it once. Your logs will then show Cloudflare's addresses, so restore the real visitor IP from the CF-Connecting-IP header, which you'll need when checking for signs of attack.
  • Prove the request came through your account: Cloudflare's IP ranges are shared by all its customers, so add Authenticated Origin Pulls, where the server only accepts connections that present a Cloudflare client certificate. Cloudflare notes its shared certificate only proves a request came from the Cloudflare network, so upload your own for stricter security.
  • Use Full (strict) encryption: in Full (strict) mode Cloudflare checks the server's certificate is valid, unexpired and matches the hostname. A free Cloudflare Origin CA certificate is the simplest option when the server only receives traffic through Cloudflare. Cloudflare doesn't send expiry reminders for these, so track the expiry date yourself.

Other recent PHP fixes

On 24 September 2026 PHP also fixed two less serious flaws: an out-of-bounds read in the HTTP stream wrapper when following a redirect with an empty Location header (CVE-2026-93682), and an out-of-bounds read that can leak memory through the convert.* stream filters (CVE-2026-92842). Updating to the latest release covers these too.

How we can help

If you're not sure where PHP runs in your organisation or whether it's patched, get in touch. Our Penetration Testing looks for exposed and unpatched systems, and Risk, Compliance & vCISO helps you build the process to patch quickly next time.

Sources