Early bird gets the shell

Your 30-day patch window will reassure you, right up until someone tries the exploit four days before the patch exists.

Imagine the locksmith rings to say your front door lock is faulty, and a new one will be ready next Tuesday. Very kind of them. Except the doorbell camera shows someone was already trying the handle last Friday!

That’s PHP2Shell. Two critical flaws in the PHP engine itself let an attacker run code on your web server without logging in. Your app can be perfectly secure and still sit behind a dodgy lock, because the problem is in the PHP underneath it. If PHP serves web requests anywhere in your estate, assume you’re in scope.

Who started the clock?

Amazon’s honeypots caught someone trying the exploit four days before it was announced. On patch day, working exploits were out twelve hours before the fix. Amazon’s CISO, CJ Moses, put it bluntly: “A 7-day or 30-day SLA assumes a delay that no longer exists.”

So what’s wrong with 30 days?

Most security policies say the same thing. Critical in seven days, high in thirty, and the clock starts at the advisory. That rule was written for a world where attackers needed weeks to turn a bug into an exploit.

That world’s gone.

I argue the 30-day SLA now does more harm than good, because it tells everyone they’ve got time. They haven’t. Even the US government gave its own agencies three days to patch this one.

Of course, the patch itself is the easy bit. apt upgrade doesn’t care how scary the CVE is. The slow bit is the question nobody can answer when the advisory lands: which doors have the dodgy lock? (Spoiler: more than your CMDB thinks!) PHP hides in agency-built marketing sites, in container base images, in distro packages on VMs nobody’s logged into since 2022, and on the WordPress box someone yeeted up for a campaign. When you can’t find them fast enough, the only safe move left is switching things off. The simple maths on that is lost revenue for every hour it’s down.

What do I do on Monday?

Build the map before the next advisory, and use it today.

1. Find every copy. On AWS, Systems Manager Inventory can list PHP across your instances, but only if Inventory was already switched on (if it wasn’t, an empty result means “don’t know”, not “safe”):

   aws ssm get-inventory --filters "Key=AWS:Application.Name,Values=php,Type=BeginWith"

   Amazon Inspector findings for CVE-2026-109618 and CVE-2026-109619 are your second net.

2. Search your code, not just your servers. This catches FROM php images, apt install php on plain base images, and multi-stage builds:

   grep -rniE "php" --include="Dockerfile*" .

3. Check versions, not vibes. Run php -v on hosts and syft <image> | grep -i php on images. Anything below PHP 8.5.12, 8.4.27, 8.3.36 or 8.2.35 goes on the list.

4. Patch in order. Internet-facing first. Rebuild images from patched bases rather than patching the running container (it’ll come straight back on the next deploy).

5. Mitigate what has to wait. Amazon suggests blocking multipart file uploads on PHP you can’t patch yet, once you’ve checked what that breaks.

6. Look back from the 17th, not the 21st. Search form-upload POST requests for the PHP_SESSION_UPLOAD_PROGRESS string from 17 October onwards. A patched server isn’t proof nothing happened before the patch.

Remember, step one decides how long everything else takes. If your map is a spreadsheet and a Slack thread, you’ve already lost days.

Can you really do it in minutes?

For one Nordic enterprise running 300+ AWS accounts, we applied and verified one security rule across 21 security groups in 13 regions in 15 minutes, during a non-production pilot. Finding and fixing every door at once, across hundreds of accounts, is a job for minutes, not sprints.

Your estate is probably smaller, and your advisory day will still feel longer. Anyway, don’t be like me and find out where your PHP lives from the incident channel. Here at Firemind we’ve built the IT Operations Engine to keep an up-to-date map of what runs across your cloud and your code, patch it in order inside your rules, and hold higher-risk changes for a human, with every action recorded for when the board asks “were we exposed?”. Try it on a four-week pilot on one part of your live cloud, with no spend commitment.

Find every PHP runtime in your AWS estate → AWS Marketplace