23.10.2026

PHP2Shell Was a Rehearsal. Prepare Now for the Next One.

AI has pushed vulnerability discovery past the pace that patch queues were built for. PHP2Shell showed the result: the fix arrived within a day of the first public warning, and services still went dark because no one could say quickly where their PHP runtimes were running.

Why did so many services go offline for PHP2Shell?

Many services went offline because PHP2Shell sits in the PHP runtime itself, and only the runtime update fixes it. Some providers switched off on 21 October before the fix was released; others stayed dark for hours after the release because they could not confirm where PHP ran and rebuild it. The patch arrived quickly. The certainty did not.

PHP2Shell is a pair of memory-safety vulnerabilities in core PHP, tracked as CVE-2026-109618 and CVE-2026-109619 and both rated CVSS 9.2, that allow unauthenticated remote code execution before any application code runs. The PHP project released the fixed versions 8.5.12, 8.4.27, 8.3.36 and 8.2.35 on 21 October 2026, and CERT-EU Security Advisory 2026-018 advised organizations to patch immediately or isolate internet-facing applications.

The German Mittelstand felt it directly. The invoicing platform easybill switched off its application and website, and the time-tracking service Clockodo placed a notice page in front of its application. The hosters Mittwald and netcup took customer websites offline for hours; Mittwald shut down all systems at 16:17 CEST until sites returned at 22:52, according to a review of German hoster status pages.

The full scope of exploitation is still unknown; Amazon recorded a first attempt on 17 October, four days before disclosure, and attempts from multiple actors followed the release, as reported by The Hacker News. A critical flaw in a shared runtime turns every unknown deployment into a reason to shut down.

Key takeaways

PHP2Shell is a flaw in the PHP runtime, so secure application code and an up-to-date CMS do not protect a site that runs a vulnerable PHP version.
The fix shipped on 21 October 2026, yet many organizations took services offline because they could not locate and rebuild every PHP runtime fast enough.
CVE submissions grew 263% between 2020 and 2025, according to NIST, and AI-assisted research makes events like PHP2Shell more frequent.
WAF rules and runtime controls reduce exposure during the patch window, but CERT-EU and AWS both state that only the PHP update closes the vulnerability.
Preparation made now decides the next critical runtime CVE: inventory, exposure context and rebuildable images determine whether a business stays online.

Why are vulnerability disclosures accelerating?

Vulnerability disclosures are accelerating because AI has lowered the cost of finding and weaponizing flaws. Flaws that were too complex to exploit by hand are now within reach for defenders and attackers alike. The weakness behind PHP2Shell had been in the codebase for more than a decade.

NIST reported that CVE submissions increased 263% between 2020 and 2025, with the first quarter of 2026 nearly one-third above the previous year. Cloud Security Pros estimates that monthly CVE volume rose about 178% between June 2023 and June 2026, an estimate derived from annual totals.

Wiz Research, working with Calif and OpenAI, used frontier models to turn the PHP flaws into a working exploit and concluded that "a single researcher completed in a week what previously would have taken a world-class team months of work." AI-generated code adds volume on the other side of the ledger, as the analysis of why the developer workstation is now part of the cloud security perimeter shows.

Part of the growth is a reporting effect: new CVE Numbering Authorities such as the Linux kernel expanded what gets counted. The question is not whether the curve is inflated. The better question is how many critical runtime CVEs a year an organization can absorb without going offline.

Why is a released patch not the same as being patched?

A released patch is not the same as being patched because PHP rarely runs in one place. It sits in operating system packages, container base images, hosted platforms, appliances and long-running workers, each with its own update path. Updating WordPress on top changes nothing underneath.

Fixed binaries only take effect after Apache, PHP-FPM and long-running workers restart. Container images must be rebuilt with a patched PHP and redeployed. VulnCheck found PHP on 2,608,039 internet-facing hosts, more than 700,000 of them on PHP 3.x through 7.3, as reported by The Hacker News, and PHP 8.1 and older receive no official release.

Patching is an event; being patched is a property of the whole estate. An organization that knows where every runtime runs and how it is built can turn one into the other within hours. Without that knowledge, two options remain: wait, or switch off.

Can a WAF or runtime sensor protect against PHP2Shell?

A WAF or runtime sensor can reduce exposure during the patch window, but it cannot remove the vulnerability. According to AWS, one of the two vulnerabilities is largely outside the reach of any web application firewall. Edge and runtime controls buy time; only the update closes the vulnerability.

AWS describes a rule that blocks POST requests carrying PHP_SESSION_UPLOAD_PROGRESS with a PHP session identifier, plus optional rules for multipart/form-data, body size and POST rate limits. AWS is explicit about the limit: AWS WAF is "a defense-in-depth control in this situation, not a replacement for the PHP upgrade."

Runtime protection adds a second layer. According to Wiz Research, customers running Wiz Sensor version 1.0.12768 or later can enable a built-in response policy that automatically terminates processes exhibiting behavior typical of PHP2Shell exploitation. That stops an attack in progress without making the runtime safe, so it belongs with the WAF rules: valuable while the rebuild is underway.

Patch queue versus rebuild pipeline

What separated organizations that stayed online from those that went dark was rarely effort on 21 October. The difference was the work done before the advisory arrived.

Five questions decide how a critical runtime CVE plays out, and the two operating models answer them very differently:

Where does the runtime run?
Patch queue: collected by email from teams and hosters.
Rebuild pipeline: answered from a continuous inventory of hosts, images and workloads.
Which instances matter first?
Patch queue: sorted by CVSS score.
Rebuild pipeline: sorted by internet exposure, reachable secrets and validated exploitability.
How does the fix reach production?
Patch queue: a ticket per server and a maintenance window.
Rebuild pipeline: a new base image digest, rebuilt and redeployed through the pipeline.
What happens to old versions?
Patch queue: exceptions accumulate quietly.
Rebuild pipeline: end-of-life runtimes are visible and scheduled for migration.
What is the fallback?
Patch queue: take the whole service offline.
Rebuild pipeline: isolate only the exposed services that cannot be rebuilt in time.

How should teams prepare for the next PHP2Shell?

Preparation for the next critical runtime CVE is a set of capabilities built before the advisory arrives. Every hour spent finding runtimes during an incident is an hour that could have been spent before it.

Build a continuous runtime inventory. Record every place PHP and other interpreted runtimes run, from virtual machines and container images to hosted platforms. Agentless scanning of workloads and registries turns the exposure question from a day of email into a query.
Connect each runtime to its exposure. Combining vulnerability, internet exposure, identity permissions and data access into toxic combinations shows which services matter first, the approach behind modern cloud and AI security solutions. It orders the work while patching of the rest continues.
Validate exploitability from the outside. AI-driven testing of web applications and APIs confirms which exposed endpoints an attacker can actually use. It covers the application layer rather than every runtime flaw, so it complements the inventory.
Move internet-facing services to minimal, rebuildable base images. When a supplier rebuilds a base image continuously, the emergency patch becomes a new digest. The deployment step remains: these images shorten the path, they do not remove it.
Automate the path from new digest to production. Pin images by digest and let automation propose updates as soon as a patched digest appears; Chainguard's PHP2Shell advisory warns that pinned package versions in custom images block the fix. Test the rebuild in a calm week.
Prepare isolation per service, not per company. Decide in advance which services may be isolated, who decides, and which notice customers see. Targeted isolation keeps invoicing online while one exposed service waits for its rebuild.
Apply the same model to language dependencies. What enters production should come from a curated, rebuilt source rather than straight from a public registry, as the analysis of why the next malicious package may be properly signed explains. Such sources only help for the ecosystems they cover.

How can security controls avoid breaking production?

Security controls avoid breaking production when they are tested in calm weeks and scoped per service. Blocking multipart/form-data breaks every upload form, and pm.max_requests=1 recycles a PHP worker after every request, which AWS suggests only where performance allows. AWS also advises starting every WAF rule in count mode before switching to block.

If the secure path is slower than the unsafe one, teams will restore the unsafe one. A rebuild pipeline that needs a week of approvals invites exceptions that outlive the incident. Measure the time the controls add, and treat growth in that number as a defect.

What should leadership measure before the next critical CVE?

Leadership should measure outcomes that predict how the next critical CVE will play out. Five metrics cover the ground:

Time to exposure list: hours from advisory to a complete list of affected internet-facing workloads.
Rebuildable share: percentage of internet-facing services built from a maintained base image through a pipeline.
End-of-life share: percentage of runtimes on versions without official fixes.
Time to patched production: median hours from a fixed upstream release to production for critical services.
Isolation readiness: share of critical services with a tested isolation and customer-notice procedure.

For a board, the question is whether the company can name its exposed customer-facing services within hours of the next advisory and fix them without switching them off. Downtime avoided is the outcome; patch count is only activity.

What to check this week

These six checks need no new tooling:

List every container image that contains PHP and record the PHP version and package build.
Assign an owner and a migration date to every runtime on PHP 8.1 or older; PHP 8.2 reaches end of life on 31 December 2026.
Check whether internet-facing services pin base images by digest and receive automated digest updates.
Confirm session.upload_progress.enabled=0 in php.ini or the FPM pool where upload progress tracking is not needed. This blocks one demonstrated path of CVE-2026-109619.
Ask hosters and SaaS providers which PHP build they run and whether all workers were restarted.
Rebuild one internet-facing service from a new base image to production and time it

The rebuild drill is the most revealing check: its duration is a realistic estimate of how long the next emergency will take. Working through the results is the kind of task covered by professional services for cloud security.

Frequently asked questions about PHP2Shell

Is a website affected by PHP2Shell if WordPress is up to date? Y
Yes, if it runs a vulnerable PHP version. PHP2Shell is a flaw in the PHP runtime, not in WordPress, Joomla, Drupal or a plugin. A fully updated CMS on a vulnerable PHP version remains exposed. The fix is PHP 8.5.12, 8.4.27, 8.3.36 or 8.2.35, or a distribution package that contains the fix, followed by a restart of every PHP worker.

Does a WAF fix PHP2Shell?
No. A WAF rule can block the confirmed upload-progress trigger, multipart requests and oversized bodies, which reduces exposure during the patch window. One of the two vulnerabilities lies largely outside the reach of a firewall, so the PHP update remains the only complete remediation.

What about PHP 8.1 and older?
The PHP project releases no official fix for PHP 8.1 or earlier. Because of the severity, its security team published minimal source backports for 7.4, 8.0 and 8.1, and some distributions and LTS providers ship backported packages. Systems without such a package should be isolated and migrated to a supported branch.

Why did SaaS providers take their services offline?
Providers such as easybill switched off as a precaution because a single unauthenticated request could reach the vulnerable code before any application logic ran. Until every runtime was confirmed patched and restarted, going offline was the only way to rule out exploitation, at the cost of hours of downtime for their customers.

Is the CVE surge just a reporting artifact?
Partly. New CVE Numbering Authorities expanded what gets counted. NIST nevertheless reports 263% growth in submissions between 2020 and 2025, and AI-assisted research is turning previously impractical flaws, like the decade-old weakness behind PHP2Shell, into working exploits. The workload for defenders is real.

Do hardened container images remove the need to patch?
No. Hardened, minimal images reduce the components that can be vulnerable and shorten the time to a fixed image, because the supplier rebuilds it once a fix exists. Teams still pull the new digest, rebuild their own layers and redeploy. Hardened images change the speed of patching, not the need for it.

Know your exposure before the next advisory

Alan&Eve helps platform and security teams build the capability described above in a two-week Foundation Sprint. The scope is every internet-facing workload in AWS, Azure or Google Cloud that runs PHP or another interpreted runtime, together with the container registries behind it. We use Wiz to inventory those runtimes and rank them by exposure, reachable secrets and data access, and the Wiz Red Agent, to validate which exposed web applications and APIs are exploitable from the outside.

The deliverables are a ranked runtime inventory, a shortlist of toxic combinations with an owner for each, a migration plan that moves the five most exposed services onto Chainguard Containers with automated digest updates, and a one-page isolation runbook. Week one starts with a working session with your platform and security leads to agree on scope and ownership. The sprint does not cover changes to application code or the infrastructure of third-party SaaS providers.

Map your runtime exposure