PHP2Shell 在 Synology 上的應用：我們如何在一天內修復六個網站

PHP2Shell 業界最終將 CVE-2026-109618 和 CVE-2026-109619 這兩個 PHP 引擎本身存在的嚴重漏洞命名為 PHP2Shell，這兩個漏洞允許未經身份驗證的遠端程式碼執行。漏洞詳情於 2026 年 10 月 20 日洩露，比官方正式披露早一天，PHP 專案於 10 月 21 日發布了緊急版本。由於漏洞存在於解釋器中，而非任何應用程式中，因此修補 WordPress、Joomla 或 MediaWiki 等應用程式毫無作用。唯一的真正解決方法是重新建立 PHP 版本。我們在 Synology 硬體上運行六個公共 WordPress 網站，而 PHP2Shell 的出現意味著我們必須在同一周內重建所有這些網站。本指南將介紹該漏洞的本質、如何透過套件中心在 DSM 上進行修補、當您的網站運行在容器中時如何處理該漏洞，以及 Synology 的修復方案與其他 NAS 廠商迄今為止的修復方案之間的顯著差異。

SynoPower Club 點：在 PHP2Shell 安全公告發布後的一個工作天內，我們的六個網站都完成了修補程式更新。這並非什麼驚天動地的壯舉，而是 Synology 在公告發布當天就發布了修復軟體包。 Synology-SA-26:14 於 10 月 22 日發布，狀態為“已解決”，並附有完整的修復版本列表，涵蓋 PHP 7.4 及以下版本。同一天，QNAP 發布了 QSA-26-18，狀態為“正在修復”，但每個修復版本清單中都顯示“待公佈”。而 ASUSTOR 的因應措施則是從 App Central 中刪除舊版 PHP，而不是發布補丁。如果您在 NAS 上自行託管公共網站，那麼這其中的差距並非無關緊要。它意味著您是需要更新軟體包，還是只能等待網站下線。

什麼是 PHP2Shell？它有何不同之處？

PHP2Shell 並非單一 bug，而是一系列相關的記憶體安全漏洞，這些漏洞存在於 PHP 在處理記憶體耗盡的請求時進行清理的過程中。 PHP 使用 longjmp() 為了避免致命錯誤（包括記憶體溢出），這種跳轉會跳過通常會將引擎恢復到已知狀態的清理程式碼。其中一些狀態是全域的，會延續到同一工作進程處理的下一個請求中。

CVE-2026-109618 是記憶體溢位漏洞。精心建構的 HTTP 請求會在請求資料僅部分初始化時耗盡記憶體限制，導致清理例程遍歷到尚未完成的結構。 CVE-2026-109619 是釋放後使用漏洞：指向已釋放請求記憶體的全域狀態可能被同一工作進程上的後續請求讀取，導致程式碼執行或記憶體外洩。

PHP2Shell 有兩個特性使其比一般的 PHP 安全漏洞更嚴重。首先，它是預認證漏洞。這兩個漏洞都會在任何應用程式層驗證運行之前觸發，因此登入牆、會員外掛程式或管理員密碼都無法起到保護作用。其次，記憶體外洩漏洞會洩漏工作進程內存，而 WordPress 網站上的 PHP 工作進程會持有資料庫憑證、API 令牌和支付金鑰。即使讀取成功，也不需要執行程式碼，就能讓你的一週都陷入困境。

PHP 安全團隊將這兩個 PHP2Shell CVE 的 CVSS v4.0 評分定為 9.2 分。 Synology 在其安全公告中，根據 CVSS v3.1 給出了 9.8 分的評分。不同的評分標準，得出的結論相同。漏洞利用報告不一：watchTowr 表示已發現針對其蜜罐網路的攻擊嘗試，而 Bitdefender 在撰寫本文時未在其遙測資料中發現任何此類攻擊，QNAP 則表示未收到任何針對 QNAP 產品的漏洞利用報告。

PHP2Shell 與普通 WordPress 漏洞利用

大多數攻擊公共 WordPress 網站的問題都源自於外掛漏洞。其模式很常見：插件自帶一個損壞的 REST 端點，掃描器發現該漏洞，用戶更新插件後漏洞就被修復了。 PHP2Shell 完全打破了這種慣例，因此，對插件進行例行檢查在這裡是徒勞無功的。

方面	典型插件 CVE	PHP2Shell
蟲子居住的地方	應用程式程式碼（外掛程式或主題）	PHP解釋器本身
誰能觸發它	通常需要訂閱者或管理員角色	無人。預授權，在應用程式邏輯運行之前。
更新 WordPress 有幫助嗎？	通常是的	不。核心和插件的更新無關緊要。
WAF（妻子同意機制）能阻止它嗎？	通常情況下，一旦規則存在	部分如此。請求形狀規則缺少 OOM 路徑。
真正能解決這個問題的是什麼？	插件更新	一個新的 PHP 建置版本，僅此而已。
爆炸半徑	一個網站，一項功能	盒子上的所有 PHP 網站，一次全部加載完畢。

正是最後一行程式碼導致 PHP2Shell 專案耗時一整天，而不是一個下午。 NAS 上的一個共用 PHP 套件可能被十幾個 Web Station 虛擬主機使用，而一個容器映像檔可以作為多個網站的基礎。補丁不是針對每個網站，而是針對每個運行時，你必須先列舉所有運行時，才能說任何工作已經完成。

如何判斷你的NAS是否暴露在外

要評估 PHP2Shell 漏洞，首先要區分兩個不同的問題：目標主機是否包含易受攻擊的 PHP 版本？該版本是否可從網路存取？ Synology 明確區分了這兩個問題：DSM 系統自帶一個作業系統使用的內部 PHP 元件，Synology 指出該元件沒有外部可存取的模組，因此不存在暴露的攻擊面。 Synology 認為該組件的風險極低，並且計劃在後續的 DSM 版本中發布補丁，以避免漏洞掃描將其標記為漏洞。

對 PHP2Shell 而言，重要的軟體包是那些為 Web 提供 PHP 服務的軟體包。 Synology 列出了 Calendar、IDrive、Joomla、KodExplorer、MailStation、MediaWiki、phpMyAdmin、vtigerCRM、Web Station 和 WordPress。如果您安裝了其中任何一款軟體包並且可以訪問，那麼您的 PHP2Shell 就在其適用範圍內。

直接檢查版本，不要依賴控制台。在套件中心，已安裝的 PHP 軟體包會在圖示上顯示版本，更新通知會列出目標建置版本。也可以從命令列直接查詢執行時間環境：

# Synology PHP 套件（請依照您執行的版本調整路徑）/volume1/@appstore/PHP8.2/usr/local/bin/php -v # 容器化網站 docker exec php -v

堅持的理由 php -v 對 PHP2Shell 進行審計時，你會發現其他所有訊號都是虛假的。建置輸出可能顯示成功，但實際上卻重複使用了快取層；儀表板可能顯示某個套件是最新的，但實際運行的 worker 卻不是；HTTP 回應頭甚至可能在你看到之前就被 CDN 移除。我們六個站點中有兩個，它們的管理介面顯示運行狀況良好，但實際上它們仍在運行未打補丁的解釋器。

四步完成 Synology 上的 PHP2Shell 補丁

對於運行在 DSM 上的 Web Station 站點，整個 PHP2Shell 修復程式只需透過套件中心更新即可。 Synology 為 DSM 7.4、7.3 和 7.2 發布了 PHP 安全性更新，PHP 軟體包更新後，其依賴軟體包會自動重啟，從而解決問題。 Mail Station 是已知的例外情況，需要手動更新。

上面的截圖來自我們自己的一台機器，時間是 PHP2Shell 發布安全公告後的第二天早上。請注意，「新增功能」面板直接顯示了上游版本號，因此您可以直接將 Synology 建置後綴與對應的 PHP 版本進行匹配，無需猜測。 Synology Calendar 也出現在同一個更新清單中，版本號碼為 3.0.4-21435，這與安全公告中要求的版本完全一致。

對於 Web Station 使用者來說，PHP2Shell 的一個值得注意的陷阱是：一台 DSM 機器可以同時安裝多個 PHP 分支，每個虛擬主機都會綁定到一個設定檔。更新預設設定檔對綁定到其他分支的網站無效。首先列出所有設定文件，更新它們，然後檢查 Web 服務下每個網站的綁定情況。

哪些DSM套餐會受到影響？

PHP2Shell 中 Synology 的宣告比 panic 所暗示的範圍要窄。只有執行某些特定 PHP 依賴軟體套件的系統才會受到影響，而 Synology Drive 明確不在其中。 IDrive 在清單中，但它是第三方軟體。

• 網路平台優先。 Web Station、WordPress、Joomla、MediaWiki、vtigerCRM、KodExplorer 和 phpMyAdmin。這些軟體為所有能夠存取它們的人提供 PHP 服務。
• 郵件和日曆。 Mail Station 需要在 PHP 套件更新後手動更新。 Synology Calendar 的固定版本為 3.0.4-21435。
• DSM內部組件。 存在但無法從外部訪問，補丁推遲到以後的 DSM 版本中發布，Synology 將風險評為最小。
• 容器不在承保範圍內。 容器管理器內部的 PHP 執行環境需要您自行修補。任何軟體包更新都不會影響它，而這正是 NAS 用戶誤以為問題已解決，但實際上並非最常見的原因。

如果您仍在使用低於 7.2 的 DSM 版本，Synology 建議您暫時停用受影響的軟體包，直到有修補程式版本可用。儘管 DSM 7.2 確實收到了這些 PHP 更新，但聲明中仍將其標記為已停止維護。

PHP2Shell 的一個棘手問題是 PHP 7.3 及更早版本。 Synology 不會修復 7.3 版本，因為該分支已停止維護，上游也未發布任何針對 7.3 及更早版本的修補程式。 Linux 發行版為一些舊版本提供了向後移植，但 Synology PHP 套件並非發行版軟體套件。如果網站需要 7.3 或 5.6 版本才能運行，則不會有修補程式發布，合理的選擇是將網站遷移到受支援的分支、將其置於 Web 應用防火牆 (WAF) 之後，或將其從公共互聯網上移除。

容器網站擁有者如何處理 PHP2Shell

我們的六個網站中有五個使用 Docker 而非 Web Station 來運行 WordPress，而這正是 PHP2Shell 發揮作用的地方，因為套件中心對此無能為力。運行時環境取決於鏡像的內容，而重建鏡像與更新鏡像並不相同。

我們遇到的第一個 PHP2Shell 故障，也是最有可能讓其他人遇到的故障，是自訂鏡像的重建會重複使用快取的基礎層。未固定的 從 標籤並不代表版本最新。我們的一個映像在四天前重建過，但仍然包含 2025 年 7 月的 PHP 版本，安全修補程式已經過時一年多了，因為沒有任何機制強制 Docker 重新拉取基礎映像。

錯誤：靜默地重複使用本機快取的基礎層 docker build -t mysite . 正確：始終重新拉取基礎映像 docker build --pull -t mysite .no 然後只啟動您需要的服務，而不啟動休眠的同級服務 docker compose up -dno-deps wordcpress-deps wordccker 最後

第二次 PHP2Shell 失敗更棘手，因為它報告成功。透過管道傳輸建構輸出 尾巴 這會隱藏建置失敗，因為管道的退出程式碼屬於其中的最後一個命令。 設定 -e 永遠不會觸發。然後，compose 步驟會從舊鏡像重新建立容器，列印“已啟動”，然後你就會得到一個看起來像是新部署的、但實際上沒有打補丁的網站。單獨檢查建置結果，並進行驗證。 php -v 然後。

兩點小提示。在重建鏡像之前，請先給舊鏡像打上標籤，因為鏡像會保留其標籤，從而提供一個比快照便宜得多的免費回滾點。另外，不要指望鏡像升級就能更新應用程式：官方 WordPress 鏡像入口點僅在文件根目錄為空時才會複製核心文件，因此在新鏡像上重新建立容器不會改變現有安裝的版本。我們在正式環境部署之前已在測試環境中驗證過這一點，WordPress 版本並未變更。

為什麼禁用 session.upload_progress 只能覆蓋一半

針對無法打補丁的機器，目前流傳的 PHP2Shell 緩解措施是設定 session.upload_progress.enabled = 0在 DSM 系統中，該設定位於 Web Station 的「腳本語言設定」下的 PHP 配置的「核心」標籤中。這樣做是值得的。但這並非一個徹底的解決方案，而且這種差距仍然很重要。

會話上傳進度路徑只是其中一種攻擊途徑。記憶體外洩變體是透過普通的多部分請求處理實現的，完全不需要會話功能，因此關閉該功能後，這條途徑仍然暢通。 PHP 專案已明確表示，目前沒有完全的緩解措施，更新是唯一安全的解決方案。 Imunify360 報告稱，目前沒有任何規則可以阻止 CVE-2026-109618 的記憶體溢位攻擊路徑，而 Elastic 指出，上傳進度設定可以關閉已確認的會話路徑，但並非所有變體都能被利用。

你還會看到 記憶體限制 = -1 基於記憶體不足導致漏洞發生的邏輯，有人建議這麼做。但這並非勝利，而是一種權衡。在公共 Web 伺服器上移除記憶體限制，只會將一種故障模式替換為另一種；而在採用共享記憶體預算的 NAS 裝置上，則會導致工作執行緒耗盡整台機器的記憶體。

邊緣過濾是真正發揮作用的 PHP2Shell 層，因為它能夠偵測到已解密的流量，而你的路由器卻無法做到。 Cloudflare 已為 PHP2Shell 部署了託管規則保護，AWS 在其 PHP 託管規則組的 2.3 版本中增加了對 CVE-2026-109619 的覆蓋，Azure Front Door 也發布了規則 99006001，該規則默認處於禁用狀態。 GitHub 上有社群版的 Snort 和 Suricata 規則，但截至撰寫本文時，官方的 Snort 和新興威脅規則集尚未發布任何內容，因此 NAS 入侵防禦功能在這裡也無濟於事。而且它也無法讀取 TLS 封包內部的內容。

哪家 NAS 廠商真正發布了修復程式？

這部分關於 PHP2Shell 的資訊應該會影響你的購買決策。 PHP 上游於 10 月 21 日發布。以下是四家主要的消費級和專業級 NAS 廠商在第二天的情況，資訊來自他們自己的公告頁面，而非媒體報道。

小販	諮詢	地位	已發布修復版本
群暉科技	Synology-SA-26:14，2026年10月22日	已解決	是的。所有 PHP 7.4 至 8.4 的分支，以及日曆和郵件站。
QNAP	QSA-26-18，2026年10月22日	定影	不。每一行都寫著「待公佈」。
華碩	傳統 PHP 退役，2026 年 10 月 22 日	退休，而非修補。	否。 PHP 7、7.3、7.4 和 8.1 已從 App Central 移除。
UGREEN	未找到	未知	未找到 UGOS Pro 的相關建議

Synology 在發布安全公告的同一天發布了完整的 PHP2Shell 版本表，並將該安全性公告標記為「已解決」。 DSM 用戶閱讀此公告後，當天下午即可採取行動：打開套件中心，點擊“更新”，然後進行驗證。這就是完整的修復流程，也正因如此，我們的 Web Station 伺服器才能在幾分鐘內而非幾天內完成修復。

QNAP 在同一天發布了公告，列出了一系列受影響的產品，包括 QTS 6.1.0、QTS 5.2.11 及更早版本、QuTS hero h6.1.0、h6.0.x 和 h5.2.11 及更早版本、QuTScloud c5.2.9 及更早版本、Note，所有產品的狀態均顯示為“正在修復”，但未提供修復版本。由於 PHP 運行時是 QTS Web 元件的一部分，因此沒有單獨的軟體包可供更新，修復工作只能透過韌體更新來完成。

目前，QNAP 為 PHP2Shell 受害者提供了一系列緩解措施，值得仔細閱讀，因為它要求用戶採取以下行動：停用路由器連接埠轉送和 UPnP，取消發布 myQNAPcloud 服務，將遠端存取置於 VPN 之後，將管理連接埠限制在受信任的子網內，停止執行不需要的基於網路的應用程式，禁用不使用的網路跡象，禁用不使用的 Web Center 是否存在。對於未打補丁的設備來說，這些建議非常合理。但對於任何託管公共網站的用戶來說，這也意味著需要關閉網站。

ASUSTOR 採取了第三種方法。其於 10 月 22 日發布的題為「舊版 PHP 停用公告」的通知，立即從 App Central 中移除 PHP 7、PHP 7.3、PHP 7.4 和 PHP 8.1，建議用戶備份重要數據，並告知用戶今後僅使用 PHP 8.3 或 8.4。此舉的理由合情合理，因為上游僅對 8.2 及更高版本進行補丁修復。對於運行舊版 PHP 應用程式的用戶而言，這意味著運行時環境將從應用程式商店中消失，而不是修復。 ASUSTOR 也並未說明已發布修復後的 8.3 或 8.4 版本。值得注意的是，Synology 發布了修復後的 7.4 版本 7.4.33-0131，而 ASUSTOR 要求遷移的用戶群正是這些舊版用戶。

對於 UGREEN，我們完全找不到任何關於 UGOS Pro 的 PHP2Shell 安全公告。沒有公開聲明並不能證明產品存在漏洞，UGOS Pro 可能根本沒有提供面向 Web 的 PHP 執行環境。但如果您是產品所有者，保持沉默並不能讓您採取任何行動，這本身就是一種風險。

這一切都不能證明 Synology 是完美的。它無法修復 PHP 7.3 的問題，它將 DSM 7.2 標記為生命週期結束，而且它本身的內部 PHP 元件仍然處於規劃階段而非實際修復階段。但重點遠比品牌之爭更具體、更有意義：在 PHP 引擎中發現預授權遠端程式碼執行漏洞的當天，一家廠商在套件中心提供了一個按鈕即可修復漏洞，而其他廠商則讓用戶陷入了漫長的等待。

哪裡可以找到更多官方資源

撰寫本文時，PHP2Shell 發布僅兩天，情況仍在變化，因此請參考原始資料而非摘要。目前沒有任何廠商發布官方影片教程，所以以下列表僅供參考，並非操作指南。

• Synology-SA-26:14 這是權威的版本表。在打補丁之前請再次檢查，因為安全公告會不時更新。
• Synology PSIRT聲明 列出受影響的包裹，並解釋 DSM 內部組件和郵件站異常。
• 上游 GitHub 公告 GHSA-w8hw-w9fx-j79w 和 GHSA-6wmf-4rv5-p3rp 連結到 Synology 公告，描述的是引擎行為，而不是供應商的打包方式。
• QNAP QSA-26-18 如果您執行 QTS 或 QuTS hero，修復後的韌體版本資訊將顯示在此處。請關注此頁面，而不是新聞文章。
• 您自己的套件中心才是已安裝軟體的最終權威來源。系統提示會告訴您目標版本，磁貼會告訴您實際安裝了哪些軟體，僅此而已。 php -v 告訴你正在運行什麼程式。

有關在 Synology 虛擬機器上運行公共網站的背景信息，請參閱我們的演練。 在 VDSM 虛擬機器之間遷移 Docker 堆疊 涵蓋了使此次緊急情況得以應對的快照和回滾習慣。

PHP2Shell 的限制與安全注意事項

在 DSM 上修補 PHP2Shell 很簡單，但在其他地方則不然，因此在宣布工作完成之前，有必要明確指出一些限制。

PHP2Shell 軟體包更新並非網站審計。更新 PHP 會立即修復漏洞，但如果該伺服器在 10 月 20 日至 22 日期間可以從互聯網訪問，則意味著在漏洞利用程式公開期間，該伺服器一直處於可訪問狀態。請檢查日誌中是否有異常的 POST 請求量，查找出現在可寫入目錄中的文件，並輪換 PHP 工作進程可能持有的任何憑證。鑑於記憶體洩漏漏洞的存在，輪換憑證是合理的預防措施，而非杞人憂天。

PHP2Shell 驗證必須針對正在執行的解譯器。在這一輪測試中，儀錶板、建置日誌和回應頭都至少出現過一次驗證失敗的情況。 CDN 可能會移除包含版本資訊的回應頭，建置過程可能會在重複使用快取層的情況下報告成功，軟體包資訊區塊可能會在舊工作進程仍在執行時顯示目前版本。 php -v 請求處理程序內部會解決它。

容器不受任何廠商 PHP2Shell 安全建議的保護。這一點需要一再強調，因為這是 NAS 上最常見的安全迷思。如果您的網站運行在容器管理器中，即使套件中心顯示所有元件都是最新的，也無法保證您的網站安全。任何捆綁了自身運行時的第三方應用程式也同樣如此。

配置緩解措施的設計初衷就是為了緩解部分問題。停用會話上傳進度有所幫助，取消記憶體限制會引入另一種風險，而路由器的入侵防禦功能無法檢查終止於其他地方的 TLS 流量。請將所有這些措施視為爭取時間，以便您可以安排真正的補丁程序，而不是替代補丁程序。

已停止維護的執行時間環境完全沒有 PHP2Shell 路徑。 PHP 7.3 及更早版本既沒有從上游獲得任何更新，也沒有從 Synology 獲得任何更新。如果一個網站確實需要一個不支援的分支，那麼擺在你面前的選擇只有遷移、隔離或從公共網路上退出。沒有第四個選擇，假裝有其他選擇只會讓一個遺留網站成為訪問同一伺服器上所有其他網站的入口。

最後，請密切關注公告而非新聞報導。 Synology 已將 SA-26:14 標記為已解決，並在發布後六分鐘內對其進行了一次修訂。 QNAP 表示，QSA-26-18 將在修復版本發布後進行更新。這兩個頁面都會發生變化，本文中的版本號為 2026 年 10 月 22 日發布的版本。

參考

• Synology-SA-26:14 PHP2Shell 安全公告發布日期：2026 年 10 月 22 日，狀態：已解決，修復版本適用於 PHP 7.4 至 8.4。
• Synology 關於 PHP2Shell 漏洞的聲明PSIRT 說明列出了受影響的軟體包和 DSM 覆蓋範圍。
• QNAP QSA-26-18狀態：修復中，受影響產品及其修復版本待公佈。
• ASUSTOR Legacy PHP 停用公告從 App Central 移除 PHP 7、7.3、7.4 和 8.1。
• 幫助 Net Security 了解上游 PHP2Shell 版本發布情況涵蓋 PHP 8.5.12、8.4.27、8.3.36 和 8.2.35 以及舊分支的僅原始碼向後移植版本。

經常問的問題