PHP2shell: Patch Today, Then Prove It

If you run PHP anywhere, PHP2shell comes down to one task and one question. The task is patching. The question is whether you are actually exposed.

What happened, briefly

On October 21, 2026, the PHP Project shipped emergency fixes for two flaws, together called PHP2shell. These flaws let an attacker who has not logged in run code on your server. They are rated 9.2 out of 10 on the Common Vulnerability Scoring System (CVSS4.0). Fixed versions exist for four branches of PHP, and anything older than 8.1 will not get a fix at all. Probing was seen the same day the fix shipped, and at least one attempt was reported four days before the fix was public.

The first move is to patch to a supported version, confirm it actually took, and make a plan for anything too old to patch.

The two questions every team is asking

Since the fix shipped, we have been on a lot of calls, and they all focus on the same questions: “where do we run PHP?” and “could someone actually get in?”

The first one you can answer by looking. The second one you cannot, and that is where teams get stuck.

Why looking is not enough

PHP turns up in more places than the list of applications you think of as yours. It is tucked inside vendor appliances, baked into container images, running a marketing site an agency manages, or powering an internal tool nobody has touched in a year. A tidy inventory will miss most of these, because nobody files them as PHP.

And even where you know PHP is running, a vulnerable version is not the same as an exposed system. A flawed version on a server nobody can reach is a chore, but the same version on an exposed server with the wrong settings is a real risk. From a list alone, the two look identical.

There is one more wrinkle. The networks that sit in front of your sites are increasingly hiding the fingerprints an outside scanner uses to spot PHP. An external scan will miss things, and the only reliable way to find out whether a particular system is exposed is to check that system directly, with permission and with care.

Hard to exploit != Safe

You will read that PHP2shell is difficult to exploit reliably. That is true, but it is also not the reassurance it sounds like. Difficult means skilled people are busy making it easier, which is exactly what the early probing shows. And it means whether you are at risk depends on your own setup, host by host.

A scan tells you where PHP is, but a check tells you whether anyone can get in. One is a list, and the other is proof you can hand to your board.

What proof looks like

When we talk about checking, we mean something specific. Someone attempts the thing an attacker would, on systems you have named, with every step written down, and hands you back a record a second person can follow. If the attempt gets nowhere on a given system, that is worth knowing, though it is not a guarantee: it means the paths tried did not work, not that none exist. If it gets somewhere, you have found it before someone else did, and you have the evidence to act.

That record is what a board actually wants when it asks whether you are exposed, and it is what an auditor will take in place of a promise.

Where XBOW comes in

XBOW is an autonomous offensive security platform. The PHP2shell check has been rolled into every new assessment. Where the attempt succeeds, XBOW shows the exposure safely and gives you the full trace; where it does not, you see what was tried. You set the scope, every action is logged, and nothing runs outside what you allow.

XBOW can validate real impact even on PHP instances that off-the-shelf tooling would simply mark "possibly vulnerable" and move on. What we can do is run the check inside an assessment you already have, carefully, and give you proof you own rather than a number you have to trust.

If you are already a customer, run a new assessment; the check is included as the rollout completes and your account team can confirm it is on for you. If you are still evaluating, ask us, and ask every other vendor, for a trace rather than a score. With a flaw this fiddly, the ability to show the work is the whole test.

Your short list

1. Patch to a supported PHP version, and confirm it took.
2. Hunt down the PHP your inventory misses: appliances, images, sites others run, end of life versions.
3. Decide what to do about anything too old to patch.
4. Check the systems that matter, rather than assuming the patch closed the question.

Get more details in our checklist of PHP2shell steps to take today.