Two security events landed side by side this week, PHP2Shell and the eMudhra certificate compromise. Both reached the same place, the foundation their applications are built on.
PHP2Shell is a pair of critical flaws in the PHP engine itself, CVE-2026-109618 and CVE-2026-109619. They let an unauthenticated request become code execution on the server, on any PHP application, however careful its own code is, and PHP runs about 69% of the websites whose server-side language is known.
The eMudhra compromise is a different kind of problem. Eight intermediate certificates from the certificate authority eMudhra turned out to have private keys that can be computed from the public certificates, which let anyone issue a certificate for any website and have it accepted. Browsers revoke certificates like these on their own, but a container image carries its own trust store and keeps trusting them until it is rebuilt.
Docker Hardened Images published a fixed PHP image within 24 hours
The dhi.io/php image was rebuilt on the patched PHP and published early on October 22, within 24 hours of the upstream release and after the DHI testing and verification steps. Pulling the current tag puts you on the fixed version. The few DHI images that bundle their own PHP application, such as composer and nextcloud, follow as their upstream projects release.
Rebuilt across the catalog, verifiable tag by tag
The certificate compromise touched the whole catalog, because every image carries a trust store. In the 48 hours after the PHP release, the DHI build system ran 16,567 package and image builds across the catalog. By 10pm UTC on October 22, almost all catalog tags were on the fixed CA store, with most of the rest in the build queue. That percentage comes from the SBOM that ships with every image, read for every published tag to check which CA store and which PHP version it carries, and you can run the same check on anything you pull.
How to make sure your environments are covered
If you run PHP on Docker Hardened Images, pull the current tag for your branch and redeploy, and rebuild anything you built on top of a DHI image so it picks up the new base docker pull dhi.io/php:8.4
Customizations built through the DHI Enterprise workflow are rebuilt automatically when the base layer is patched. For the certificate fix the same applies to every image you build from a DHI base, PHP or not. The Docker Security update from October 22 lists the affected PHP versions and the support path.
If you run PHP in any other container, check the PHP version running inside it rather than the tag on the outside, and rebuild it on a patched base.
Build from a trusted foundation
Weeks like this one will keep coming, but a trusted foundation will make all the difference.
If you are not building on hardened images yet, this week is the wake-up call and the week to start. Both events landed on the foundation, and that is where the fix has to happen, in the image itself, rebuilt from fixed sources before anyone pulls it.
This is exactly what Docker Hardened Images were built for. Docker builds, patches and maintains the system packages inside each image from source, and the build system is event-driven, so an upstream release or a changed package triggers rebuilds of everything that depends on it. Each image ships signed, with its SBOM, SLSA Build Level 3 provenance and VEX data attached, which is why a rebuild of this size can be measured as well as done.
The catalog is free and open source under Apache 2.0, with near-zero CVEs on every image. It stays compatible with the Alpine and Debian your teams already run, so adoption is a one-line change to the FROM line in your Dockerfile, with no migration project attached. DHI Select and DHI Enterprise add SLA-backed remediation with critical CVE fixes within 7 days, FIPS and STIG variants, image customization with the guarantees kept, and Extended Lifecycle Support for the versions upstream has stopped patching. All of it is in the Docker Hardened Images catalog, free to pull today.
