---
title: "PHP2Shell企業伺服器資安應變方法"
locale: zh-hant
category: how_to
category_name: "操作教學"
translation_status: reviewed
license: cc_by
author: "injoys"
source_url: https://injoys.com/en/articles/php2shell-enterprise-security-patch-response-guide
published_at: 2026-10-24T16:09:48+09:00
---

# PHP2Shell企業伺服器資安應變方法

> 因應PHP2Shell，應先更新實際網站服務使用的PHP並重新啟動。若疑似遭到入侵，應先保全證據，即使套用修補程式後，仍須檢查日誌並更換驗證資訊。

## Key Points

- 確認運作中的伺服器與嵌入式產品使用PHP的情況。
- 若疑似遭到入侵，請隔離伺服器，並在重新啟動前保全證據。
- 套用修正版本，或在更新前先採取官方臨時措施。
- 重新啟動執行PHP的服務後，確認實際網站服務已套用修補程式。
- 檢查過往日誌，並更換曾暴露的伺服器所用的驗證資訊。

PHP2Shell 的應變應從確認 PHP 使用情況及套用修正版開始。更新後，請重新啟動執行服務。若懷疑遭到入侵，必須在重新啟動前保全證據。修補後仍須檢查日誌並更換驗證資訊。

版本與設定以 2026年10月22日 KISA 公告及 10月23日 PHP 補充公告為準。

## PHP2Shell 是什麼漏洞？

PHP2Shell 是可在未經驗證的情況下執行伺服器程式碼的 PHP 漏洞，涉及網頁伺服器處理請求時的記憶體管理問題。攻擊是否成功取決於執行環境與設定。

| 分類 | 識別編號 | 問題性質 |
| --- | --- | --- |
| 記憶體不足處理問題 | CVE-2026-109618 | 在記憶體不足時處理不完整的內部資料 |
| 請求之間殘留狀態的問題 | CVE-2026-109619 | 在後續請求中使用指向已釋放記憶體的狀態 |

KISA 公告指出，兩項漏洞的嚴重程度皆為 CVSS 9.2 分。攻擊成功後，可能安裝網頁後門或竊取客戶資料。網頁後門是遭濫用來遠端控制伺服器的檔案，也可能導致網站遭竄改及內部網路遭入侵。

KISA 已通報修補程式發布前的資訊外洩與攻擊嘗試。研究團隊公開了運用 AI 發現漏洞的過程。問題出在 PHP 本身，並不限於特定網站產品。[KISA 企業應變守則](https://www.boho.or.kr/kr/bbs/view.do?bbsId=B0000133&menuNo=205020&nttId=72230)、[研究團隊的 PHP2Shell 說明](https://www.php2shell.com/)

## 不同情況的應變順序

更新與證據保全的順序，取決於是否懷疑遭到入侵。一般修補作業是在測試後進行更新及重新啟動。若懷疑伺服器遭到入侵，請先隔離。

| 目前狀態 | 優先處理事項 | 後續處理事項 |
| --- | --- | --- |
| 無入侵跡象的對外開放伺服器 | 檢視相容性並套用修正版 | 重新啟動、確認實際版本、檢查日誌 |
| 發現網頁後門或可疑連線 | 網路隔離並通報 | 保全證據後進行復原 |
| 無法立即更新的伺服器 | 套用官方暫時設定並在前端限制請求 | 規劃修補時程並套用 |
| 連暫時措施也難以實施的伺服器 | 考慮封鎖外部存取或暫停服務 | 修補後判斷是否恢復服務 |
| 由代管業者或製造商管理的環境 | 向管理業者確認是否已套用 | 取得執行環境已套用的佐證 |

更新後重新啟動，是為了讓修正後的程式碼開始執行。事故應變期間延後重新啟動，則是為了保全證據。即使是同一台伺服器，只要懷疑遭到入侵，就應遵循後者的順序。

## 如何確認 PHP 使用情況

請同時檢查資產清單與實際運作中的伺服器。只檢查主要網站，可能會漏掉未納入管理的伺服器。包含 PHP 的設備與容器也須檢查。

1. 列出對網際網路開放的網站與系統。
2. 確認委外製作的網站與舊網站。
3. 確認活動伺服器、測試伺服器及管理頁面。
4. 確認設備管理介面與解決方案是否包含 PHP。
5. 確認容器映像檔與執行中的容器。
6. 記錄各環境的 PHP 版本與管理負責人。

若使用代管服務，請要求業者確認是否已套用修補程式。設備內含的 PHP，請確認製造商提供的更新。內部系統也須檢查，但應優先處理對網際網路開放的伺服器。

## PHP 修正版與支援終止標準

PHP 官方公告中的 8.5 系列修正版為 **8.5.12**。KISA 原文也列出相同版本。這不表示必須等到 8.5.13 才能修補。

| 使用系列 | 兩項漏洞的修正版本 | 應變標準 |
| --- | --- | --- |
| PHP 8.5 | 8.5.13 以上 | 確認該系列最新的安全性版本 |
| PHP 8.4 | 8.4.27 以上 | 確認該系列最新的安全性版本 |
| PHP 8.3 | 8.3.36 以上 | 確認該系列最新的安全性版本 |
| PHP 8.2 | 8.2.35 以上 | 修補的同時準備升級至較新系列 |
| PHP 8.1 及以下 | 正規安全支援已終止 | 轉用受支援的系列，或確認供應商提供的修補程式 |

表格以 2026年10月21日發布的修正版為準。發行版套件顯示的版本號可能維持不變。此時請在變更紀錄中確認是否已修正這兩項 CVE。[PHP 安全性版本公告](https://www.php.net/archive/2026.php)

PHP 8.2 的安全支援終止日期為 2026年12月31日。KISA 建議轉用 PHP 8.3 以上版本。轉換前，請測試應用程式相容性。[PHP 支援時程](https://www.php.net/supported-versions.php)

PHP 8.1 及以下版本的正規安全支援已終止。發行版或長期支援業者提供的修補程式，須另外確認。本次公開的舊版原始碼修補程式，也不代表恢復正規支援。

## 如何更新與重新啟動

更換安裝檔案後，須重新啟動 PHP 執行服務。原有程序可能繼續執行留在記憶體中的程式碼。若懷疑遭到入侵，請先保全證據，再進行下列作業。

1. 檢視修補程式對既有功能的影響。
2. 在測試環境中確認服務相容性。
3. 優先在對網際網路開放的伺服器套用修正套件。
4. 重新啟動所有執行 PHP 的服務。
5. 容器環境應使用修正後的映像檔重新部署。
6. 確認實際處理網頁請求的 PHP 是否已套用更新。

須重新啟動的服務包括 PHP-FPM 與 Apache mod_php。也請確認 php-cgi、FrankenPHP、LiteSpeed。若伺服器上有多個 PHP 環境，須逐一檢查。

`php -v` 顯示的是命令列執行的 PHP 版本，可能與網頁服務使用的 PHP 不同。請勿只憑命令列輸出判定更新已完成。

## 更新前的暫時設定標準

暫時措施只能減少部分攻擊途徑，無法解決全部漏洞。若難以套用設定，請考慮封鎖外部存取。

### 如何套用 memory_limit 設定？

本次漏洞的官方暫時建議為 `memory_limit=-1`。這個值會解除 PHP 本身的記憶體使用上限。請勿將其視為一般運作設定。

解除上限可減少導致記憶體不足的特定路徑，但無法阻止實際的記憶體配置失敗。須一併考慮請求大小限制與資源管理措施。[PHP 記憶體不足漏洞建議](https://github.com/php/php-src/security/advisories/GHSA-w8hw-w9fx-j79w)

| 項目 | 官方暫時措施 | 套用時須確認的內容 |
| --- | --- | --- |
| `memory_limit` | 設為 `-1` | 套用管理員層級設定，避免應用程式變更 |
| `session.upload_progress.enabled` | 設為 `0` | 使用在處理請求前即生效的設定位置 |
| `post_max_size` | 無須上傳時，以 `8M` 為範例 | 一併檢視實際服務需求與前端限制 |
| `upload_max_filesize` | 設為小於 `post_max_size` | 確認對檔案上傳功能的影響 |
| `fatal_error_backtraces` | 在 PHP 8.5 中設為 `0` | 不要一律套用至其他系列 |

表中的設定值以 2026年10月官方應變公告為準。`8M` 是針對無須上傳的服務提出的範例，並非所有服務都應套用相同大小。

1. 在網頁應用程式防火牆、網頁伺服器及代理伺服器上限制請求大小。
2. 確認沒有大小資訊的請求是否也受到限制。
3. 若無須上傳，請在前端封鎖 multipart 請求。
4. 確認網頁應用程式防火牆的最新封鎖規則。
5. 在 `php.ini` 或 PHP-FPM pool 等位置套用設定。
6. 確認是否須保全證據後，再重新啟動 PHP 程序。

請勿只透過 `ini_set()` 套用暫時設定。原本須在處理請求前生效的設定，可能會太晚套用。也請勿期待 PHP-FPM 的 `.user.ini` 能發揮相同作用。[PHP 官方暫時措施](https://www.php.net/archive/2026.php)

### 10月23日補充公告中須確認的內容

PHP 在補充公告中建議關閉上傳進度功能。這是針對部分設定組合中仍存在的另一條執行路徑所做的說明。若已關閉該功能，公告指示應維持到下一次定期修正版發布。

相關條件包括在執行期間變更工作階段序列化方式。並非所有 PHP 安裝環境都符合相同條件。修補後是否恢復設定，請查閱補充公告再決定。（確認設定值 session.upload_progress.enabled=0，建議維持至下一次定期錯誤修正版本發布 · 來源 php.net · 2026-10-23 確認）[PHP Session upload progress 補充公告](https://www.php.net/archive/2026.php)

## 如何檢查日誌與更換驗證資訊

KISA 建議至少檢查 **2026年10月20日當日及之後**的紀錄。若可行，也請檢查更早的紀錄。修補無法挽回已發生的入侵或資訊外洩。

| 檢查對象 | 須確認的跡象 |
| --- | --- |
| 網頁伺服器日誌 | 反覆出現的 HTTP 500 錯誤 |
| PHP 執行紀錄 | 異常終止與 segfault |
| 網站、上傳及暫存資料夾 | 新增或遭修改的 PHP 檔案 |
| 程序執行紀錄 | 網頁伺服器執行 sh、bash 或下載工具 |
| 網路連線 | 新連線至陌生外部位址的跡象 |
| 網站、管理頁面 | 遭暗中加入的外部指令碼 |

不能只因出現錯誤就認定遭到入侵。反過來說，沒有異常紀錄也不能確定安全。KISA 說明如下。

> 即使紀錄中沒有異常，也無法保證安全，因此應同時進行更新與驗證資訊更換
>
> KISA「PHP 安全漏洞（PHP2Shell）相關企業資安應變守則」

修補前曾暴露於網際網路的伺服器，建議更換驗證資訊。發現入侵跡象的伺服器則務必更換。更換對象包括資料庫密碼與管理員密碼。也請檢查 API 金鑰與存取權杖是否可能外洩。

連接個人資料資料庫的服務，也請檢查資料庫紀錄。須檢查大量查詢與資料匯出的跡象。也請限制從網際網路直接存取 phpMyAdmin。網頁服務帳號的資料庫權限應縮減至必要範圍。[個人資料保護委員會預防措施說明](https://pipc.go.kr/np/cop/bbs/selectBoardArticle.do?bbsId=BS074&mCode=C010010000&nttId=12588)

## 懷疑遭到入侵時的應變順序

懷疑遭到入侵時，請勿關閉伺服器或立即重新啟動。重新啟動可能使記憶體中殘留的攻擊跡象消失。請先進行網路隔離，再蒐集證據。

1. 從網路端封鎖伺服器的外部連線。
2. 韓國境內企業請透過 보호나라 的入侵事故通報選單進行通報。
3. 保存日誌與執行中程式清單。
4. 也請保存目前的網路連線資訊。
5. 取得證據後，再進行更新與重新啟動。
6. 移除網頁後門並更換驗證資訊。

韓國境內的諮詢窗口為 KISA 118。通報選單為 보호나라 > 入侵事故通報 > 進行通報。若在海外營運，請確認當地的通報窗口。

## 常見錯誤比較

要確認是否已套用修補程式，還須檢查執行狀態與變更紀錄。只看到安裝完成訊息，並不代表確認作業已結束。請將下列判斷納入檢查表。

| 常見判斷 | 須確認的內容 |
| --- | --- |
| `php -v` 改變就算完成 | 確認網頁服務實際使用的 PHP |
| 只要安裝套件就算完成 | 確認 PHP 執行服務已重新啟動 |
| 版本號不變就表示未處理 | 確認發行版變更紀錄中是否已修正相關 CVE |
| 有網頁應用程式防火牆就能省略修補 | 確認最新規則，同時更新 PHP |
| 日誌沒有異常就表示沒有外洩 | 也須檢視驗證資訊外洩的可能性 |
| 委外網站由業者自行處理 | 要求提供各項服務已套用的佐證 |

請勿在正式環境的伺服器上執行從網路找到的驗證程式碼。KISA 警告，有假冒的 PoC 內含惡意程式。PoC 是用來展示漏洞可被利用的驗證程式碼。請先從版本與修補紀錄確認是否存在漏洞。

## 委外與代管環境的處理完成確認表

處理完成報告宜保留各項服務的確認依據。下表是將 KISA 應變守則整理成工作確認項目，並非另外制定的官方提交表格。

| 確認項目 | 向業者或負責人索取的內容 |
| --- | --- |
| 是否遺漏對象 | 網站、管理頁面與測試伺服器的檢查清單 |
| 漏洞修正 | 已套用的版本，或列有兩項 CVE 的套件變更紀錄 |
| 執行狀態 | 服務重新啟動或容器重新部署紀錄 |
| 實際套用情況 | 從網頁服務確認的 PHP 執行環境 |
| 入侵檢查 | 已檢查的日誌期間與發現事項 |
| 驗證資訊 | 更換對象與完成情況 |
| 尚待處理的工作 | 僅套用暫時措施的伺服器及後續修補計畫 |

例如，假設業者只通知套件已安裝完成。此時請要求提供重新啟動及網頁執行環境的確認結果。日誌檢查與驗證資訊更換則可作為獨立項目確認。

## FAQ

### 更改登入密碼就能阻擋 PHP2Shell 嗎？
此漏洞無須登入即可被利用，因此僅更改密碼無法解決。必須安裝 PHP 安全性更新。更換驗證資訊是因應可能外洩的另一項措施。

### PHP 8.5 必須等到 8.5.13 嗎？
PHP 與 KISA 原文將這兩項漏洞的修補版本列為 8.5.13。這不代表必須等待 8.5.13。套用更新時，也請確認該版本系列的最新官方發行版本。

### 使用 PHP-FPM 就不必檢查嗎？
PHP-FPM 也需要檢查。攻擊條件可能因執行方式而異。請勿僅憑環境名稱判斷是否安全。

### php -v 的結果顯示為修補版本，就代表處理完成了嗎？
命令列使用的 PHP 可能與網頁服務使用的 PHP 不同。請確認實際處理網頁請求的環境，也必須確認執行中的服務是否已重新啟動。

### 修補後版本號碼沒有改變，就代表失敗了嗎？
發行版或廠商提供的套件可能會將修正內容套用至既有版本。請在套件變更紀錄中確認是否已納入這兩項 CVE 的修正。

### memory_limit=-1 是此次應對措施中禁止使用的設定嗎？
此次漏洞的官方暫行建議包含這項設定，必須與一般維運建議區分。請一併評估請求限制與資源管理措施。

### 沒有檔案上傳功能的網站也在影響範圍內嗎？
不能僅因沒有上傳功能就將其排除在影響範圍之外。由於這是 PHP 本身的漏洞，請確認使用版本與修補狀態。封鎖不必要的 multipart 請求只是暫時措施。

### PHP 8.1 及以下版本若有廠商修補程式，可以繼續使用嗎？
廠商修補程式須與正式支援終止狀態分別確認。即使暫時套用該修補程式，也請制定轉用受支援版本的計畫。

### 日誌沒有異常，就可以保留原有驗證資訊嗎？
不能僅憑日誌判斷未曾發生資訊外洩。KISA 建議更換修補前暴露於網際網路的伺服器驗證資訊。若有入侵跡象，務必更換。

### 懷疑遭到入侵時，應該先更新嗎？
請先將其與網路隔離。通報並保存證據後，再進行更新。重新啟動可能導致記憶體中殘留的攻擊痕跡消失。

### 使用主機代管服務的用戶應確認哪些事項？
請向廠商索取各項服務已套用修補程式的依據，也請索取重新啟動及實際網頁執行環境的確認結果。日誌檢查與驗證資訊是否已更換，請另行確認。

### 修補後可以重新開啟上傳進度設定嗎？
請確認 PHP 於 2026年10月23日發布的補充公告。由於部分設定組合存在其他問題，建議維持停用此功能。是否恢復設定，請在確認後續修正內容後再判斷。

## Sources

- [KISA 보호나라：PHP 安全漏洞（PHP2Shell）相關企業安全應對守則，2026年10月22日](https://www.boho.or.kr/kr/bbs/view.do?bbsId=B0000133&menuNo=205020&nttId=72230)
- [PHP 2026年公告：10月21日安全更新與10月23日 Session upload progress 補充說明](https://www.php.net/archive/2026.php)
- [PHP 安全公告：RCE via OOM corruption](https://github.com/php/php-src/security/advisories/GHSA-w8hw-w9fx-j79w)
- [PHP 安全公告：RCE via stale global state](https://github.com/php/php-src/security/advisories/GHSA-6wmf-4rv5-p3rp)
- [PHP Supported Versions：官方支援期間](https://www.php.net/supported-versions.php)
- [PHP2Shell：研究團隊的漏洞說明與影響範圍](https://www.php2shell.com/)
- [個人資料保護委員會：呼籲針對 PHP 安全漏洞採取個人資料外洩預防措施，2026年10月22日](https://pipc.go.kr/np/cop/bbs/selectBoardArticle.do?bbsId=BS074&mCode=C010010000&nttId=12588)

## Images

![一名女子在伺服器機房內，手持藍色網路線接頭，靠近機架式伺服器的網路埠。](https://injoys.com/rails/active_storage/blobs/proxy/eyJfcmFpbHMiOnsiZGF0YSI6MzIzODIsInB1ciI6ImJsb2JfaWQifX0=--756ccdbcf3c83be470043fadc3bfdf6d3eeeef02/ai-6de3df23.webp)
![一名年長技術人員在工廠內，查看開啟的網路設備櫃旁平板電腦上的狀態畫面](https://injoys.com/rails/active_storage/blobs/proxy/eyJfcmFpbHMiOnsiZGF0YSI6MzIzODgsInB1ciI6ImJsb2JfaWQifX0=--ab8091216d8ebf858c1dfbe779a6e6a5d3535ae7/ai-61ada64c.webp)