這兩天資安風暴，手上剛好有個已重構成 serverless 的 PHP 服務。PHP 的 CVE-2026-109618 與 CVE-2026-109619 通報出來後，我把這個服務也列入檢查。
這波警訊也到了官方層級：國家資通安全研究院發布漏洞通報，日本首相高市早苗也透過自己的 X 帳號發文，呼籲確認公開網站是否使用 PHP，並預備套用修補版；ITmedia 報導也確認了這則貼文。我想確認：改成 Lambda 後，漏洞還會不會打得到？評估結果是會，服務仍得更新。
只收 JSON，為什麼還會受 multipart 漏洞影響？
Dockerfile 只寫著安裝 php83，看不出 patch 版本；檢查 base image 和 app image 後，CLI 與 PHP-FPM 都是 8.3.14。API 只收 JSON，程式也沒有上傳功能，但 PHP 會在 Laravel 處理路由前解析 multipart/form-data。Serverless 仍會經過這層。
Alpine 還沒有 patch，怎麼辦？
PHP 在 2026 年 10 月 21 日發布 security 版（PHP ChangeLog）。我先把受影響版本與修補目標列在一起：
外部分析對漏洞本質的描述不一：Sansec 稱為 upload-progress unserializer 的 Use After Free；Red Hat 著重 request parsing 時的 memory limit 處理；Check Point 則對 UAF 分類保留信心。因此本文聚焦在確認過的版本與修補路徑，不把單一機制寫成定論。
| PHP 分支／環境 | 當下版本或受影響範圍 | 預計升級至 |
|---|---|---|
| PHP 8.5 | ≤ 8.5.11 | 8.5.12 |
| PHP 8.4 | ≤ 8.4.26 | 8.4.27 |
| PHP 8.3 | ≤ 8.3.35 | 8.3.36 |
| PHP 8.2 | ≤ 8.2.34 | 8.2.35 |
| 這個服務 | 8.3.14 | 8.3.36 |
接著查 apk policy php83，穩定版套件庫都還沒有 8.3.36：
| 修補路徑 | 當時可用版本 | 評估 |
|---|---|---|
| Alpine stable | 3.19：8.3.14；3.21：8.3.19；3.22：8.3.29；3.23：8.3.31 | 等 3.23 backport，時間不確定 |
| Docker 官方 PHP image（4k ⭐） | Docker Hub 已有 php:8.3.36-fpm-alpine3.23 | 改 base、重整 Dockerfile，當天可修 |
| Alpine edge | 8.3.36 | 不建議用於正式環境 |
因此最後選官方 PHP image 當底，不等 backport，也不把 edge 放進正式環境。
預計怎麼改？
我搜過後端程式碼裡的 hasFile、->file(、UploadedFile、$_FILES 和 upload_progress，都沒有找到。這個服務只收 JSON，沒有上傳功能，所以入口拒絕 multipart、關閉未使用的 upload 設定，都不會影響既有功能。
| # | 做什麼 | 改哪裡 | 性質 |
|---|---|---|---|
| 1 | 入口直接擋掉 multipart/form-data | API Gateway／WAF（可獨立套用規則時），或 nginx 回 415；這次用 nginx | 今天止血，請求進不到 PHP |
| 2 | 關掉 upload 相關設定 | PHP-FPM 的 php.ini：file_uploads = Off、session.upload_progress.enabled = Off | 補強，停用服務不使用的上傳與進度追蹤功能 |
| 3 | 升到 PHP 8.3.36 | base 改用 php:8.3.36-fpm-alpine3.23 → 重建 v4 → app image → 更新 Lambda | 根本解 |
PHP 文件說明，file_uploads 控制 HTTP 檔案上傳，session.upload_progress.enabled 控制上傳進度追蹤（核心設定、Session 上傳進度設定）。第二項是補強，不能取代入口拒絕 multipart 或升級到修補版本。
修補 image 怎麼更新到 Lambda？
PHP 版本凍在 base image 裡；只重 build app image，不會升級 PHP。修補時先用官方 image 重做 base，再重建 app image：
FROM php:8.3.36-fpm-alpine3.23這次由 nginx 擋 multipart、回覆 415 止血；根本修補則是推送新版 base 與 app image，再手動執行 update-function-code。Lambda 不會因為 image tag 更新就自動換版。prod 也需要把兩個 image 都打包推上去，所以最後走 CI 重新 build，而不是只把 dev digest 改貼成 prod tag。
API request 怎麼確認更新生效？
Lambda 更新是非同步的。第一次 API request 發生時狀態仍是 InProgress，而且比 LastModified 早了 4 秒；回應仍是舊版 nginx，multipart 回 422。等狀態變成 Successful 再送 request，x-amzn-remapped-server 顯示 nginx 從 1.24.0 升到 1.28.3，multipart 也改回 415。
最後從 dev 和 prod 的 API 路徑重跑 smoke test：兩邊的 multipart 都回 415，prod 的 ready 回 200。expose_php 關閉時 API 不會直接回報 PHP 版本，因此我把 Lambda 更新狀態、response header 和 multipart 結果一起核對。
最後，PHP 官方快速發了 Patch，我們也快速打包更新。這場資安風暴應該可以化險為夷、安然度過吧。
