PHP2Shell: a 30-minute response plan for sites you don’t host

1. Inventory what you’re responsible for

List every site, who hosts it, and the PHP version it reports. You can’t prioritise what you haven’t listed, and agencies routinely discover sites nobody remembered.

2. Prioritise by data and exposure

Start with sites that hold client or patient data and sites on Apache with mod_php, which the advisory flags as the highest-risk configuration. A brochure site on managed hosting can wait for the afternoon.

3. Ask the host in writing

• Which PHP build is running on this account, and when was it last updated?
• Does it include the fixes released on 21 October (8.5.12, 8.4.27, 8.3.36, 8.2.35, or the backports for 7.4 to 8.1)?
• Was PHP restarted after the update?
• Does your answer cover every site on the account?

4. Update or stage a stopgap

Move to a fixed build. If the application can’t take the upgrade today, restrict access to what you can and put the upgrade on the calendar. A WAF rule is a stopgap, not a fix: the maintainers’ own guidance is that updating is the only complete fix.

5. Verify and record

Confirm the running version after the restart, not the installed package. Write down what you checked, when, and who confirmed it. That record is what your insurer or client will eventually ask for.

A note on the threat picture

Reports conflict on how widely this is exploited, and Rapid7 found public proofs of concept work only on specific combinations of operating system, PHP version and web server. That argues against panic, not against patching.