# PHP2Shell: The Patch Is Out. Is It Running in Your Containers? > PHP2Shell patches for CVE-2026-109618 and CVE-2026-109619 are out. Five checks to prove the fix is running in your containers, not just released. - URL: https://www.kielltampubolon.id/writing/php2shell-the-patch-is-out-is-it-running-in-your-containers/ - Author: Kiell Tampubolon - Published: 2026-10-24 - Last updated: 2026-10-24 - Language: en - Tags: Security Engineering, Deployment ## Key takeaways - CVE-2026-109618 and CVE-2026-109619, nicknamed PHP2Shell, both score 9.2 on CVSS v4.0 and affect the PHP runtime including PHP-FPM, Apache mod_php, php-cgi, FrankenPHP and LiteSpeed. - Fixed releases are 8.2.35, 8.3.36, 8.4.27 and 8.5.12, while PHP 8.1 and older get no official release and usually need a branch upgrade. - Composer dependencies are not the problem, so composer update will not help. - Ask the running process with php -v, since 8.4.26 is vulnerable and 8.4.27 is not, and rebuild with docker compose build --pull --no-cache. - Scan with docker scout cves for both CVE IDs and pin base images by digest so Renovate or Dependabot opens a PR when it changes. The PHP project shipped fixes for two critical remote code execution bugs on October 21, 2026. But the details had leaked a day earlier, and Amazon's honeypots reportedly saw exploit attempts days before that. So the question is not "is there a patch". It is "is the patch inside the container that is serving traffic right now". ## TL;DR (for non-technical readers) > - Two serious flaws in PHP, the language behind a large share of websites, let a stranger take over a web server with a single crafted request. > - The fix exists. But fixing the software and fixing your running website are two separate steps, and the second one is easy to forget. > - If your company runs anything built on PHP, the cost of waiting is a possible breach, not just a bug. > - Ask your tech team one thing: "Which PHP version is running in production right now, and how do you know?" ## What happened The two bugs are CVE-2026-109618 and CVE-2026-109619, nicknamed PHP2Shell. Both score 9.2 on CVSS v4.0, according to the [php.net advisory](https://github.com/php/php-src/security/advisories/GHSA-w8hw-w9fx-j79w) and the [Docker write-up](https://dev.to/docker/how-to-fix-php2shell-cve-2026-109618-and-cve-2026-109619-3df3). ![Timeline of PHP2Shell: Oct 17 honeypot exploit attempt, Oct 20 details leak, Oct 21 fixed releases and Docker images rebuilt about two hours later, Oct 22 public scanners and advisories.](https://www.kielltampubolon.id/writing/php2shell-the-patch-is-out-is-it-running-in-your-containers/img-1.png) ![Cards showing the fixed PHP release per branch: 8.2.35, 8.3.36, 8.4.27, 8.5.12, with a warning that PHP 8.1 and older get no official release.](https://www.kielltampubolon.id/writing/php2shell-the-patch-is-out-is-it-running-in-your-containers/img-2.png) - CVE-2026-109618: out-of-memory handling can interrupt PHP while request data is half-initialized, and cleanup then trusts invalid data. - CVE-2026-109619: request state survives after its memory is freed, and a later request on the same worker can use it. Both live in the PHP runtime. PHP-FPM, Apache mod_php, php-cgi, FrankenPHP and LiteSpeed are all affected. Composer dependencies are not the problem, so `composer update` will not help. Per Help Net Security, the UK NCSC went as far as urging organizations to take vulnerable systems offline. | Branch | Fixed in | |---|---| | 8.2 | 8.2.35 | | 8.3 | 8.3.36 | | 8.4 | 8.4.27 | | 8.5 | 8.5.12 | PHP 8.1 and older get no official release. Source backports exist for 7.4, 8.0 and 8.1, but for most teams the real answer there is a branch upgrade. The timeline, as reported by [Huntress](https://huntress.com/blog/php2shell-leaked-critical-php-vulnerabilities) and [Help Net Security](https://helpnetsecurity.com/2026/10/21/php2shell-php-vulnerabilities-patched-cve-2026-109618-cve-2026-109619): ```plaintext Oct 17 Amazon honeypot sees an exploit attempt Oct 20 Details leak before the planned disclosure Oct 21 Fixed releases (about 13:48 UTC); Docker images rebuilt ~2h later Oct 22 Public scanners and vendor advisories appear ``` ## What practitioners are saying The [Hacker News thread](https://news.ycombinator.com/item?id=50180836) is a good map of the mood. - **Disclosure process.** One highly upvoted commenter said the overlapping discovery claims by several vendors and AI models made the timeline hard to trust, and others were annoyed that the embargo broke at all. - **The language.** A recurring view is that this is another memory-safety bug in C code, and that discipline alone has not fixed that class of problem in decades. - **Treat it as game over.** One commenter argued that any heap corruption should be assumed to be code execution, so arguing over exploit details misses the point. - **The AI skeptic.** Another doubted the "AI found it" story, pointing out the underlying code is about 20 years old and the compute cost was never disclosed. - **Do not trust the workaround.** Writers at [lilting.ch](https://lilting.ch/en/articles/php2shell-official-patch) note that disabling `session.upload_progress` was an early suggestion, but a PHP core developer said patching is the only real mitigation, and the researchers who proposed it later softened their view. ## My take I agree with the crowd on the workaround and the memory-safety point. I disagree that this is a story about disclosure drama. The part that matters for teams is the gap between "released" and "running". A leak plus public scanners means the window between those two states is now measured in hours, not weeks. That is uncomfortable, but it is also the most positive thing in this story: the fix was available within a day, and official Docker images were rebuilt within about two hours. The tooling worked. What decides your outcome is whether your pipeline can pick it up quickly. My stance: teams that can rebuild and redeploy a base image the same day are in good shape, and teams that cannot should treat that as the real finding, more than any one CVE. I would also push back on the AI skeptics a little. Whether or not the marketing is inflated, the practical lesson holds: old, boring code paths are now getting audited at a pace defenders should plan for. ## Try it in 15 minutes Pick one PHP service. Do not fix anything yet. Just measure. ![Five numbered checks from released to running: list where PHP runs, ask the running process, rebuild without cache, scan for the CVEs, pin by digest.](https://www.kielltampubolon.id/writing/php2shell-the-patch-is-out-is-it-running-in-your-containers/img-3.png) ### 1. List every place PHP runs Cron containers, queue workers, CI runners, that internal admin tool nobody owns. ```bash docker ps --format '{{.Image}}' | sort -u kubectl get pods -A -o jsonpath='{range .items[*]}{.spec.containers[*].image}{"\n"}{end}' | tr ' ' '\n' | sort -u ``` ### 2. Ask the running process, not the Dockerfile ```bash docker compose exec php -v ``` 8.4.26 is vulnerable. 8.4.27 is not. One caveat: if PHP comes from a distro package rather than the official image, the vendor may backport the fix without changing the upstream version number. In that case check the vendor advisory, not just `php -v`. ### 3. Rebuild without the cache ```bash docker compose build --pull --no-cache docker compose up -d ``` `--pull` fetches the rebuilt base image. `--no-cache` stops Docker from reusing the layer holding the old binary. ### 4. Scan for the specific CVEs ```bash docker scout cves --only-cve-id CVE-2026-109618,CVE-2026-109619 ``` Run it against the image you deploy. If your scanner does not know the IDs yet, step 2 still works. ### 5. Pin by digest ```bash docker pull php:8.4-fpm docker inspect --format='{{index .RepoDigests 0}}' php:8.4-fpm ``` Put the `php@sha256:...` value in your Dockerfile and let Renovate or Dependabot open the PR when it changes. ### Write down three numbers The PHP version you believe runs, the version `php -v` reports, and the minutes it took to find out. If the first two disagree, or the third is long, that is your real result. ## What to learn next - The [official PHP advisory for CVE-2026-109618](https://github.com/php/php-src/security/advisories/GHSA-w8hw-w9fx-j79w), including the partial mitigations for teams that cannot patch yet. - [Docker Scout documentation](https://docs.docker.com/scout/), to run step 4 in CI. - [Renovate's Docker docs](https://docs.renovatebot.com/docker/), to automate step 5. ## Question When a critical fix lands midweek, what is the slowest step between "released" and "running everywhere" on your team: approval, build, rollout, or knowing where it runs? *Originally published on [DEV](https://dev.to/kielltampubolon/php2shell-the-patch-is-out-is-it-running-in-your-containers-341j). Discussion happens there.* ## FAQ ### How do I check if my container is patched for PHP2Shell? Run php -v inside the running container, for example with docker compose exec. On the 8.4 branch, 8.4.26 is vulnerable and 8.4.27 is fixed, though a distro package may backport the fix without changing the version number. ### Does composer update fix CVE-2026-109618 and CVE-2026-109619? No. Both bugs live in the PHP runtime, not in Composer dependencies, so the fix is a patched PHP release or rebuilt base image. ### Which PHP versions fix PHP2Shell? The fixed releases are 8.2.35, 8.3.36, 8.4.27 and 8.5.12. PHP 8.1 and older get no official release, so for most teams the answer is a branch upgrade.