A decade-old bug became exploitable in a week

On October 21, 2026, PHP shipped fixes for PHP2Shell, two CVEs (CVE-2026-109618 and CVE-2026-109619, CVSS 9.2) in the core PHP engine. An unauthenticated attacker can execute code as the PHP web worker or read live process memory, including passwords, tokens, API keys and certificates belonging to other requests. Every PHP release back to 5.4 is affected by at least one of the issues, and PHP runs roughly 70% of websites.

The vulnerable code is in PHP itself. A plain "Hello World" application on an unpatched runtime is exploitable, and the demonstrations against WordPress, Drupal and Joomla used their latest container images at the time of testing.

The part that should change how you plan is the timeline. These flaws sat in the codebase for over ten years. Turning them into a working exploit meant chaining several memory bugs and adapting to each target's memory layout, work that used to take a specialist team months. With frontier AI models in the loop, the researchers went from first finding to confirmed remote code execution in two days and adapted the exploit across applications in hours.

Exposure and exploitability move faster than patch cycles

Two things decide whether an externally exposed service gets you breached, and you control neither on the day it matters. The first is reachability, which drifts every time a service goes public or a vendor gets an inbound path. The second is exploitability, and PHP2Shell shows how fast that one can flip. Code that was safe in practice for ten years was exploitable in two days, and the adaptation work that used to protect you (different PHP versions, configurations, memory layouts) now costs an attacker an afternoon with a model and a debugger.

The disclosure also carries a quieter path. An attacker can read worker memory and walk away with credentials from other requests without ever executing code, so detection built around malicious execution may see nothing. Add the time it takes to patch every runtime and restart every PHP-FPM worker in a large estate, and you have a window measured in weeks where an exposed service is a given.

Planning around that window means treating the first hop as granted. The question that stays stable across every CVE is what happens after it.

Assume breach: the PHP worker is now the attacker

PHP2Shell gives the attacker code execution as the PHP web worker. In the cloud, that worker is a principal. On AWS it holds the EC2 instance role from the metadata service, or an ECS task role, or a Lambda execution role. On Azure it holds a managed identity, and on Google Cloud a service account. Whatever secrets the application loaded into memory, database passwords, API keys, tokens for other services, are sitting in the same process the attacker just entered.

So the assume-breach question for every exposed PHP service is concrete. Which principal does it run as, and what is that principal's effective access once every identity policy, resource policy, SCP, RCP, trust policy and condition is evaluated together? That number is almost always larger than anyone intended, because roles get copied, broadened for a migration and left in place.

Then the second question: of that effective access, what does the log source show the principal used over the last 90 days? The gap between configured access and observed access is the attacker's room to move, and it's the one variable in this story you own before and after any CVE. Blast radius is a property of your configuration, and configuration is something you can change this week.

Where Act fits

Act models your cloud as a graph: principals, resources, services and the access paths between them, across AWS, Azure and Google Cloud. For PHP2Shell the walk starts on the External boundary, at the services that are publicly reachable, and follows the access paths outward from the principal each one runs as.

Three states of access matter on that walk. Configured access is what the policies declare. Effective access is what nets out after every overlapping policy, guardrail and trust relationship is evaluated together, including the access enablers (roles the worker's principal can assume) that turn a modest instance role into a path across accounts. Observed access is what the log source shows the principal used. Act computes all three for every path, so the question "what can this compromised worker reach, and did it ever need to" has an answer per service instead of a spreadsheet exercise.

That answer becomes work in Act's hardening campaigns. Rightsizing operations remove the configured-not-observed access on the roles behind exposed services. Ring-fencing operations draw an Application Boundary around a crown-jewel application so a compromised web tier can't reach into it. Guardrail operations attach SCPs and RCPs so a worker in one account can't touch production data in another. Each operation breaks down into action items that move through change review, validation and enforcement, and the Policy Simulator shows the impacted paths before any policy is attached. Narrowing a role is the step teams skip because they fear breaking something. Seeing the exact paths a change would block takes that fear out.

The variable you own

The next PHP2Shell will arrive on the same terms: old code, new exploitability, a patch window you can't close overnight. Reachability and exploitability will keep moving, and AI will keep moving them faster. The blast radius behind each exposed service is the part of the equation that sits in your configuration, and it's the part Act lets you see and shrink before the next disclosure.

If you want to see the effective access behind your externally exposed services, talk to us.