PHP2Shell 修補程式已推出，如何確認容器正在執行已修補版本？

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 and the Docker write-up.

• 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.

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 and Help Net Security:

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 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 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.

1. List every place PHP runs

Cron containers, queue workers, CI runners, that internal admin tool nobody owns.

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

docker compose exec <service> 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

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

docker scout cves --only-cve-id CVE-2026-109618,CVE-2026-109619 <image>

Run it against the image you deploy. If your scanner does not know the IDs yet, step 2 still works.

5. Pin by digest

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, including the partial mitigations for teams that cannot patch yet.
• Docker Scout documentation, to run step 4 in CI.
• Renovate's Docker docs, 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?