Reachability – when you need to address big issues quickly, you have to start with what’s Internet facing. And unfortunately, we had to deal with a lot of that this week.
When PHP2Shell broke last week, almost every PHP web server on the internet became a one-request takeover target. With PHP behind roughly 70% of websites, according to Wiz, security teams all faced the same question: of all the places PHP runs, which can an attacker actually reach, and how far could they get from there? It won’t be the last time they have to ask. As AI tools uncover more flaws like this and shorten the path from bug to working exploit, reachability is what decides where to act first.
We asked the same question of our own products. Tufin’s exposure to PHP2Shell turned out to be negligible, and hot fixes for the separate eMudhra certificate compromise, which also surfaced last week, are on the way. You’ll find the details at the end of this post.
On October 21, the PHP project shipped emergency fixes for two critical vulnerabilities now known as PHP2Shell. An attacker can use them to run code on a web server with a single unauthenticated request, and almost every PHP installation that serves web traffic is affected. The fallout was immediate. Within hours, government and company sites across Europe went offline while teams patched, and the UK’s NCSC advised taking down anything that couldn’t be fixed right away.
The flaws themselves aren’t new. They sat in PHP’s code for more than a decade, and until recently, turning them into a working exploit was more effort than most attackers would spend. AI changed that math. Wiz has described PHP2Shell as an AI inflection point, and Amazon’s threat researchers saw someone attempt the exploit four days before the bugs were even announced.
In a separate incident the same week, the certificate authority eMudhra revoked eight intermediate certificates after a researcher showed their private keys could be recovered in seconds. The two incidents have nothing technically in common, but they leave security teams in the same spot, with more to fix than time to fix it and attackers who increasingly work at machine speed.
Start with what attackers can reach
Your vulnerability scanners can tell you where PHP is running. The harder question, and the one that matters now, is which of those systems an attacker can actually get to.
Two PHP servers can carry the same severity score and pose very different risks. One sits behind several layers of segmentation, while the other answers requests from the internet. With exploits already circulating and improving rapidly, internet-facing systems have to be patched, isolated or shielded behind a web application firewall (WAF) first, and everything else can wait its turn based on how exposed it really is.
A scanner report alone can’t answer that, because reachability isn’t a property of the server. It’s decided by the firewall rules, cloud security groups, SASE policies and routes that sit between the server and the outside world.
If one server falls, how far can an attacker get?
Exposure determines where an attack can begin, and blast radius determines how much damage follows. A PHP server compromised before it’s patched gives the attacker a foothold. What happens next depends on what that server can reach, whether that’s the database behind it, the internal apps beside it or the rest of the data center.
Picture how it plays out. An attacker on the internet sends a single unauthenticated, malicious HTTP request, exploits PHP2Shell and starts running code with the web worker’s privileges. The web server is now compromised. If a segmentation boundary is enforced around it, though, the attacker’s next moves hit a wall: the server can reach the database only in the ways the application requires, it can make only the internal API calls it actually needs, and connections to other servers are denied, so there’s no lateral movement. The server is lost, but the damage stops at the boundary, because segmentation denies every connection the server never needed in the first place.
That’s the job of segmentation, and increasingly microsegmentation. Done well, it keeps one compromised workload from turning into many. The catch is that segmentation drifts. Rule changes, migrations and new subnets can open paths nobody intended, so this is a good week to confirm the boundaries around internet-facing servers still hold. Our 4-step checklist for continuous segmentation assurance is a quick place to start.
How Tufin helps
Tufin models connectivity across firewalls, cloud, SASE and microsegmentation in a single, live view of the network. Bring in vulnerability scanner data, and security teams can see which vulnerable assets are reachable from the internet and which paths lead to them. They can trace that exposure back to the specific rules that create it, across every vendor in the estate, and shrink the attack surface from there. Remediation gets ranked by what attackers can actually reach, not by severity score alone.
The same model shows what a compromised server could reach next and whether microsegmentation is really blocking that traffic, and Segmentation Intelligence checks whether segmentation still matches its design. When a system can’t be patched right away, teams can restrict its access as a compensating control, with each change risk-checked, approved and recorded.
What to do this week
- Patch PHP to 8.5.12, 8.4.27, 8.3.36 or 8.2.35, beginning with internet-facing systems.
- Track down every PHP system reachable from the internet, including the ones nobody remembers deploying.
- If a system can’t be patched yet, put it behind a WAF, or restrict or remove its internet access.
- Make sure segmentation around those systems still holds, so a compromised web server can’t reach critical assets.
- Audit where your environment relies on TLS, and make sure every product in that chain, from VPNs and browsers to operating systems, has removed the compromised eMudhra intermediates and root from its certificate trust store, including stores used for mTLS.
- Watch for advisories from your network and security vendors, and apply fixes as they’re released.
The bigger shift
PHP2Shell won’t be the last vulnerability of this scale that AI helps uncover. As the gap between a hidden flaw and a working exploit keeps shrinking, the teams that already understand their network will spend that time fixing problems rather than searching for them.
For a look at the same reachability question applied to AI agents, read Once an AI Agent Is In, How Far Can It Go?
What we’re doing at Tufin
Like many enterprise products, the Tufin Orchestration Suite and TufinOS ship their own certificate trust stores, so the browser and operating-system updates released last week don’t cover them automatically. Our R&D teams began remediation as soon as the compromise was disclosed. We’re blocking the affected certificates in every runtime and base image we ship, and we’re delivering the fix as hotfixes for all supported versions as a top priority, so customers can apply it without waiting for a feature release. The first hotfixes will be:
- TOS R25-2 PHF5.0.0
- TOS 5.4.10
- TufinOS 4.90
As for PHP2Shell, our assessment found negligible exposure across the Tufin Orchestration Suite and TufinOS. All currently supported versions of TOS run without PHP anywhere in the stack, and the few findings, such as a sendmail.php component used in older TOS versions, were housekeeping in nature. Details will be included in the release notes, and we’ll notify customers as soon as updates are available. Customers with questions in the meantime can reach out to their Tufin account team or Support.
Behind that response is a bigger change in how we build software. We’re transforming our Product-R&D organization into an AI-powered software factory, where AI is built into every stage of our development lifecycle, from design and coding through testing, release and production. The eMudhra response shows why this matters: a single compromise touched code libraries, container images and the operating system across several supported versions at once. A software factory lets us identify what’s affected, apply the fix, and rebuild, validate and ship it across our platform far faster than a traditional release process allows. The same capabilities that speed up our response to vulnerabilities also help us bring new solutions to market sooner, so our customers get what they need when they need it, whether that’s a security fix or a new capability.
Ready to Learn More
Get a Demo
