PHP2Shell 是什麼？七成網站在用的 PHP 出了漏洞，你的網站要做的三件事

目錄

1. 發生了什麼
2. 哪些網站受影響
3. 現在被拿來攻擊了嗎
4. 你的網站要做的三件事
5. 第一件：查出網站實際在跑的 PHP 版本
6. 第二件：更新，然後重啟
7. 第三件：問主機商，並看一眼有沒有異狀
8. AI 參與找到這個洞，對防守方代表什麼
9. 還不確定的事
10. 常見問題
11. 出處

撰寫於 2026-10-26。本文的事實來自 PHP 官方公告、CVE 紀錄、發現者（Wiz、Calif）的原文與各資安廠商公告，每段標明出處；廠商說法互相矛盾的地方直接寫出來，查不到的寫「不知道」。

2026 年 10 月 21 日，PHP 發布了緊急安全更新，修補兩個漏洞：CVE-2026-109618 與 CVE-2026-109619，合稱 PHP2Shell。兩個的 CVSS 4.0 分數都是 9.2（Critical）。用 PHP 官方的話說，它們「可能允許未經認證的遠端程式碼執行」，也就是攻擊者不用登入、不用你的網站本身有 bug，送出特製的網頁請求就可能在你的伺服器上跑他的程式。

標題的「七成」要講清楚：這是發現者之一 Wiz 的說法，PHP 撐起全球約 70% 的網站。這是 PHP 的使用率，不是「七成網站已經被入侵」。但 Wiz 也說，過去十年發布的每一個 PHP 版本都至少中其中一個漏洞，最遠回溯到 PHP 5.4。所以如果你的網站跑 PHP，而且這幾天沒人動過伺服器，你大概就在受影響的範圍裡。

先給結論：

你的網站如果用 WordPress、Laravel、Drupal、Joomla、Magento 或任何 PHP 程式，要確認伺服器上的 PHP 已更新到 8.5.12、8.4.27、8.3.36、8.2.35（或主機商的修補版套件），而且更新後 PHP 行程有重啟。更新 WordPress 或外掛修不到這個洞。

#發生了什麼

項目	內容
漏洞	CVE-2026-109618（記憶體不足處理造成的資料損壞）、CVE-2026-109619（請求結束後殘留的狀態指向已釋放的記憶體）
嚴重度	CVSS 4.0：9.2 Critical（兩個都是）
前提	不需登入、不需使用者互動；攻擊複雜度高、需特定條件（CVSS 向量 AC:H/AT:P）
美國 CISA 評估	CVE 紀錄裡 CISA 的補充評估（10/21 評估、10/22 更新）標為尚無利用證據、無法自動化，之後可能改變
修補版本	8.5.12、8.4.27、8.3.36、8.2.35（2026-10-21 發布）
8.1 以下	官方不再更新，另提供 7.4、8.0、8.1 原始碼修補

依 PHP 官方公告，兩個漏洞的白話版是：

• CVE-2026-109618：記憶體不足時，PHP 會中斷正在處理的請求，這時內部資料可能只建立了一半，接著清理步驟把這份不完整的資料當成正常資料處理。
• CVE-2026-109619：一個請求擁有的內部狀態，在它的記憶體被釋放後還留著；同一個 PHP 行程接下來處理的請求，可能在重新初始化之前就用到這份過期的狀態。

兩個都屬於記憶體安全問題，根本解法只有更新 PHP。

時間線也值得知道：PHP 10/20 預告 10/21 14:00 UTC 發版；Securelist 等廠商說細節在發版前就外洩（Hacker News 貼文），PHP 實際在 13:34 UTC 左右就公布了。Wiz 的時間線是 8 月 19 日發現、8 月 24 日回報 PHP；另一組發現者 Calif 的時間線是 8 月 1 日發現、8 月 11 日回報。也就是說，Calif（8/1）與 Wiz（8/19）的時間線相隔不到三週；GitHub 公告列了四位回報者，Wiz 也說發布前和 PHP、Calif、OpenAI 一起處理過發現與驗證。

#哪些網站受影響

伺服器設定：PHP 官方說，所有在處理網頁請求的 PHP 都在風險內，包括 PHP-FPM、Apache mod_php、php-cgi、FrankenPHP、LiteSpeed。其中 mod_php 風險最高，因為已經有攻擊示範能在任何應用程式碼執行之前就觸發。

版本：8.2 到 8.5 修補版以前的全部版本；8.1 以下官方不再修，Wiz 說最遠回溯到 5.4。

WordPress、Laravel 這些框架：漏洞在 PHP 本身，不在框架。發現者 Calif 列出在預設設定下確認可未登入執行程式的應用，包括 WordPress 7.1.2、Drupal 11.4.3、Joomla 6.1.4、Magento 2.4.9、phpMyAdmin 5.2.3、Nextcloud 35.0.1、Laravel 13.11、Symfony 8.1 與 WHMCS。Wiz 另外用 WordPress、Drupal、Joomla 官方最新版的容器映像檔示範成功。這些是 Calif 測試時的版本號，之後這幾套各自出了新版，但不改變結論，因為漏洞在 PHP。WordPress 官方 10/21 的公告也說，這兩個漏洞不是 WordPress 專屬，網站負責人要更新的是 PHP。所以「我的 WordPress 是最新版」不是安全的理由。

虛擬主機（共享主機）：你通常沒有權限更新 PHP 本身，也沒辦法自己套用官方的暫時緩解設定。PHP 官方明說緩解設定要放在 php.ini、FPM pool 或伺服器設定裡，不能靠程式裡的 ini_set() 或 .user.ini。我們的推論是：用虛擬主機的人，能做的事就是確認主機商已經修好，下面第三件事會給你問法。

#現在被拿來攻擊了嗎

截至 2026-10-26，各家說法不一致，整理如下：

• 公開的攻擊程式：Rapid7 說已有多個公開的概念驗證（PoC），但每個只對特定的作業系統、PHP 版本與網頁伺服器組合有效，沒有一個看起來能廣泛穩定運作；Rapid7 自己的嘗試也只在條件很窄的實驗環境成功。Rapid7 同時提醒，更通用的攻擊手法隨時可能出現，現在難以穩定利用應該當成修補的空檔，不是拖延的理由。
• 攻擊嘗試：Rapid7 說有多起攻擊嘗試的報告，但他們沒觀察到實際遭利用的案例。Sophos 看到掃描與少量失敗的嘗試，並在 10/22 更正了先前較嚴重的說法。依 Help Net Security 轉述，Amazon 的蜜罐在 10/17，也就是公開揭露前四天，就記錄到一次利用嘗試。
• 撤回的入侵報告：Palo Alto Networks 的 Unit 42 在 10/23 說觀察到一起歐洲政府機關遭入侵的案例，10/25 撤回，原文是無法確認初始入侵與 PHP2Shell 有關。

我們的讀法：攻擊程式已經在外面，有人在掃，有人在試。還沒有確認的大規模入侵，不代表你可以等。

修補的速度也不樂觀。OX Security 用 Shodan 量測，修補釋出 24 小時後，能看出版本號的有漏洞 PHP 主機中，99.3% 還沒顯示修補版本（OX 只看伺服器對外回傳的版本號。我們的推論是：發行版修補常常不改版本號，會被算成未修，所以這個數字只能看方向，不是精確比例）。Bitsight 則說，能辨識版本的 PHP 主機裡，只有約三分之一跑的是有官方修補的 8.2 到 8.5，最常見的分支是 7.4。

#你的網站要做的三件事

#第一件：查出網站實際在跑的 PHP 版本

不同身分有不同的查法：

• 用 WordPress：後台「工具 → 網站健康狀態 → 資訊 → 伺服器」，會列出 PHP 版本。
• 用虛擬主機：主機控制台（例如 cPanel 的 PHP 版本選擇或 MultiPHP 管理員、Plesk 的 PHP 設定）會顯示每個網域用的 PHP 版本。面板通常只顯示分支（如 8.2），看不出修補層級，所以還是要問主機商。
• 有伺服器權限的工程師：php -v 看到的是命令列的 PHP，不一定是網頁在用的那一個。要確認網頁實際版本，看網頁環境的 phpinfo()（看完立刻刪掉那個檔案），並用套件管理工具查套件版本，例如 dpkg -l | grep php 或 rpm -qa | grep php。

注意：版本號不一定說了算。 Linux 發行版常把修補放進舊版本的套件裡，版本號不變。例如依 Wiz 漏洞資料庫，Ubuntu 的 php8.1 修補版套件是 8.1.2-1ubuntu2.28，php -v 顯示的還是 8.1.2。所以「版本號很舊」不一定沒修，「版本號 8.3.x」也不一定有修，要看套件版本或問提供者。

有伺服器權限的話，也可以查套件的更新紀錄，例如 apt changelog <套件名稱> | grep CVE-2026-10961 或 rpm -q --changelog <套件名稱> | grep CVE-2026-10961。這招只在發行版把 CVE 編號寫進更新紀錄時有效，查不到不代表沒修。

#第二件：更新，然後重啟

• 跑 8.2 到 8.5：更新到該分支的修補版，8.5.12、8.4.27、8.3.36 或 8.2.35，或是你的發行版、主機商發布的修補套件。
• 更新完要重啟所有 PHP 行程（php-fpm、apache2 或 httpd、frankenphp，LiteSpeed 則是 lsws 或 lsphp）。Google Cloud 的公告特別提醒：只更新磁碟上的套件、不重啟，正在跑的舊行程還是有漏洞。
• 更新後，PHP 官方另建議在下一個例行版本前設 session.upload_progress.enabled=0（針對 CVE-2026-115560；PHP 官方說，程式執行時不會切換 session.serialize_handler 的網站可以保持開啟，不確定就關）。
• 跑 8.1 以下：官方不會再出版本。選項依序是：升到 8.3 以上的修補版（8.2 的安全支援 2026-12-31 結束，能的話直接上 8.4 或 8.5）；或確認你的發行版、主機商、長期支援廠商已提供修補套件；再不然就是自行用官方提供的 7.4、8.0、8.1 原始碼修補編譯。升版前要先確認你的佈景主題與外掛相容，這是很多網站停在 7.4 的原因，但這次停在原地的代價變高了。

真的沒辦法馬上更新，PHP 官方給了暫時的緩解設定，並明說「只降低特定攻擊路徑的暴露，不會讓安裝變安全」：

; CVE-2026-109619 相關，設完要重啟每一個 PHP 行程
session.upload_progress.enabled = 0
; 只有 PHP 8.5 需要
fatal_error_backtraces = 0

; CVE-2026-109618 相關
; memory_limit 要用 php_admin_value 之類應用程式改不回去的方式設定
memory_limit = -1
; 不需要上傳檔案的網站用 8M，需要上傳的用 32M，upload_max_filesize 要比它小
post_max_size = 8M

memory_limit = -1 是拿掉 PHP 自己的記憶體上限，PHP 官方建議同時用容器或 cgroup 設記憶體上限，避免單一行程吃光整台機器，並特別說不要用 RLIMIT_AS 或 RLIMIT_DATA 代替。這組設定請交給懂伺服器的人改，改錯會影響網站正常運作。

網站前面如果有 WAF，可以多一層。依 Help Net Security 引述 Cloudflare 技術長，Cloudflare 已對所有客戶（含免費方案）部署針對已知攻擊手法的 WAF 規則；依 PPC Land 轉述，Cloudflare 自己也說仍然要更新 PHP。WAF 是第二層，不是解法。

#第三件：問主機商，並看一眼有沒有異狀

用虛擬主機或託管主機的，直接把下面這段傳給主機商：

你好，想確認 PHP2Shell（CVE-2026-109618、CVE-2026-109619）的處理狀況：

1. 我的網站（網域：＿＿＿）目前實際使用的 PHP 版本與套件版本是什麼？
2. 這個版本是否已包含上述兩個 CVE 的修補？
3. 更新後 PHP 行程是否已經重啟？
4. 如果我用的是 8.1 以下，你們是否提供修補版本，或建議我升到哪一版？

如果對方答不出第 2 題，或回答「我們的 PHP 很穩定」這類跟問題無關的話，這本身就是答案。

有伺服器權限的，看一下這幾個訊號（整理自 Wiz 與 Google Cloud 的公告）：

• 不尋常的 multipart 上傳請求，接著出現 memory limit 錯誤（Wiz）
• PHP-FPM 行程以 SIGSEGV（結束碼 139）大量重啟，或出現 core dump（Google Cloud）
• php-fpm、apache 或 httpd 底下長出 sh、bash、curl、wget 這類子行程（Google Cloud）
• 同一個網址短時間內 500 與 200 交錯的大量 POST（Google Cloud）
• 伺服器回應裡 Set-Cookie: PHPSESSID= 長度異常（超過 256 位元組）（Google Cloud、Wiz）

沒看到這些訊號不代表沒被入侵：Google Cloud 指出有利用鏈不會留下崩潰或錯誤日誌。若懷疑已被入侵，重啟 PHP 前先請處理的人擷取記憶體（Google Cloud）。

看到上面這些訊號，先保留日誌，不要急著重開機清掉證據，再找能處理資安事件的人。

頁尾的 UltraProbe 免費掃描檢查的是網站的 SEO、AEO、AAO 與 AI 防禦層面，不會檢查 PHP 版本或這兩個漏洞，掃出沒問題不代表你已經修補。

#AI 參與找到這個洞，對防守方代表什麼

Wiz 的標題是「AI 找到影響七成網路的嚴重漏洞」，原文寫 Wiz 在研究過程中使用了 Wiz Atlas、Gemini 4 Argon 與 GPT-5.6 Sol，其中 Argon 對找到與協助修補漏洞的貢獻特別顯著。Wiz 也寫：底層缺陷存在了很久，證明它能被利用需要極複雜的步驟，「前沿 AI 模型大幅降低了這個門檻，把長期存在的缺陷變成可用的攻擊」。Wiz 的原文同時引用了 Google DeepMind 的說法，AI 角色的敘述出自有產品利益的一方。

另一組發現者 Calif 的說法比較收斂。Calif 研究員 Ryan Austin 寫，初次發現時「沒有用特殊的工具框架，也沒有用一般人拿不到的模型」，他選的是自己熟悉、知道它漏洞歷史的目標，帶著一個具體的假設去找。他也說，模型預設會從最新、最有名的 bug 往附近的舊程式碼找，不會自己想到二十年前的冷門利用手法。

兩邊並不矛盾，合起來比較接近實情：是熟悉目標的人帶著 AI 找到的，不是 AI 自己找到的。 但對防守方來說，有三件事是確定的：

1. 修補窗口變短了。 Wiz 寫，過去攻擊程式要針對不同 PHP 版本、設定、記憶體配置一個個改寫，現在 AI 能幫忙改。多組人在幾週內找到同一批問題，細節又在正式發布前外洩，從「有人知道」到「有人在試」的時間被壓縮了。以前「下個月維護時再更新」的節奏，對這種等級的漏洞已經太慢。
2. 老漏洞會被重新挖出來。 這次的根源可以追到很早期的設計；Calif 的時間線提到 2004 年就有人發現過相關的記憶體上限問題。AI 讓「再看一次舊東西」變便宜，長年沒動的舊系統風險會上升。
3. 防守的前提是知道自己跑什麼。 這次能不能在一天內處理完，取決於你能不能馬上回答「我有幾個網站、各跑哪一版 PHP、誰負責更新」。這份清單平常就該有。

#還不確定的事

• 實際被成功入侵：截至 10/26 沒有確認。這一點可能隨時變，以 PHP 官方與主要資安廠商的更新為準。
• 台灣有多少網站受影響：我們讀到的公開資料都沒有台灣的數字，所以這篇不寫。
• 兩個 CVE 的技術細節對應：PHP 官方公告與 Wiz 的漏洞表，在哪個攻擊路徑屬於哪個 CVE 上寫法不一致。對網站負責人來說不影響動作，兩個一起修就對了。
• 美國 CISA 是否列入已知遭利用漏洞清單（KEV）：撰稿時未查到紀錄。

#常見問題

PHP2Shell 是什麼？ PHP 本身的兩個漏洞 CVE-2026-109618 與 CVE-2026-109619 的合稱，CVSS 4.0 都是 9.2。不用登入就可能在伺服器上執行程式。2026-10-21 由 PHP 發布 8.5.12、8.4.27、8.3.36、8.2.35 修補。

PHP2Shell 已經被拿來攻擊了嗎？ 截至 2026 年 10 月 26 日，已有多個公開的概念驗證攻擊程式，也有多家廠商看到掃描與攻擊嘗試；但我們讀到的主要廠商沒有一家維持「確認成功入侵」的說法，Unit 42 在 10 月 25 日撤回了先前的入侵報告。這不代表安全，代表還在早期。

我的 WordPress 已經是最新版，還要處理嗎？ 要。漏洞在 PHP，不在 WordPress。發現者 Calif 確認在預設設定下 WordPress 7.1.2 能被未登入執行程式，Wiz 也用官方最新版的 WordPress 容器映像檔示範成功。要更新的是伺服器上的 PHP。

我用 PHP 7.4，怎麼辦？ 官方不再發布 7.4 的版本，但提供了原始碼修補。實際做法：先問主機商或發行版是否已出修補套件；中期升到 8.3 以上的修補版（8.2 的安全支援 2026-12-31 結束，能的話直接上 8.4 或 8.5）。

我用的是 Laravel 或自己寫的 PHP 程式，有影響嗎？ 有。只要是用 PHP 處理網頁請求就在範圍內，跟框架無關。Calif 的確認清單裡也有 Laravel 13.11 與 Symfony 8.1。

裝了 WAF 或 Cloudflare 就不用更新嗎？ 要更新。WAF 能擋已知的攻擊手法，但這類漏洞的變形多，Cloudflare 自己也說仍然要更新 PHP。

10/23 又出了一個 PHP 漏洞，跟這個一樣嗎？ 那是 CVE-2026-115560，跟 session 上傳進度功能有關。PHP 官方在 10/23 的公告說，只有「程式在執行時把 session.serialize_handler 從 php_binary 或 php_serialize 切成 php，且上傳進度仍開啟」這種少見組合才會中，所以排在下一個例行版本才修（截至 10/26 尚未釋出）。官方建議在那之前把 session.upload_progress.enabled=0，已經更新到 8.5.12 等修補版的也一樣。設完要重啟 PHP 行程。

Windows 版 PHP 又出了「-1」版本，跟這個有關嗎？ Windows 版 PHP 10/26 另有 -1 重新打包版（修 Brotli 漏洞 CVE-2026-111497，與 PHP2Shell 無關），PHP 版本號不變。

怎麼確認主機商修好了？ 問三件事：實際的 PHP 版本與套件版本、是否含這兩個 CVE 的修補、更新後是否重啟 PHP 行程。上面有可以直接複製的範本。

#出處

• PHP 官方安全公告（2026-10-21）：https://www.php.net/archive/2026.php#2026-10-21-5
• PHP 官方發版預告（2026-10-20）：https://www.php.net/archive/2026.php#2026-10-20-1
• PHP 官方 session 上傳進度公告，CVE-2026-115560（2026-10-23）：https://www.php.net/archive/2026.php#2026-10-23-1
• GitHub 安全公告 GHSA-w8hw-w9fx-j79w（CVE-2026-109618）：https://github.com/php/php-src/security/advisories/GHSA-w8hw-w9fx-j79w
• GitHub 安全公告 GHSA-6wmf-4rv5-p3rp（CVE-2026-109619）：https://github.com/php/php-src/security/advisories/GHSA-6wmf-4rv5-p3rp
• CVE 紀錄 CVE-2026-109618：https://www.cve.org/CVERecord?id=CVE-2026-109618
• CVE 紀錄 CVE-2026-109619：https://www.cve.org/CVERecord?id=CVE-2026-109619
• Wiz，PHP2Shell: AI uncovers critical RCE vulnerabilities affecting 70% of the Internet：https://wiz.io/blog/php2shell-php-rce
• Wiz 漏洞資料庫 CVE-2026-109618（發行版修補套件版本）：https://www.wiz.io/vulnerability-database/cve/cve-2026-109618
• Calif，PHP2Shell: A tale of two PHP remote vulnerabilities：https://calif.io/php2shell/
• WordPress 官方，Critical PHP Security Release（2026-10-21）：https://wordpress.org/news/2026/10/critical-php-security-release/
• Google Cloud，Responding to core PHP vulnerabilities：https://cloud.google.com/blog/products/identity-security/responding-to-core-php-vulnerabilities-cve-2026-109618-cve-2026-109619
• Unit 42 Threat Brief（2026-10-25 更新）：https://unit42.paloaltonetworks.com/cve-2026-109618-cve-2026-109619/
• Rapid7：https://www.rapid7.com/blog/post/etr-cve-2026-109618-and-cve-2026-109619-critical-unauthenticated-remote-code-execution-in-php/
• Sophos：https://www.sophos.com/blog/proof-of-concept-exploit-released-for-php-vulnerabilities-109618-109619
• Help Net Security：https://helpnetsecurity.com/2026/10/21/php2shell-php-vulnerabilities-patched-cve-2026-109618-cve-2026-109619
• OX Security，24 小時修補率：https://www.ox.security/blog/php2shell-24-hours-in-99-3-of-measurable-php-instances-are-still-unpatched/
• Bitsight：https://www.bitsight.com/blog/critical-vulnerability-alert-cve-2026-109618-and-cve-2026-109619-php2shell
• Qualys：https://blog.qualys.com/vulnerabilities-threat-research/2026/10/20/php-announces-critical-security-release-for-two-vulnerabilities
• Trend Micro：https://success.trendmicro.com/en-US/solution/KA-0024789
• Securelist（Kaspersky）：https://securelist.com/php2shell-critical-vulnerabilities-in-php/121596/
• PPC Land 轉述 Cloudflare WAF 規則：https://ppc.land/cloudflare-blocks-php2shell-exploits-9-hours-before-php-flaws-went-public/

更新紀錄：2026-10-27 更正 session.upload_progress 例外條件的說法，以 php.net 10/23 公告為準。