‘PHP2Shell’ Bugs Signal Red Alert for Security Industry

Security teams are scrambling to remediate two critical PHP vulnerabilities following leaked details and reports of exploitation attempts.

A pair of critical vulnerabilities tied to open source scripting language PHP appear to have significant consequences for much of the server infrastructure holding the Internet afloat.

These vulnerabilities, dubbed “php2shell” by some researchers, include CVE-2026-109618 and CVE-2026-109619. CVE-2026-109618 enables remote code execution (RCE) via out-of-memory corruption, and CVE-2026-109619 enables RCE via a stale global state. The vulnerabilities, discovered by infosec consulting firm Calif, were designated with a critical CVSS v4.0 score of 9.2.

According to a WatchTowr blog post, both PHP vulnerabilities let an attacker run their own code on a Web server without logging in. “It stems from stale internal data that survives after its memory is freed; a later request handled by the same worker can use that leftover data, and PHP confirms this can let an attacker run their own code on the server without logging in. Reaching the server over the network is enough; no account or prior access is needed,” researchers said in the blog post.

Patch Your Web-Facing PHP Servers Now

Organizations should update affected servers to PHP 8.5.12, 8.4.27, 8.3.36, or 8.2.35 to protect against the flaws. As 8.2 through 8.5 are the supported versions of PHP, lower numbered versions do not have a patch available, meaning organizations must either upgrade their PHP versions to a supported branch or use a backported fix. PHP’s security advisory urges that while only an update is a complete solution, organizations can take certain actions to reduce exposure until that time.

PHP’s maintainers initially said yesterday that an emergency security release was scheduled for Wednesday at 14:00 UTC alongside coordinated disclosure, but as WatchTowr’s blog post explained, the embargo broke. A proof of concept tool called “PHP2Shell” came to light, and WatchTowr claimed to be able to recreate both vulnerabilities.

John Hammond, senior principal security researcher for Huntress, tells Dark Reading that there was a silver lining in the leak in that it “pushed defenders to inventory systems, prepare mitigations, and get ready to patch sooner.”

On the other hand, “that same early warning was available to attackers, who were undoubtedly spinning up AI and LLMs to find the vulnerabilities, identify targets, and start developing or adapting exploits,” Hammond adds.

This may not be theoretical risk, either; WatchTowr reported it has observed exploitation attempts of both flaws in the wild. Jake Knott, head of threat intelligence for WatchTowr, tells Dark Reading that while no one has been successful yet, the company does not expect this to be the case for very long.

The vendor said the potential for exploitation is broad across vulnerable PHP installations, and security teams should prioritize “internet-facing servers running PHP as an Apache module,” as the PHP Foundation highlighted that configuration as having the highest risk.

“Every PHP installation that serves web requests is in scope, including PHP-FPM, Apache’s mod_php, php-cgi, FrankenPHP, and LiteSpeed, and PHP says the risk is highest on mod_php, where an attack can succeed before any application code runs,” WatchTowr’s blog post read. “Session Upload Progress, a feature turned on by default, offers one confirmed path to the problem, so most default deployments meet that precondition.”

More Critical Bugs Involving Open Source Projects

PHP is a common, highly supported programming language run on servers across the globe and used for web development. The scope of organizations using PHP spans the Internet, from enterprises to small businesses, critical infrastructure, and municipalities. Many organizations, like the Netherlands’ National Cyber Security Centre (NCSC), took websites and services down to limit exposure and/or facilitate emergency patching.

As the Independent Federated Intelligence Network, a not-for-profit cyber intelligence group, warned in a Mastodon post, “If you are able to contact folks at local schools, governments, nonprofits, and other services to warn them about the PHP vulnerabilities, please consider doing so. These locations often do not have dedicated security staff and almost certainly have PHP assets exposed.”

In a blog post, Huntress’s Hammond recommended inventorying every PHP install, identifying end-of-life PHP installs, and alerting on “PHP worker processes launching shells, interpreters, or download tools.”

Despite the leak and the resulting chaos, PHP maintainers acted quickly to give organizations lead time for two challenging vulnerabilities. Patrick Münch, chief security officer at Mondoo, praised the PHP Foundation’s response. He worries, however, about the resources of open source organizations, which have to support this kind of work often under a volunteer basis.

“I think the PHP team handled this well. They warned people a day ahead, Linux distributions got the patches early, and they even wrote fixes for old versions they don’t support anymore. A lot of commercial vendors wouldn’t do that,” he says. “Where it gets harder is everything after php.net. PHP gets packaged and shipped by distributions, hosting companies, and software vendors, and a lot of those are volunteers or very small teams.”

Indeed, the PHP2Shell flaws echo the Log4Shell vulnerability in Log4j 2 nearly five years ago, which similarly required the security industry to come together to collectively patch a major flaw in a popular open source project.