PHP2Shell: the patch is easy – finding PHP in your containers is the real work
On 21 October the PHP project released fixes for two critical vulnerabilities in the PHP core, now widely referred to as PHP2Shell (CVE-2026-109618 and CVE-2026-109619). Both are rated 9.2 under CVSS v4 and can allow unauthenticated remote code execution with the privileges of the web worker. Google Cloud lists every PHP version from 5.4 up to 8.5.11 as affected.
Patching is the obvious answer. But in a containerised world, the harder question usually comes first: where, exactly, does PHP run in your estate?
What we know so far
- What is broken: one flaw involves memory corruption during out-of-memory handling; the other lets request-owned state survive into a later request on the same worker. Neither depends on a bug in your application code.
- What is affected: installations that serve web requests – PHP-FPM, Apache mod_php, php-cgi, FrankenPHP and LiteSpeed. Rapid7 notes that the vendor considers mod_php the highest risk.
- Fixed versions: 8.2.35, 8.3.36, 8.4.27 and 8.5.12. Branches that are end of life should be treated as needing an upgrade; check with your distribution or long-term support vendor for any backports.
- Exploitation: public proof-of-concept code exists. According to Rapid7, the PoCs it has examined only work for specific combinations of operating system, PHP version and web server, and it had seen exploitation attempts but not confirmed exploitation in the wild as of 22 October. It expects that to change, and recommends patching on an emergency basis, outside normal patch cycles.
Why containers make this question harder
On a classic server you patch the package and restart the service. In Kubernetes, a patched node changes nothing: the vulnerable runtime lives inside the container image, and it stays there until the image is rebuilt and the pods are redeployed. Google's guidance for GKE says exactly that – update the image, redeploy the pods.
That means the real work is in three places:
- Inventory. Which images in your registries and clusters contain a PHP runtime? Not only your own applications, but third-party images you run as they are: admin tools, CMS-based sites, legacy integrations, a "temporary" utility someone deployed two years ago.
- Rebuild. Is the base image pinned to an old tag? Does your pipeline actually pull a fresh base image, or does it reuse a cached layer? A rebuild that does not pick up the patched PHP version is just a redeploy.
- Rollout. Can you push a new image to every environment the same day, with confidence that nothing else changes?
Inventory first, then patch
The organisations that will close this quickly are the ones that can answer the inventory question from data rather than from memory. In practice that means:
- Image scanning and SBOMs in the registry, so "which images contain PHP < 8.x.y" is a query, not a project.
- Everything deployed through Git (GitOps), so the list of what runs where is the repository, and a rollout is a pull request.
- Infrastructure as code, so that a staging environment really looks like production and you can test the patched image before it goes out.
- Clear ownership of third-party images, so someone is responsible for knowing when an upstream vendor has shipped a fix.
A quick manual check such as running php -v inside a running pod can confirm a suspicion, but it does not scale and it misses images that are not running right now.
If you cannot patch today
The advisories describe temporary measures that reduce exposure without fixing the flaws – for example disabling session upload progress, enforcing memory limits administratively, and capping request size and multipart complexity at the edge (ingress, load balancer or WAF). Treat these as a bridge for days, not a substitute for patched images. Rapid7 is explicit that an update containing both fixes is the only complete remediation.
The broader lesson
Every few months a critical flaw lands in something that runs almost everywhere. The response time is rarely limited by the patch itself; it is limited by how well you know your own platform. A short, regularly tested routine – find it, rebuild it, roll it out – is worth more than any single emergency effort.
If you want a second pair of eyes on how your container platform would handle the next one, we are happy to talk.