PHP2Shell: Protect Your Clients, Then Replace the Apps You Can't Patch

PHP2Shell Reaches Every Client With a PHP Web Server

CERT-EU says the flaws affect every PHP installation serving web requests: PHP-FPM, Apache mod_php, php-cgi, FrankenPHP and LiteSpeed. The end-of-life branches, PHP 8.1 and older, are affected too. Wiz Research, which named the flaws PHP2Shell, says nearly every PHP version back to 5.4 carries at least one of them.

That scope is what makes this an MSP problem rather than a hosting problem. Client WordPress sites are the obvious place to look, and they aren't the whole list. Line-of-business portals, booking systems, intranet tools and the reporting page a developer built in 2014 all count, along with appliances and third-party products that embed PHP without saying so.

The question I'd ask of every client site is what breaks first and who finds out first, because on an unpatched server the answer is the attacker, then the hosting provider, then the client's own customers.

Work Each Client Through Five Steps

Go client by client, and finish one before starting the next. The order matters because each step tells you what the next one has to cover.

A Firewall Rule Buys Time, Not Safety

The claim worth testing first is that a web application firewall rule means a client is covered. Put it against the advisories and it doesn't hold. CISA says a web application firewall may provide some protection until systems are patched, and Wiz says Cloudflare, Fastly, Google, Vercel and other vendors published mitigations for customers who cannot patch immediately. That's useful, and if a client sits behind one of those services today, good.

But CISA only promises some protection from a firewall, and Wiz says the PHP update remains the only complete fix. A rule in front of the server narrows the ways in. It doesn't change the code that breaks. So treat a vendor mitigation as the thing that keeps a client safe while you schedule the patch, never as the patch.

End of Life Decides Whether a Fix Exists

Whether an old app can be fixed depends on two things: which PHP branch it runs, and who built that PHP. An end-of-life PHP app is a car whose maker stopped making parts: it still drives, and the first part that fails stays failed.

The bottom row is where your real work sits. A backport is a patch for this flaw, not support, and my view is that you shouldn't count on the next flaw in an unsupported branch getting one.

The App You Cannot Patch Is the Upgrade Conversation

Look for the app nobody wants to touch because the person who built it left, and it still works. Until this week, "it still works" was a defensible answer. An app on unsupported PHP now has a public, critical flaw, and for anything older than PHP 7.4 the advisories name no fix. That turns a nice-to-have upgrade into a risk the client's leadership can understand in one sentence.

I'd open the conversation with the record from step 5, not with fear. Show the client what you found, what you patched, what is isolated, and what it costs them to leave the isolated app offline. Then put two options in front of them: rebuild the app on a supported stack, or replace it with something off the shelf. Either way, the decision is theirs and the facts are yours.

My view is that this won't be the last time. Wiz says it found PHP2Shell with help from AI models, including Gemini 4 Argon and GPT-5.6 Sol. If that kind of tool can find critical flaws in PHP itself, I'd expect old, unmaintained application code to get the same attention, from attackers as well as defenders.

Rebuilding Old PHP Apps With Claude Code or Codex

My view is that coding agents such as Claude Code and OpenAI Codex are worth testing on exactly this work: reading an unfamiliar codebase, explaining what it does, and writing the replacement under an engineer's direction. If they hold up on your first app, some jobs that were too fiddly to quote could become worth quoting.

I don't buy the version where the AI does the project on its own. The pattern I'd use keeps a person responsible at every step:

1. Have the agent read the old app and write down what it does, including the odd behaviours the client relies on.
2. Turn that description into tests before any new code is written.
3. Rebuild on a supported PHP branch or another stack, and run the same tests against both versions.
4. Have an engineer review every change and own the cutover.

It depends on the app. A form-and-database tool is a good first candidate. Anything that handles payments or health records needs your normal security review on top, AI or not. Pilot one app, measure the hours it actually took, and price the next one from that.

A Rebuild Is a Project, and Maintaining It Is a Service

The money works on two lines. The rebuild is project work, typically billed at about $185 an hour blended, with 50% the gross margin to aim for on projects.

Take a hypothetical project engineer on a typical $84,000 salary. At a 1.25x burden for payroll taxes, benefits and insurance, excluding paid leave, they cost $84,000 × 1.25 = $105,000 a year. At 1,660 available hours and 85% utilization, they bill 1,660 × 85% = 1,411 hours. That puts their cost at $105,000 / 1,411 = $74.42 an hour, so each hour billed at $185 leaves $185 − $74.42 = $110.58, and $110.58 / $185 = 59.8% gross margin, above the 50% target.

Hours an AI agent saves on a fixed-price quote stay with you, as long as you price the outcome rather than the hours. Then sell the second line: a flat monthly fee to keep the rebuilt app patched, its PHP branch current and its dependencies updated. Say in plain words what that fee includes and what it doesn't. That is the service that stops this client being on next year's unpatched list.

Tell Us If You Want the How-To

We're considering a practical guide to having someone on your team use AI to upgrade clients' legacy apps: picking the first app, the test-first workflow, and pricing the project and the maintenance service. If you'd want that, say so in the comments below, and tell us what your oldest client app runs on.