PHP 兩項嚴重漏洞最高風險評分達 9.2 分，攻擊者可能在未經身分驗證的情況下遠端執行程式碼。從 WordPress 到企業管理系統都可能受到影響，資安署已啟動通報聯防，呼籲機關、學校與企業儘速確認版本、完成修補，並檢查是否已有異常活動。
網站遭駭，未必是因為員工點了釣魚郵件，也不一定是因為密碼遭到竊取。有時候，問題可能出在網站底層使用的程式語言，只要攻擊者找到漏洞，就可能繞過登入程序，直接對遠端伺服器發動攻擊。
2026 年 10 月 21 日，開源伺服器端腳本語言 PHP 緊急發布安全更新，修補兩項嚴重漏洞，編號為 CVE-2026-109618 與 CVE-2026-109619，兩者的 CVSS v4.0 嚴重度評分均為 9.2 分。
這起事件受到全球資安圈高度關注，原因不只是漏洞可能造成遠端程式碼執行（Remote Code Execution，RCE），更在於 PHP 長期廣泛應用於網站、內容管理系統及各類企業應用。若系統使用受影響的 PHP 執行環境，攻擊者就可能利用漏洞，進一步取得伺服器控制權、讀取敏感資料，甚至將入侵行動擴大到其他系統。
臺灣數位發展部資通安全署已發布提醒，並透過資安警訊、國家資安資訊分享與分析中心（N-ISAC）及 TWCERT/CC 等管道通知相關機關與企業儘速應處。這代表這起事件不只是國際資安新聞，更是臺灣各類網站與應用系統必須立即確認的實際風險。
一、為什麼這次漏洞如此嚴重？駭客可能不必登入就能執行程式碼
一般人可能會認為，只要網站有帳號密碼、登入驗證與防火牆，就能有效阻擋外部攻擊。然而，這些防護措施不一定能阻止直接利用底層程式漏洞的攻擊。
PHP 是一種常見的伺服器端程式語言，負責處理網站收到的請求、執行程式邏輯，以及與資料庫或其他服務互動。當 PHP 執行環境本身存在安全漏洞時，即使網站的登入功能正常，也不代表底層系統不會受到攻擊。
此次兩項漏洞的技術成因有所不同，涉及記憶體處理與程式執行過程中的安全問題。研究指出，在特定條件下，攻擊者可能利用相關缺陷造成記憶體資訊洩漏，甚至進一步達成遠端程式碼執行。
所謂「遠端程式碼執行」，就是攻擊者能夠透過網路，讓目標伺服器執行非預期的程式指令。實際能取得哪些權限，仍取決於伺服器設定、執行帳號權限及其他防護措施，但可能造成的後果包括：
- 網站遭到控制：攻擊者可能修改網站內容、植入惡意程式，或建立後續入侵管道。
- 敏感資料外洩：若伺服器能存取客戶資料、會員資訊、訂單紀錄或內部文件，這些資料可能面臨風險。
- 帳號與系統遭進一步利用：攻擊者可能嘗試取得應用程式憑證、資料庫連線資訊或其他存取權限。
- 企業營運受到影響：網站或相關服務可能遭竄改、中斷，甚至成為攻擊其他內部系統的跳板。
需要強調的是，漏洞具備遠端程式碼執行能力，不代表每一台受影響主機都已遭駭，也不代表攻擊者必然能取得最高管理員權限。但只要漏洞可能讓外部攻擊者繞過正常驗證機制，企業就不能以「目前網站還能正常使用」作為安全判斷的依據。
二、為什麼政府網站也可能暫時停止服務？
此次漏洞公開後，部分國家或公共服務機構據報採取預防性措施，暫時停止部分網站或服務，以降低漏洞遭利用的風險。
這類措施反映出一個重要問題：當系統漏洞可能讓攻擊者直接在伺服器執行程式碼，而管理單位又無法立即確認受影響範圍或完成修補時，暫時限制服務可能比繼續暴露在網際網路上更安全。
不過，必須區分「預防性下線」與「已遭入侵」兩件事。網站暫停服務，不等於該網站已經被駭；是否發生入侵，仍須依據日誌、系統跡象及後續調查結果判斷。
從資安管理角度來看，真正的挑戰往往不是知道漏洞存在，而是能否迅速回答以下問題：
- 哪些系統正在使用受影響的 PHP？
- 哪些系統直接暴露在網際網路上？
- 是否能立即更新，或需要先暫時限制對外連線？
- 修補之前，有沒有跡象顯示漏洞已被利用？
如果企業平時沒有完整的資訊資產清冊，也不清楚委外廠商代管哪些網站與應用程式，就可能在漏洞公開後花費大量時間尋找受影響系統，錯失最重要的應變時機。
三、臺灣資安署已啟動通報聯防，點名機關、學校與企業儘速應處
數位發展部資通安全署指出，PHP 安全團隊於 10 月 21 日晚間 10 時（臺灣時間）釋出緊急安全更新，修補 CVE-2026-109618 與 CVE-2026-109619 兩項嚴重漏洞，兩者的 CVSS v4.0 評分均為 9.2 分。攻擊者可能在未經身分驗證的情況下，從外部執行任意程式碼。
資安署掌握情資後，已透過資安警訊、N-ISAC 及 TWCERT/CC 等管道，通知各機關與企業儘速完成應處。
資安署也特別提醒，PHP 不只用於自行開發的網站，也是 WordPress、Drupal、Joomla、Magento 等主要內容管理系統的底層架構。部分軟體即使沒有明確標示使用 PHP，內部仍可能依賴 PHP 運作。
這項提醒對企業尤其重要。許多組織平時只盤點自己知道的網站平台，卻未必掌握網站主機、內部管理介面、舊系統、委外應用程式及相關套件的實際執行環境。若只更新網站應用程式，卻忽略底層 PHP 執行環境，漏洞仍可能存在。
網站使用 WordPress，不代表只要更新 WordPress 就能修補 PHP 漏洞；應用程式更新與 PHP 執行環境更新，是兩項不同的工作。
因此，企業應依 PHP 官方公告及實際系統供應商的修補指引，逐一確認受影響範圍，不能只憑系統名稱或管理介面顯示的版本資訊，就認定風險已經排除。
四、AI 也參與了漏洞研究：問題不只是漏洞存在多久，而是發現與利用的門檻正在改變
這起事件另一個值得關注的焦點，是人工智慧（AI）在漏洞研究過程中扮演的角色。
根據 Wiz Research 公開的研究說明，研究團隊運用 AI 輔助分析 PHP 程式碼、追查記憶體處理問題，並協助研究可能的漏洞利用方式。相關研究指出，部分底層問題可追溯至 PHP 5.4.0，發布時間約在 2012 年，顯示這些程式碼問題可能已存在十多年。
這不應被簡化為「AI 自己找到所有漏洞並完成攻擊」。更準確地說，AI 能協助研究人員分析複雜程式碼、整理可能的錯誤路徑、提出測試方向，以及加速驗證漏洞是否可能形成實際攻擊鏈。最終的漏洞確認、影響評估與研究結論，仍需要專業人員進行驗證。
從防禦角度來看，這項發展有兩個值得企業重視的意義。
第一，長期存在的程式碼問題，可能因分析工具進步而更容易被發現。企業不能只關注最近發布的軟體或新開發的系統，長年運作、很少更新的網站與應用程式，同樣可能存在高風險弱點。
第二，漏洞研究與利用技術的門檻可能持續降低。當 AI 能加快程式碼分析與漏洞驗證，防禦方不能再假設複雜漏洞只會被少數高度專業的攻擊者掌握。對外服務系統的修補速度、監控能力與應變流程，將更加重要。
AI 可以幫助防禦人員更快發現問題，但也可能讓攻擊者更有效率地研究漏洞。企業應關注的不是 AI 是否取代資安專家，而是攻防雙方都可能利用新工具加快行動，因此必須縮短從漏洞公布到完成修補的時間。
五、企業現在該怎麼做？建議優先完成五項工作
面對這類可能導致遠端程式碼執行的重大漏洞，企業不應只寄出一封通知信，或要求 IT 人員「有空再更新」。應將其視為需要追蹤、驗證並留下紀錄的資安事件應處工作。
1. 立即盤點所有 PHP 系統
盤點對外網站、內部管理介面、應用程式伺服器、測試環境、舊系統、委外維運服務，以及其他可能內含 PHP 的軟體。
除了已知的 WordPress、Drupal、Joomla、Magento 等平台，也應確認不易從外部辨識的後端服務與應用程式套件。若系統由雲端服務商或委外廠商管理，應立即要求對方確認是否受影響、修補進度及完成時間。
2. 依官方公告更新 PHP，確認修補真正生效
PHP 官方已發布相關安全更新，包括 PHP 8.5.12、8.4.27、8.3.36 及 8.2.35 等版本。實際應採用的版本，仍應依 PHP 官方公告、系統相容性與供應商修補指引確認。
使用較舊、已停止維護的 PHP 版本時，不能只因為找不到新版就繼續維持原狀。應確認供應商是否提供安全修補，並評估升級、套用經驗證的修補方案，或暫時限制系統對外服務。
另外，部分 Linux 發行版可能將安全修正回補至其維護的套件中，因此不能單憑版本號看起來較舊，就斷定一定未修補；同樣也不能只因為版本號較新，就直接認定安全。應核對實際套件來源及官方修補狀態。
3. 修補後檢查日誌，確認是否曾遭利用
這是許多組織容易忽略的一步。
修補漏洞可以降低未來遭利用的風險，但無法自動清除攻擊者可能在修補前植入的惡意程式，也不能讓已遭竊取的憑證自動失效。
企業應檢視網站與伺服器日誌、異常存取紀錄、可疑程式執行、陌生檔案、異常帳號、對外連線及其他可疑活動。如果發現異常跡象，應進一步確認相關帳號與憑證安全性，必要時進行數位鑑識、隔離受影響主機及更換憑證。
若沒有發現異常，也應保留檢查紀錄與判斷依據，而不是將「目前沒有看到問題」直接等同於「從未遭到入侵」。
4. 不要把防火牆或 WAF 當成修補的替代品
Web 應用程式防火牆（WAF）及其他網路防護機制，可能有助於降低特定攻擊流量的風險，但不能取代 PHP 官方修補。
企業應優先完成正式更新；在修補尚未完成的過渡期間，才依實際架構評估是否需要限制外部存取、暫時停用高風險功能或採取其他緩解措施。若無法立即修補且系統暴露於網際網路，應由系統負責人與資安團隊評估是否需要暫時下線或隔離。
5. 將漏洞處理納入管理流程，明確追蹤責任與期限
企業應記錄受影響資產、風險等級、修補負責人、預計完成時間、驗證結果，以及是否需要進一步調查。對於由外部廠商管理的系統，應要求廠商提供具體處理結果，而非只回覆「已處理」或「目前正常」。
重大漏洞的處理不能只靠個別 IT 人員自行判斷。管理階層也應掌握哪些關鍵服務仍未修補、延遲原因是什麼，以及未修補期間採取了哪些風險控制措施。
六、真正的風險不只在漏洞，而在企業能不能及時掌握自己的系統
從資安治理角度來看，PHP2Shell 事件再次凸顯一個基本問題：企業是否清楚知道自己的資訊系統由哪些技術組成，以及這些系統由誰維護？
當重大漏洞公開時，擁有完整資產清冊、明確委外管理機制、持續監控及漏洞應變流程的組織，通常更容易迅速找出受影響系統並完成處理。反之，如果網站、主機、套件與委外服務分散管理，連哪些系統正在執行 PHP 都無法確認，就可能讓已知漏洞持續暴露。
這也是為什麼資安工作不能只停留在購買防火牆、部署偵測工具或定期進行弱點掃描。工具可以協助發現風險，但企業仍需要明確的責任分工、資產盤點、修補時限、例外管理及事件調查機制，才能把警訊轉化成實際防護。
對企業而言，這次事件最重要的提醒是：漏洞公開後，第一步是確認並修補；第二步是查明修補前是否已遭利用；第三步則是確保所有系統與委外服務都納入持續管理。
不要等到網站被竄改、客戶資料外洩或服務中斷，才開始追查自己使用了哪些 PHP 系統。面對可能讓攻擊者不必登入就能執行程式碼的重大漏洞，及早盤點、迅速修補，並以日誌與調查結果驗證安全狀態，才是降低實際損害的關鍵。
參考資料
- PHP 官方網站與安全更新公告：https://www.php.net/
- Wiz Research，PHP2Shell 漏洞研究：https://www.wiz.io/blog/php2shell-php-rce
- European Union Agency for Cybersecurity（ENISA），PHP 重大漏洞聯合聲明：https://www.enisa.europa.eu/news/joint-statement-on-critical-php-vulnerabilities
- Cloudflare，PHP 漏洞與 WAF 防護說明：https://blog.cloudflare.com/php-vulnerabilities-waf-protection
- NCSC-NL，PHP2Shell 漏洞應處資訊：https://github.com/NCSC-NL/php2shell
- 數位發展部資通安全署，https://moda.gov.tw/ACS/press/news/press/21134(開發程式語言 PHP 釋出緊急安全更新 資安署呼籲儘速完成修補)。
