If your company has a website, there's a good chance PHP is running somewhere behind it, even if your team hasn't written a line of it in years. That's why PHP2Shell got so much attention so quickly. It's a pair of flaws in PHP, the programming language behind most of the web, that lets an attacker take over a server without logging in. The details leaked a day before the fix shipped, so attack tools were circulating almost as soon as the patch was.
The good news is that the attack arrives as an ordinary web request, so a protection layer in front of the application can recognize and stop it. The security community moved fast to publish protections, and that speed helps everyone. Blocking the request is also the part of the response most security teams already have a playbook for.
The questions we heard from customers went further. Where in our business do we even run PHP? Is anyone trying this against us right now? If someone got through, how would we know? Can we block it without breaking something customers rely on?
For the technical detail, the PHP project has published its advisory and the fixed versions, and our security advisory covers the Cequence specifics. Cequence's own products don't use PHP and aren't affected. The rest of this post is about protecting yours.
We've seen this pattern before
PHP2Shell is new, but this kind of flaw isn't. In 2014, researchers found Shellshock in Bash, a tool so basic that most people didn't know their web servers used it, and attackers reached it through ordinary web requests. The same year, Heartbleed let anyone ask a server for pieces of its memory, and that memory turned out to hold passwords and encryption keys. In late 2021, Log4Shell hit a logging library buried inside thousands of applications, and the hardest part for most companies was simply finding where it ran.
PHP2Shell combines all three. The flaw is in PHP itself, underneath the application, so a well-maintained website on an old version of PHP is still exposed. It allows a full server takeover, and it can also leak memory, which can include other users' passwords, login sessions and the keys your applications use to talk to each other.
Each of those earlier events taught the same lessons: know what you're running before the advisory arrives, watch what attackers do and what your servers send back, and assume leaked secrets will be used later. Those lessons are built into how Cequence protects applications today.
How Cequence protects a vulnerable PHP application
Cequence App & API Protection inspects every request before it reaches your applications, along with every response on the way back. That visibility is what lets it protect a PHP application while your team schedules the patch.
When an attacker goes after an unpatched PHP site protected by Cequence, a few things happen:
Cequence recognizes attack requests on the way in. PHP2Shell detections are already live across every Cequence deployment, and once you turn on blocking, Cequence stops those requests before PHP ever processes them.
Cequence also identifies the attacker behind the requests. Our behavioral analysis detects the client probing your sites and can block or challenge it across all of your applications, even after it changes addresses or modifies its tools.
Request limits cut off risky traffic by design. Cequence can cap request sizes and reject file uploads on pages that aren't built to accept them, which removes the entry point this attack depends on regardless of the exact payload.
Responses expose anything that gets through. If a server starts sending back leaked memory, Cequence sees it in the response and tells you which application and which client were involved.
Monitoring continues after the attack. If attackers later use leaked credentials against your APIs, Cequence spots the misuse.
Start with exposure
Most enterprises run more PHP than their asset lists show. Think of the marketing site, or the partner portal that came with an acquisition and never got migrated. Log4Shell made this clear: the vulnerable code was everywhere, and the inventories weren't up to date.
So the first job is a list of which of your applications run PHP and which of those face the internet. A protection layer usually covers the applications someone remembered to register with it. Cequence discovers APIs and applications from live traffic instead, so anything that receives requests shows up in the inventory. PHP applications are easy to identify once you're looking at real traffic rather than a spreadsheet.
That list drives the later decisions, from where it's safe to block aggressively to which teams need to patch first. The same list will guide the response to the next vulnerability.
Watch the whole attack, including the response
Within hours of disclosure, our threat research team saw attackers scanning several customers with publicly available attack tools. Initial rules keyed on fingerprints those tools leave behind. They worked on day one, but they would stop working the moment someone modified the tool, without anyone noticing.
So we built our detections around the parts of the attack that are hard to change, and rolled them out to every customer without any per-customer setup. They look at three stages:
Setup: the request that primes the server for the attack.
Attempt: the follow-up request that tries to use it.
Result: a server response that shows signs of having just leaked memory.
Read together, they tell you whether someone prepared an attack, tried it, and if they succeeded. The last one matters most. If you inspect only incoming requests, each new variation of the attack can evade detection. A detection that watches the response works no matter how the attacker changed the request, so it still fires if the attack succeeds.
These detections reach running deployments as a configuration update, with no software upgrade necessary.
Who sends the request matters too
One source we saw on day one came from a home internet address on a large consumer provider, shared with ordinary users of the same customer's applications. In about 45 minutes it probed 18 of that customer's sites. Since it was a home internet address, blocking the address would have blocked real customers along with it. Blocking the behavior, a single client running an attack sequence across sites it had not previously visited, would not have.
Our behavioral analysis looks at how each client behaves across an entire session and across the customer's applications, not just at one request in isolation. Attack tools spread across sites and repeat the same steps without doing what a person would do first, whatever vulnerability they're aimed at. Intent Graph, our behavioral fingerprinting, keeps tracking that client when it switches addresses or disguises itself, so the protection follows the attacker rather than the exploit. We made the broader case for this in why behavior outlasts vulnerability signatures.
Assume something leaked
The leak gets less attention than the server takeover, and it lasts longer. Heartbleed proved this: companies patched quickly, but stolen keys and passwords kept working long after. A server that handled logins or checkout may have exposed other people's sessions and the keys your systems use to call each other. Patching stops new leaks; it does nothing about secrets that were already stolen.
For any PHP application that showed signs of leaking or remained unpatched on the internet for a significant period, replace the credentials it used. Then watch the APIs those credentials give access to. A stolen key showing up from somewhere it has not previously been used, or a login session suddenly reaching into parts of the system its owner never touches, is API abuse, and it tends to appear days or weeks after the patch goes out. Cequence watches for that kind of misuse, which keeps it useful long after you patch.
Decide on blocking with your own traffic
When a flaw is this serious, the instinct is to switch everything to blocking right away. That instinct is reasonable. The trouble is that broad blocking affects file uploads most, which is the feature this attack abuses, and an outage there can hurt as much as the attack, depending on your business.
Our approach adds one short step: new detections run in watch-only mode against your real traffic first. Within a day you can see where they fire and whether any legitimate application triggers them. You then turn on blocking where that evidence says it's safe, and keep watching where it isn't.
The request-size and upload limits described earlier don't need to wait for any of that, and your Cequence team can help put them in place today.
The next one is already out there
PHP2Shell is the second major "2shell" flaw this year. Researchers used AI to help find the WordPress flaw disclosed in July, and attackers were exploiting it within days. AI is shrinking the time from an old bug to a working attack, so attackers will keep exploiting new disclosures faster.
The protections that helped this week don't depend on knowing the vulnerability in advance. Knowing where your applications are, tracking how attackers behave and seeing what your servers send back would have limited the damage from Shellshock, Heartbleed and Log4Shell, and they'll help with whatever comes next. We're also working toward answering the first question for you: when a vendor publishes an advisory, Cequence will have already flagged the affected parts of your environment and deployed a matching detection.
In the meantime, update PHP; it's the only complete fix. If you run PHP behind Cequence, contact your account team or Cequence Support to review what our detections have seen on your properties and decide where to block. If you don’t, and you want to learn more, contact us today.
