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

PHP 專案於 2026 年 10 月 21 日發布修補程式，修復兩個嚴重的遠端程式碼執行漏洞。但漏洞詳情早一天已外洩，而據報 Amazon 的蜜罐在此之前幾天已發現漏洞利用嘗試。

所以問題不是「有沒有修補程式」，而是「目前正在處理流量的容器內，有沒有安裝修補程式」。

重點摘要（供非技術讀者參考）

PHP 是許多網站所使用的程式語言，其中兩個嚴重漏洞可讓陌生人只需傳送一個特製請求，便能控制網頁伺服器。

修補程式已經推出。但修補軟件和修補正在運作的網站是兩個不同步驟，第二步很容易被忽略。

如果你的公司有運行任何以 PHP 建構的系統，等待的代價可能是遭入侵，而不只是一個漏洞。

只需問技術團隊一個問題：「目前正式環境正在運行哪個 PHP 版本？你們如何確認？」

事件經過

這兩個漏洞的編號是 CVE-2026-109618 和 CVE-2026-109619，綽號為 PHP2Shell。根據 php.net 的安全公告和 Docker 的分析文章，兩者在 CVSS v4.0 中均獲評 9.2 分。

CVE-2026-109618：記憶體不足處理機制可能在請求資料尚未完全初始化時中斷 PHP，而清理程序隨後會信任無效資料。
CVE-2026-109619：請求狀態在其記憶體釋放後仍然保留，同一個工作程序處理後續請求時可能會使用這些狀態。

兩個漏洞都存在於 PHP 執行環境。PHP-FPM、Apache mod_php、php-cgi、FrankenPHP 和 LiteSpeed 均受影響。問題不在 Composer 依賴項，因此 composer update 不會有幫助。據 Help Net Security 報道，英國 NCSC 更呼籲機構將有漏洞的系統下線。

分支	修補版本
8.2	8.2.35
8.3	8.3.36
8.4	8.4.27
8.5	8.5.12

PHP 8.1 及更舊版本不會有官方修補版本。雖然 7.4、8.0 和 8.1 有回移植的原始碼修補程式，但對大部分團隊而言，實際的解決方法是升級分支版本。

根據 Huntress 和 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

業界人士的看法

Hacker News 討論串很好地反映了各方情緒。

披露流程。一位獲大量讚好的留言者表示，多家供應商和 AI 模型聲稱自己先發現漏洞，令事件時間線難以令人信服；其他人則對保密期遭破壞感到不滿。
程式語言。一個常見看法是，這又是 C 程式碼中的記憶體安全漏洞，而單靠編程紀律，數十年來都未能解決這類問題。
視之為無可挽回。一位留言者認為，任何堆積記憶體損毀都應假定會導致程式碼執行，因此爭論漏洞利用細節只會偏離重點。
質疑 AI 的人。另一位留言者質疑「由 AI 發現」的説法，指出相關程式碼已有約 20 年歷史，而且從未披露運算成本。
不要相信臨時解決方法。lilting.ch 的作者指出，停用 session.upload_progress 曾是早期提出的建議，但 PHP 核心開發人員表示，修補才是唯一真正有效的緩解方法，而提出該建議的研究人員其後也放寬了立場。

我的看法

我認同大家對臨時解決方法和記憶體安全問題的看法，但不同意把這件事看成披露風波。

對團隊而言，關鍵在於「已發佈」與「正在執行」之間的落差。漏洞資訊外洩，加上公開掃描器，意味着這兩個狀態之間的時間差如今以小時計，而非星期計。這令人不安，但也是這件事中最令人鼓舞的一點：修補程式在一天內已可取得，而官方 Docker 映像檔約兩小時內便完成重新建置。工具確實發揮了作用。最終結果取決於你的部署流水線能否迅速採用修補程式。

我的看法是：能夠在同一天重新建置並重新部署基礎映像檔的團隊，狀況良好；做不到的團隊，應把這視為比任何單一 CVE 更重要的真正發現。我也想稍微反駁一下 AI 懷疑論者。無論宣傳有否誇大，這項實際教訓依然成立：舊而乏味的程式碼路徑如今正以防守方應有所準備的速度接受審核。

15 分鐘試做

選一項 PHP 服務。先不要修復任何問題，只作量度。

1. 列出所有執行 PHP 的地方

Cron 容器、佇列工作程序、CI 執行器，還有那個無人負責的內部管理工具。

docker ps --format '{{.Image}}' | sort -u
kubectl get pods -A -o jsonpath='{range .items[*]}{.spec.containers[*].image}{"\n"}{end}' | tr ' ' '\n' | sort -u

2. 查證正在執行的程序，而非查看 Dockerfile

docker compose exec <service> php -v

8.4.26 存在漏洞；8.4.27 則沒有。一點要注意：如果 PHP 來自發行版套件，而非官方映像檔，供應商可能會回移修補程式，而不更改上游版本號碼。在這種情況下，請查閲供應商的安全公告，而不只是 php -v。

3. 不使用快取重新建置

docker compose build --pull --no-cache
docker compose up -d

--pull 會取得重新建置的基礎映像檔。--no-cache 可防止 Docker 重用存有舊二進制檔的層。

4. 掃描指定的 CVE

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

對你要部署的映像檔執行掃描。即使你的掃描器尚未識別這些編號，第 2 步仍然有效。

5. 以摘要值鎖定

docker pull php:8.4-fpm
docker inspect --format='{{index .RepoDigests 0}}' php:8.4-fpm

將 php@sha256:... 的值寫入 Dockerfile，並讓 Renovate 或 Dependabot 在值有變更時建立 PR。

記下三個數字

你認為正在執行的 PHP 版本、php -v 回報的版本，以及查明所需的分鐘數。如果前兩個數字不一致，或第三個數字偏高，這才是你真正的結果。

接下來可以瞭解

CVE-2026-109618 的 PHP 官方安全公告，包括尚未能安裝修補程式的團隊可採取的部分緩解措施。
Docker Scout 説明文件，瞭解如何在 CI 執行第 4 步。
Renovate 的 Docker 文件，瞭解如何自動執行第 5 步。

問題

當重大修補程式在週中推出時，你們團隊從「已發佈」到「所有地方都已執行」之間最慢的步驟是甚麼：審批、建置、推出，還是不知道它在哪裏執行？