---
title: "PHP CVE-2026-109618/109619：Serverless 也要修嗎？"
description: "PHP CVE-2026-109618/109619 會影響已改成 serverless 的 Lambda 嗎？本文記錄如何查出 image 仍跑 PHP 8.3.14、確認 Alpine 尚無修補版、快速更換 PHP image，並從 API 回應驗證更新生效。"
url: https://jasperhung.dev/posts/php-cve-2026-109618-109619-lambda/
date: 2026-10-22T13:31:31.000Z
tags: ["PHP","Security","Docker","AWS-Lambda","CVE","Serverless"]
---

# PHP CVE-2026-109618/109619：Serverless 也要修嗎？

> PHP CVE-2026-109618/109619 會不會影響 serverless Lambda？會，因為 PHP 仍會在 Laravel 收到請求前解析 multipart；確認實際版本與修補 image 後，還要等 Lambda 更新完成，再從 API 回應確認。

這兩天資安風暴，手上剛好有個已重構成 serverless 的 PHP 服務。PHP 的 CVE-2026-109618 與 CVE-2026-109619 通報出來後，我把這個服務也列入檢查。

這波警訊也到了官方層級：[國家資通安全研究院發布漏洞通報](https://www.nics.nat.gov.tw/core_business/information_security_information_sharing/Vulnerability_Alert_Announcements/5c4e9af1-4275-44ef-a277-c692786b5a2c/)，[日本首相高市早苗也透過自己的 X 帳號發文](https://x.com/takaichi_sanae/status/2112890642590564386)，呼籲確認公開網站是否使用 PHP，並預備套用修補版；[ITmedia 報導](https://www.itmedia.co.jp/news/article/2610/22/2000002483/)也確認了這則貼文。我想確認：改成 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](https://www.php.net/ChangeLog-8.php)）。我先把受影響版本與修補目標列在一起：

外部分析對漏洞本質的描述不一：[Sansec](https://sansec.io/research/php2shell) 稱為 upload-progress unserializer 的 Use After Free；[Red Hat](https://access.redhat.com/security/cve/cve-2026-109618) 著重 request parsing 時的 memory limit 處理；[Check Point](https://blog.checkpoint.com/security/php2shell-what-we-know-about-the-leaked-critical-php-vulnerabilities-cve-2026-109618-cve-2026-109619/) 則對 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](https://github.com/docker-library/php)（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` 控制上傳進度追蹤（[核心設定](https://www.php.net/manual/en/ini.core.php)、[Session 上傳進度設定](https://www.php.net/manual/en/session.configuration.php)）。第二項是補強，不能取代入口拒絕 multipart 或升級到修補版本。

## 修補 image 怎麼更新到 Lambda？

PHP 版本凍在 base image 裡；只重 build app image，不會升級 PHP。修補時先用官方 image 重做 base，再重建 app image：

```dockerfile
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，我們也快速打包更新。這場資安風暴應該可以化險為夷、安然度過吧。