Working exploit code has gone public for a pair of critical PHP vulnerabilities, and security researchers say attackers have already attempted to use the flaws to plant botnet malware on vulnerable servers — though no confirmed breach has resulted yet.

Two Critical, Unauthenticated Flaws

The vulnerabilities, collectively nicknamed PHP2Shell, are tracked as CVE-2026-109618 and CVE-2026-109619. Both carry a CVSS severity score of 9.2 and, according to Sophos, can allow an attacker to execute arbitrary code on a vulnerable server without needing to log in first — the most dangerous category of web application flaw.

The two bugs stem from distinct underlying failures in how PHP manages memory and request data. CVE-2026-109618 can trigger memory corruption during the cleanup process that follows an out-of-memory condition. CVE-2026-109619, meanwhile, involves stale data from a previous request lingering in shared internal state, which a later, unrelated request handled by the same worker process can then inadvertently reuse. Both represent the kind of low-level memory-handling flaw that is difficult to spot through ordinary code review but devastating when a working exploit chain is assembled.

PHP released fixed versions on October 21, with patched releases available at PHP 8.5.12, 8.4.27, 8.3.36, and 8.2.35. The affected software spans a wide range of deployment configurations, including PHP-FPM, Apache’s mod_php module, php-cgi, FrankenPHP, and LiteSpeed. The Dutch National Cyber Security Centre, which published proof-of-concept code for the flaws on GitHub under the PHP2Shell name, has specifically flagged Apache mod_php deployments as carrying the highest risk, since exploitation there can occur before any application-level code even begins executing.

A Withdrawn Claim and a Careful Correction

Sophos initially suggested its telemetry showed signs of a successful compromise tied to the flaws, but the company walked that claim back in a correction issued October 22 at 21:21 UTC. The revised assessment: Sophos’s customer data shows scanning activity and a small number of failed exploitation attempts, but no evidence that any attacker actually achieved a successful compromise through these specific vulnerabilities.

That distinction matters. Security teams reading early, unconfirmed reports about “active exploitation” can easily conflate attempted attacks — which are extremely common within days of any high-profile CVE going public — with confirmed, successful breaches, which are a much rarer and more serious event. Sophos’s own correction is a useful reminder to treat initial incident claims with some caution until a vendor or researcher firms up the details.

The Intended Payload: An Updated Mirai Variant

Sophos researchers identified the payload attackers were trying to deliver as “Potassium,” which they assess is likely a variant derived from the long-running Mirai botnet family. In the observed attempt, the organization’s security controls intercepted and blocked the malicious traffic before the payload could actually land on a target system, meaning the malware itself was never successfully installed in that instance.

Even so, analysis of the blocked sample revealed a larger, apparently updated version of a Mirai-derived threat that researchers had previously tracked earlier in 2026, now carrying both additional download capability and features aimed at disrupting network traffic. Technically, the sample resolves an encrypted command-and-control address, issues an HTTP request, and checks for both a successful HTTP 200 response and the presence of Linux ELF executable “magic bytes” at the start of the returned file — confirming the downloader is specifically expecting to retrieve and run another Linux binary, not ordinary web content. The sample also supports fallback domain resolution through public DNS services, a resilience technique that helps botnet infrastructure survive the takedown of any single DNS provider. Like other members of the Mirai family, Potassium is built to conscript infected machines into launching distributed denial-of-service attacks against further targets.

Exploitation Attempts Predate the Patch

This isn’t purely a post-disclosure problem. Separate reporting indicates Amazon observed related PHP exploitation attempts as early as October 17 — four days before fixes were publicly released — suggesting some attackers had working knowledge of the flaws, or were probing for them, ahead of general disclosure. That timeline is a useful prompt for defenders to review logs going back further than the patch release date itself, rather than assuming risk began only once the CVEs were announced.

Patch First, But Don’t Panic Either

Sophos notes that successfully weaponizing the public exploit code is not trivial — the company says its own research team found reliable exploitation difficult to achieve even with the help of AI-assisted tooling. That’s a meaningful caveat: public proof-of-concept code existing does not automatically mean every exposed server is at imminent risk of compromise, since real-world conditions like differing PHP build configurations, worker process behavior, and installed dependencies can all affect whether an exploit actually works against a given target.

Still, the recommended response is unambiguous. Organizations should update to one of the patched PHP releases, or apply an equivalent vendor backport, as soon as possible. Because PHP is frequently bundled inside third-party products and appliances, administrators should check the actual runtime version used by each service rather than relying on a single command-line check, and restart affected services afterward to confirm patched code is in use.

Where immediate patching isn’t feasible, Sophos recommends removing exposed PHP systems from direct internet access, or placing them behind network-level authentication as a stopgap. The company has also added new firewall and intrusion-prevention signatures, though it stresses these are a temporary safeguard, not a substitute for the update itself.