At a glance
- PHP2Shell fires in PHP’s request parser, before any application code runs, so an attacker needs no login and no user interaction.
- The only precondition is reachability: if a packet can arrive at your listening port, the exploit can run.
- Exploitation started before the patch shipped, so patching is necessary and never closes the window fast enough.
- The durable fix is to stop exposing the port at all, so an unauthenticated attacker can’t reach the service in the first place.
The Week PHP Broke
On October 20, 2026, details of two critical PHP vulnerabilities leaked a day ahead of their planned disclosure. Within hours, Cloudflare reported active exploitation and pushed emergency firewall rules, and PHP shipped patches earlier than scheduled. The pair, tracked as CVE-2026-109618 and CVE-2026-109619 and nicknamed PHP2Shell, carries a CVSS score of 9.2 and allows remote code execution on vulnerable web servers.
That reaches almost everyone, because PHP powers close to 70% of the websites with a known server-side language. WordPress, Drupal, Magento, Joomla, cPanel, and countless internal applications all sit on top of it. The detail security teams should sit with, though, isn’t the CVSS score. It’s where the flaw lives and when it fires.
The Flaw Runs Before Your Login Does
Both PHP2Shell bugs live in the PHP engine itself, in the code that parses an incoming HTTP request in memory. That parsing happens before any of your application code runs. Your authentication check, your framework’s security middleware, and your carefully written access rules haven’t executed yet. As the Dutch NCSC put it, “a simple POST request may be enough to execute external code on a vulnerable web server.” No credentials, no valid session, no user interaction.
When that code executes, it runs with the privileges of the web server process, which is usually enough to read application secrets, reach the database behind it, or drop a web shell for later. A flaw this deep in the stack doesn’t care how well your application is written, because your application never gets a vote.
So the usual mental model, where a login gate protects the application behind it, falls apart. The attacker never reaches your login. They break the service one layer below it, in the part of the stack you didn’t write and can’t easily inspect.
An Open Port Is a Target You Can’t Talk Your Way out Of
Here’s the uncomfortable part. The only precondition PHP2Shell really needs is reachability. If an attacker’s packet can arrive at your web server’s listening port, the exploit can run. That’s why, within a day of disclosure, automated scanners were sweeping the internet for open ports on servers running PHP.
An exposed port answers anyone who knocks: a legitimate customer, a researcher, a botnet, or a scanner probing for the next CVE. The port can’t tell them apart, because telling them apart is the application’s job, and the application hasn’t woken up yet. Every service you publish to the internet is a service that can be attacked, enumerated, and, in cases like this, broken without a single valid login.
“Internal” is thinner protection than it sounds, too. The same reporting notes that intranets and CRM systems get reached through routing mistakes, supplier connections, and flat networks all the time. A port you believe is private is still a port.
Patching Is Necessary, and It’s Never Fast Enough
The right response to PHP2Shell is to patch, restart your workers so the old code leaves memory, and hunt your logs for signs you were hit before you got there. Do all of it.
Then notice the timeline. Exploitation started before the patch existed. Several organizations, including hospitals and a university, pulled affected sites offline as a precaution rather than risk the gap. That’s the pattern with every serious pre-authentication vulnerability: a window opens between “attackers have it” and “you’ve deployed the fix,” and during that window, your open port does exactly what it was built to do, which is accept connections from anyone. You won’t win that race every time, and the next PHP2Shell is already in someone’s research queue.
Make the Service Unreachable, Not Just Defended
There’s a more durable answer than out-racing each new exploit. Stop exposing the port at all.
NetFoundry builds on a Zero Trust overlay where services have no open inbound ports on the public internet. Instead of listening for connections, an application makes an outbound-only connection into an identity-based network, and it accepts traffic only from endpoints that present a cryptographically verified identity. There’s no port for a scanner to find, so there’s nothing to probe, enumerate, or hit with a pre-authentication payload.
In that model, an unauthenticated attacker can’t reach the PHP engine in the first place. The exploit that runs before your login never gets to run at all, because the connection that would carry it is refused at the network layer, before a single byte reaches your parser. Even an endpoint that is allowed in reaches only the specific service it’s authorized for, not the flat network behind it, so a single compromised identity can’t roam. Patching closes the hole you know about. Closing the port closes the ones you don’t.
The Takeaway
PHP2Shell is a sharp reminder that your login isn’t your first line of defense. It’s one of your last. Everything in front of it, including the open port, the listening service, and the request parser, is reachable by anyone who can route a packet to you. Reduce what’s reachable, and you shrink the problem to a size patching can actually keep up with.
See how NetFoundry removes inbound ports from your attack surface. Explore the NetFoundry platform.
Want to pressure-test your own exposure? Talk to us.
FAQ
What is PHP2Shell?
PHP2Shell is the nickname for two critical PHP vulnerabilities, CVE-2026-109618 and CVE-2026-109619, each rated CVSS 9.2. They live in the PHP engine’s request-parsing code and allow remote code execution on vulnerable web servers. Supported branches were patched in PHP 8.5.12, 8.4.27, 8.3.36, and 8.2.35.
Does exploiting PHP2Shell require a valid login?
No. The flaw fires before any application code runs, so authentication, session checks, and framework security never get a chance to apply. An unauthenticated request can be enough to run code on a vulnerable server.
I’ve patched PHP. Am I safe from this specific bug?
Patching the affected server and restarting PHP-FPM or Apache so the old code leaves memory addresses this vulnerability. It does nothing for the next pre-authentication flaw, which is why reducing what’s reachable from the internet matters beyond any single CVE.
How does closing inbound ports actually help?
If a service has no open inbound port on the public internet, there’s nothing for a scanner to find and no path for an unauthenticated payload to travel. With NetFoundry, applications connect outbound into an identity-based overlay and accept only cryptographically verified endpoints, so a pre-authentication exploit can’t reach the service to begin with.
