PHP2Shell: Two Critical PHP Flaws Explained

The hardest part of responding to PHP2Shell, the nickname for two critical flaws in the PHP programming language, is finding every system that needs the patch. PHP runs behind websites, inside vendor appliances, control panels and content management systems, and plenty of those installations were never installed on purpose.

Two Critical PHP Flaws Could Let Attackers Take Over Servers

On October 20, the PHP Group gave advance notice of a security release to fix two critical vulnerabilities, CVE-2026-109618 and CVE-2026-109619, each rated 9.2 out of 10 on the CVSS severity scale. Security researchers and news outlets are calling the pair "PHP2Shell." On October 21, PHP released patches for the supported PHP versions and says updating is the only complete fix. eSentire has already taken steps to protect its customers while patching is underway.

Both flaws are remote code execution vulnerabilities, which means an attacker anywhere on the internet could run their own commands on a server that runs PHP, without needing a password (PHP says "all PHP installations serving web requests" are at risk). A server under an attacker's control can be used to steal data or as a foothold to move deeper into your network. The flaws affect PHP 8.2 through 8.5 releases earlier than the patched versions, as well as older end-of-life versions, which no longer receive regular updates and remain vulnerable unless they are fixed by hand or by a vendor. Both flaws come from mistakes in how PHP cleans up memory after handling a web request, and an attacker can trigger them on purpose. PHP says the risk is highest on web servers where PHP is built directly into the Apache web server software. PHP has shown that in this setup, a request from anyone on the internet, with no login, can trigger the attack before the website's own code even runs.

Attackers Are Already Targeting PHP2Shell

As of October 21, 2026, eSentire has identified exploitation attempts against these vulnerabilities using publicly available exploit code. In one initial observation, a modified version of that code appeared less than an hour after it was posted to GitHub. Security researchers at watchTowr observed exploitation attempts against honeypots, decoy servers set up to attract attackers, starting October 21, and Cloudflare has also confirmed similar activity and released protections for its customers. On October 26, CISA, the U.S. government's cybersecurity agency, added both vulnerabilities to its list of known exploited vulnerabilities, which confirms exploit attempts. Honeypot researchers have since recorded attackers successfully running code on unpatched honeypots.

Some of this activity predates the patches. The earliest documented attempt comes from Amazon Threat Intelligence, which saw an exploitation attempt on October 17 against its own decoy servers. eSentire's threat hunting has found no evidence of successful compromise in customer environments so far. Given how widely PHP is used and how much technical detail is now public, the eSentire Threat Intelligence team assesses with high confidence that threat actors will be highly motivated to improve their exploits. VulnCheck's analysis supports that assessment. The vulnerability intelligence firm says it has built a working exploit of its own that gets past a common memory protection, which shows successful attacks are possible. Attackers still need to get past other defenses, and patching is under way. Censys, a firm that scans the internet, is tracking remediation, with a live public dashboard showing how many PHP servers have been patched.

Patching does not remove an attacker who is already inside. Signs to look for include hidden back doors known as web shells, unexpected files, new administrator accounts, unusual outbound connections, and modified PHP files.

The Hard Part: Knowing Where PHP Is Installed in Your Environment

PHP shows up in places most teams would never think of looking. Some installations arrived bundled inside other software, and others may be tools your team never approved.

PHP 8.1 and older are past end of life. They no longer receive regular updates from the PHP project. PHP released only minimal source-code fixes for versions 8.1, 8.0 and 7.4, with no ready-to-install release, and nothing for older versions. Some Linux distributions and long-term support vendors provide their own fixes, but systems without a vendor behind them need to be rebuilt from the source, or isolated and replaced with maintained alternatives, which takes budget and planning. Even PHP 8.2, which received its fix on October 21, reaches end of life on December 31, 2026.

Your Asset Inventory Says "No PHP." It Could Be Wrong.

Most organizations answer the "where are we running it?" question by asking their security and IT tools. The trouble is that software inventory comes from many places: endpoint agents, vulnerability scanners, cloud consoles, and asset management systems. Each one records product and vendor names its own way. One tool lists a vendor's full legal name, another abbreviates it, and the security advisory uses a third format.

Think of searching your contacts for "Robert Smith" and missing "Bob Smith" and "Smith, R." An exact-match search across your inventory works the same way. It can come back clean while vulnerable PHP installations sit in your environment under a name nobody searched for, even when your team has done everything right.

During an event like PHP2Shell, teams are working through vendor advisories, threat intelligence, scanner output and alerts all at once, often across many consoles. With patches out and attackers actively exploiting the flaws, the questions that matter are which systems are exposed, which ones face the internet and which to patch first. Answering them quickly requires the right data in one place.

eSentire addresses this by leveraging the Atlas Sensor. We pull asset and software data from across your security and IT vendors and telemetry sources into a single view, then reconcile the different names each tool uses for the same software. That gives you one consolidated picture of where PHP is installed and, depending on the telemetry source, which versions are running, regardless of which scanner or agent reported it.

How eSentire Protects You While Patching Is Underway

Knowing where PHP runs answers the first question, "Am I exposed?" The second question is just as pressing: how are you protected before every system is patched?

eSentire's Threat Response Unit (TRU) started preparing on October 20, when it learned of the upcoming release. The team identified which customers run PHP, planned threat hunts, and prepared customer communications. TRU expected a wave of attacks across the internet once details were public, so it focused first on customers who run PHP. On October 21, TRU began studying the exploit code and technical details to decide where to hunt, starting with systems known to run PHP. Because eSentire knows what software runs on customer systems, the team could focus on the systems an attack could actually succeed against.

Following that work, TRU deployed detections across Atlas for Network, and Endpoint which are in production now. These detections will continue to be refined as new information emerges. TRU is also running threat hunts on customer devices, and eSentire's security operations team will contact any impacted customers. On the exposure side, eSentire's Preempt solutions are scanning for PHP2Shell.

The full details are in eSentire's security advisory on PHP2Shell and its October 21 update, which lay out the actions eSentire is taking and what customers should do next. They will be updated as new information emerges.

How Your IT and Security Teams Can Remove Exposure

Detections reduce risk while systems remain unpatched, but your own teams still need to find and patch every affected system. Start with these questions and actions, drawn from our advisory:

• Where does PHP run? Ask for a full list that includes web servers, vendor appliances, bundled Windows software, control panels and CMS platforms. VirusTotal and NCSC-NL have both published guidance on identifying vulnerable devices.
• How do you know the list is complete? Ask how inventory sources were reconciled, since different tools may name the same software differently.
• Who is patching, and by when? Fixed releases are available now (PHP 8.5.12, 8.4.27, 8.3.36 and 8.2.35), and PHP says updating is the only complete fix. Vendors of appliances and Linux distributions may ship their own updates, so check with them. If patching is not immediately possible, apply the temporary mitigations provided by the PHP Group, which reduce exposure but does not make installation safe.
• What cannot be patched? Identify end-of-life PHP instances. They remain vulnerable and get no regular updates, so isolate them and plan their replacement.
• Have we already been hit? If compromise is suspected, isolate the server, preserve web server and PHP logs, and review for unusual activity.

The patches are out. What remains is finding every system that needs one and checking whether any were already used against you.

Sources

ABOUT THE AUTHOR

Nadine Abdulkarim Senior Content Marketing Manager

As Senior Content Marketing Manager, Nadine Abdulkarim leads content and social media strategy at eSentire, contributing to the development of security-focused content across marketing channels. She has over a decade of experience in marketing, communications, content, and technical translation, with several years specializing in cybersecurity. Nadine holds a Master of Arts in French Studies and an Honors Bachelor of Arts in French Language and Literature, both from Western University in London, Ontario.