Talk to an expert
PricingNewsTalk to an expert
Back to Newsroom
Threat Intel

PHP2Shell: Critical PHP Flaws Exploited Days Before Public Disclosure

Two 9.2-rated pre-auth RCE bugs in the PHP runtime are under active attack, and probing started four days before disclosure. Here's what happened and how to respond.

4T4Tify Team4Tify
Oct 22, 2026·5 min read
PHP2Shell: Critical PHP Flaws Exploited Days Before Public Disclosure

PHP2Shell: Exploitation Began Before Disclosure — Patch PHP Now

Two critical flaws in the PHP runtime itself, collectively dubbed PHP2Shell, are being actively exploited, and at least one attacker started probing for them four days before the bugs were made public. With PHP running behind a large share of the web, this is a patch-today event, not a patch-next-cycle one.

What happened

The issues are tracked as CVE-2026-109618 and CVE-2026-109619, both scored 9.2 (CVSS). They sit in core PHP code paths that almost every request touches (memory management and error handling) and allow unauthenticated remote code execution. Every release in the PHP 7.x and 8.x lines is described as affected. Because the weakness is in the runtime rather than in application code, any reachable PHP endpoint is a potential entry point: a contact form, a login page, even a health check. The CMS, framework or plugins in use make no difference.

The disclosure did not go to plan:

  • Pre-disclosure probing. Amazon's threat intelligence team reports an exploitation attempt against its honeypot network on 17 October 2026, from an anonymisation-service IP geolocated to Australia (103.216.220[.]92). How that actor got the details while the bugs were still under embargo is not known.
  • Early leak. Coordinated disclosure was set for 22 October, 14:00 UTC. CVE details and a proof-of-concept exploit leaked ahead of that, so the PHP Foundation brought the release forward by a day.
  • Embargo broken. Threat-intel firm ELLIO saw its first PHP2Shell request at 08:36 UTC on 21 October. That was less than an hour after Chainguard, which had received the patch in advance, published fixed images. The PHP Foundation criticised that move because it let attackers study the fix before most users could get it.
  • Mass exploitation. Amazon logged multiple PoC exploits from about 02:00 UTC on 21 October, followed by six hours of attempts from anonymised infrastructure. The variety of payloads points to several separate actors. Cloudflare reports attackers changing their payloads to slip past its rules. One WebOps provider says it blocked more than 60,000 probing requests on day one.
  • Fake PoCs. JFrog has found bogus "exploits" on GitHub that carry prank malware. Don't run untrusted PoC code to test your own servers.

The UK NCSC, CISA, the FBI, the NSA and many other national agencies have issued advisories. Their message is the same: patch immediately, or take exposed systems offline until you can.

Why it matters

  • Huge exposure. Internet-wide scans count somewhere between 2.6 and 4.4 million internet-facing PHP services. Most of them run branches the PHP project no longer supports: one estimate puts about 79% on end-of-life versions such as 7.4, 7.2 and 5.3.
  • Almost no trace. Researchers note that a successful attack can leave no application-log anomaly and no error responses. Often the only sign is a single memory-limit fatal error in the web server log, the kind of line that gets ignored as noise.
  • Shrinking patch windows. Exploits are now appearing within hours of a fix, and sometimes before it. AI-assisted patch diffing is making that faster.

What to do

  1. Find every PHP instance you run. That includes websites, internal tools, appliances, container base images and forgotten staging hosts. PHP often comes bundled in OS images and old stacks.
  2. Patch now. Install the fixed PHP release from the PHP project or from your OS, distribution or hosting vendor. On an end-of-life branch, check whether your vendor ships a backported fix (some, such as CloudLinux, already do), and plan the upgrade. If you can't patch quickly, take the exposed service offline or restrict access to it.
  3. Turn on WAF protections from your CDN or WAF provider as a stop-gap. Don't treat them as a fix, because attackers are already changing payloads to get around them.
  4. Hunt for compromise. Look for PHP worker processes that start shells or download files. Check for unexpected memory-limit fatal errors in web server error logs since mid-October, and for new files in web roots.
  5. Block and investigate the reported indicators. These include 103.216.220[.]92, 31.223.184[.]166, 37.19.200[.]5, 134.209.159[.]64, 103.114.163[.]188, 95.217.98[.]37, 85.11.167[.]243, 45.198.224[.]169, 109.71.252[.]97, and the user-agent php2shell-scan/109618. Many of these addresses belong to anonymisation services, so treat matches as leads to investigate, not proof.

Knowing which of your internet-facing hosts run a vulnerable PHP build is the first step. That is the kind of exposure our vulnerability scanning service is built to surface quickly across your whole perimeter, so remediation can start where the risk is highest.

Originally reported by The Hacker News. Rewritten and analysed by the 4Tify team.

SHARE