2026 年 10 月下旬，一組代號「PHP2Shell」的 PHP 重大漏洞讓全球各大網站、企業機房與自架服務繃緊神經。QNAP 隨即發布資安公告 QSA-26-18，對旗下 QTS、QuTS hero 與 QuTScloud 釋出修補韌體。CyberQ 實測安裝，並分析這組漏洞的來龍去脈，說明為什麼 NAS 受到的衝擊比一般網站更難處理，並在一台 QuTS hero 機器上實測完整的升級與驗證流程，最後也給大家一份可以直接照做的自家 NAS 防護教戰守則。
一、懶人包：PHP2Shell 與 QSA-26-18
PHP2Shell 指的是上游 PHP 的兩個漏洞 CVE-2026-109618 與 CVE-2026-109619，CVSS v4.0 同為 9.2，屬於遠端程式碼執行等級。兩者的成因都在 PHP 處理請求的底層記憶體管理：
- CVE-2026-109618：請求在建立初期發生記憶體不足時，內部資料只建立到一半，而清理程式卻信任這份半成品，導致記憶體破壞。
- CVE-2026-109619：請求結束後，內部狀態仍指向已釋放的請求記憶體，同一個 PHP worker 處理的下一個請求可能沿用這份殘留資料。
上游 PHP 於十月二十一日發布修補版本 8.5.12、8.4.27、8.3.36 與 8.2.35。凡是對外提供網頁請求的 PHP 都在影響範圍內，包含 PHP-FPM、Apache mod_php、php-cgi 等執行模式。美國 CISA 已於十月二十六日將 CVE-2026-109618 列入「已知遭利用漏洞」清單，資安業者也在修補釋出前後觀察到實際的攻擊嘗試。
QNAP 的 QSA-26-18 公告列出各作業系統分支對應的修補版本，重點整理如下：
| 受影響分支 | 修補版本 |
|---|---|
| QuTS hero h5.3.x | QuTS hero h6.0.2.3656 build 20261023 |
| QTS 6.1.0 | QTS 6.1.0.3656 build 20261023 |
| QTS 5.2.11 及更早 | QTS 5.2.11.3661 build 20261023 |
| QuTS hero h6.1.0 | QuTS hero h6.1.0.3656 build 20261023 |
| QuTS hero h6.0.x | QuTS hero h6.0.2.3656 build 20261023 |
| QuTS hero h5.2.11 及更早 | QuTS hero h5.2.11.3661 build 20261023 |
| QuTScloud c5.2.9 及更早 | QuTScloud c5.2.9.3661 build 20261023 |
受影響的應用程式另需個別更新，例如 Notes Station 3 需升到 3.9.15、ARM32 機型的 QVR Surveillance 需升到 3.0.3.1756。Container Station 容器內或第三方套件所使用的 PHP，要向各自的提供者取得修補後的映像，韌體更新不會一併處理。
二、為什麼 NAS 比一般網站更棘手
一般網站管理員只要用套件管理工具把 PHP 升到修補版本就結束了。NAS 的情況不同，QNAP 的管理介面本身就是一套由 PHP-FPM 驅動的網頁應用，而這個 PHP 直接內建在韌體裡。
這帶來兩個後果。第一，使用者無法單獨更新 PHP，只能等原廠把修補後的 PHP 包進新韌體，再整台升級。第二，管理介面本身就落在攻擊面內，所以 PHP2Shell 對 NAS 的意義，不只是某個網站服務受影響，而是管理這台 NAS 的入口網頁如果沒有防護直接對外，會被影響到。
CyberQ 在實測機上確認，QuTS hero 韌體內建的 PHP-FPM 版本與韌體建置日期完全綁在一起，升級前是 PHP 8.5.2、建置日期與韌體相同，只有換上修補韌體，PHP 才會跟著換成 8.5.12。這正是 NAS 修補無法「只動 PHP」的根本原因。
三、實測：升級前後完整驗證
本次實測在兩台 QuTS hero 機器（以下稱主機 A 與主機 B）上進行，升級程序完全相同。為了客觀，CyberQ 先在不接觸 NAS 的隔離環境做了修補點差異佐證，再對兩台實機做升級。
升級前基線
升級前，兩台的韌體都停在 6.1.0 build 20261007，韌體內建的 php-fpm 都是 PHP 8.5.2（PHP_VERSION_ID 80502），落在修補版本 8.5.12 之前，屬於未修補狀態。
隔離實驗室的修補點差異佐證
為了在不碰實機、也不執行任何攻擊程式的前提下確認差異，我們在一台 Linux 主機的容器環境裡，並排執行上游官方的兩個 PHP 映像，只比對版本層級：
升級流程
升級採 QNAP 官方支援的方式進行，先確認修補映像與機型相符（檔名、型號一致），並確認目標 build 20261023 比現行 20261007 新，屬於升級而非降級。這一步很關鍵，QuTS hero 的韌體更新內建 CRA 降級防護，若誤用了版本號較低的映像（例如把 6.1.0 分支的機器刷成 6.0.2 的修補版），系統會以安全為由擋下，強行繞過有設定不相容的風險。確認無誤後，透過控制台的「韌體更新 > 手動更新」套用修補映像，系統完成刷寫後自動重開。
升級後驗證
重開後，我們以作業系統層級的權威來源逐項核對，而不是只看管理介面的提示：
驗證重點有三個：第一，/etc/os-release 的版本字串確實變成 build 20261023，而不是只看 Live Update 顯示「無更新」（原廠也特別提醒，Live Update 顯示無更新不代表已修補）。第二，韌體內建的 php-fpm 二進位版本確實從 8.5.2 換成 8.5.12，建置日期同步更新。第三，PHP_VERSION_ID 回報 80512，大於或等於 80512 即代表已含修補。兩台的資料儲存池在升級前後都維持 ONLINE，資料與服務正常。
四、如何防護自家 NAS：教戰守則
把這次事件當成一次演練，以下是可以直接照做的清單，從最重要的往下排。
1. 立刻升到修補韌體，並以版本號與 build date 確認
對照 QSA-26-18 的版本表，找出自己分支對應的修補版。重點是認 build 20261023 這個建置編號與完整版本號，不要只看前面的「6.1.0」或「5.2.11」，原廠明說光看大版本不足以判斷是否已修補。升級後請到控制台確認完整版本與建置日期，必要時再從作業系統層級複核。
2. 認清自己分支，不要誤刷成降級
升級前先確認目標映像的版本號不低於現行版本。QuTS hero 內建 CRA 降級防護會擋下版本號較低的刷機，這是保護，不要用強制繞過。若手上只有較舊分支的修補版，應改抓對應自己分支的版本。
3. 把 NAS 移出公開網路的攻擊面
不要把 NAS 直接暴露在網際網路上，關閉路由器上針對 NAS 的連接埠轉發與 UPnP，並在 myQNAPcloud 的自動路由器設定裡關閉 UPnP 轉發。遠端存取改走 VPN。這次實測中，我們也盤點了兩台機器對外的曝險：其中一台因為自架服務而有少數特定連接埠從外部轉入，但已用防火牆政策限制來源地區與來源網段，且管理介面所在的連接埠並未對外轉發；另一台則完全沒有對外轉入。關鍵在於你要「明確知道哪些連接埠會到達 NAS」，而不是憑印象。
4. 收斂不需要的對外服務
盤點 myQNAPcloud Link 與 DDNS 是否真的需要；不需要就關閉，減少可被觸及的中繼管道。停用使用者沒在用的服務與應用程式。
5. 停用不需要的內建 Web Server
若沒有在用 QNAP 內建的 Web Server，請到控制台把它停用。要特別注意：停用 Web Server 並不能保護 NAS 的管理介面本身，因為管理介面另有自己的 PHP-FPM，這一點原廠也特別澄清過。
6. 用防火牆限制管理介面來源
以 QuFirewall 或上游防火牆，把管理埠限制在信任網段。這次實測的兩台機器 QuFirewall 規則都是空的，等於沒有在這一層設防,是值得補強的環節。順帶一提，若管理介面仍在明文 HTTP 埠，建議改走 HTTPS 並強制 SSL。
7. 更新受影響的應用程式與容器
韌體升完後，到 App Center 更新受 QSA-26-18 影響的應用程式（如 Notes Station 3、QVR Surveillance）。Container Station 容器內或第三方套件使用的 PHP，要另外向提供者取得修補映像，韌體不會幫你處理。
8. 升級前備份，升級後複查
升級前把資料備份到獨立位置、安排停機時間、檢查儲存狀態並接上不斷電系統。升級後複查系統日誌、儲存池與各項服務是否正常。
CyberQ 指出，最後一個觀念要記牢，關閉曝險、限制來源這些措施都只是「降低風險」，不是修補。真正堵住 PHP2Shell 的，只有把韌體升到含修補 PHP 的版本。緩解措施是爭取時間，升級才是終點。
