從執行環境漏洞、軟體供應鏈遭駭到 AI Agent 治理：當攻擊全面自動化，企業防禦邊界該如何調整？
企業防禦的重點，不只在修補漏洞，也在限制一個系統失守後能動用的權限。本文從 PHP2Shell、軟體供應鏈與雲端憑證事件，整理製造業導入 AI Agent 時需要建立的查詢、核准與執行邊界。
在製造業現場，最讓 IT 與維運團隊頭痛的，往往不是三天兩頭當機的系統，而是那些穩定跑了十幾年、誰也不敢輕易更動的陳年老系統。
工廠內網常見一套用來查設備稼動率或維修紀錄的 Web 看板。它可能十年前由外部系統整合商（SI）交付，底層包著特定版本的 PHP，中間陸續串接了 MES、ERP 或產線資料庫的連線帳密。原始開發廠商或人員早已不在，系統卻長年穩定。只要產線沒停、資料還查得到，維運團隊很難有理由冒著停機風險，主動升級這類舊系統的底層元件。
類似的妥協也普遍存在於雲端與開發環境。為了讓 CI/CD 部署與跨系統整合跑得順暢，團隊在各平台建立了 Service Account、API Key 與 OAuth 授權；遇到緊急修復時，甚至會臨時放寬發布審核規則。專案驗收或問題解決後，若未定期收回不再需要的權限，或讓臨時放寬的規則在期限到了之後自動恢復，這些具備高權限的長期憑證與例外設定，往往就此沉積在系統深處。
表面上一切運作正常，底層的信任關係卻早已產生漏洞。
2026 年 10 月下旬，幾起接連爆發的重大資安事件，將這些長年累積的隱性風險直接攤在陽光下：
10 月 20 日，PHP 官方罕見提前預告重大更新；隔日，兩項被稱為「PHP2Shell」的核心漏洞正式公開（CVE-2026-109618 與 CVE-2026-109619，CVSS v4.0 評分均達 9.2）。PHP 官方已在 Apache mod_php 示範一條可於應用程式碼執行前觸發、讓未登入的外部人士以網站服務帳號執行程式的攻擊路徑。其他部署模式的利用條件不同，仍須依官方公告評估。
同一天，開源 AI 工具 LiteLLM 證實其正式發布的套件遭植入惡意後門，經由官方 PyPI 與容器映像檔庫向外擴散；雲端平台 Railway 則揭露內部系統遭入侵，部分客戶儲存於環境變數中的敏感金鑰面臨解密外洩風險。
往前追溯，LiteLLM 的破口始於五月一組「忘了撤銷」的主金鑰；今年三月，Aqua Security 的開源安全工具 Trivy 也發生過類似事件——憑證輪替作業未在第一時間澈底失效，給了攻擊者延續存取權限的空窗期。
這並不代表防火牆、網站防護與漏洞掃描已經失去價值；它們依然是企業安全的基本功。真正的改變是，風險可能在應用程式運作之前就出現，官方發布流程也可能被攻擊者利用，甚至有人已經能靠 AI 在短短數小時內擴大入侵。如果企業仍停留在「等漏洞公告 → 確認受影響系統 → 等待維護窗口」的節奏，就很難跟上新的威脅速度。
即使單一節點失守，企業更該追問的是：攻擊者能順著系統留下的既有權限，一路走到哪裡？
PHP2Shell：為何風險可能早於應用程式的登入驗證？
PHP2Shell 之所以引發資安架構師的高度戒備，部分風險在企業自行設計的登入與資料檢查機制啟動之前就可能發生。網站入口的安全防護仍可協助阻擋異常流量，但無法取代底層系統更新。
應用程式自行實作的登入驗證、存取控管與輸入過濾，通常要等應用程式本體（如 index.php）開始執行後才會啟動；位於反向代理或網站入口的防護則可能更早介入。但在傳統 Web 伺服器架構中，外部請求會先經過網站伺服器與 PHP 底層的資料處理，接著應用程式本身才開始運作。換句話說，漏洞可能藏在使用者看不見、開發團隊也很少主動更動的系統基礎裡。
本次修補的兩項漏洞，問題正是出在 PHP 底層在接收及結束請求時，未能妥善處理部分記憶體資料：
- CVE-2026-109618（記憶體不足時的處理漏洞）：當攻擊者送入刻意設計、結構複雜的表單資料，可能讓 PHP 在處理過程中耗盡記憶體。系統此時若錯誤使用尚未準備完成的資料，就可能引發更嚴重的安全問題。在特定條件下，風險不只是網站暫時中斷，還可能讓未登入的外部人士執行惡意程式。
- CVE-2026-109619（工作行程重用造成的跨請求風險）：在部分持續運作的 PHP 環境中，前一筆請求結束後，原本應清除的資訊可能仍留在系統裡。如果下一筆請求由相同的處理程序接手，就可能錯誤使用舊資料，造成敏感資訊外洩，甚至被利用來執行惡意程式。問題不在網站連線維持多久，而在處理程序重複使用的方式。PHP 官方已確認部分 Apache 與 PHP-FPM 環境存在相關風險；每筆請求都使用全新處理程序的傳統模式，則不涉及這項跨請求重用的路徑。
換句話說，應用程式碼就算一行沒改、寫得再嚴謹，只要底層 Runtime 符合觸發條件，攻擊者就可能取得網站服務本身的執行權限。若這項服務還能讀取重要資料或操作其他系統，損害便可能持續擴大。因此，讓每個服務只擁有工作所需的最低權限，是降低風險的重要一環。
PHP 官方隨後釋出 8.2.35、8.3.36、8.4.27 與 8.5.12 等修補版本，並強調升級是根治漏洞的唯一途徑。但真正困難的，往往是產線裡仍在使用多年的舊系統。PHP 8.1 及更早版本已停止例行安全維護，雖然這次事件有部分特別修補與長期支援方案，但不一定適用每個環境。企業應由維運團隊核對供應商的安全公告與修補紀錄，不能只憑畫面顯示的版本號判定是否安全；若無法取得修補，就需要加強隔離並安排升級。
在企業內部，PHP 實體可能散落在獨立虛擬機、包在微服務容器映像檔裡，或直接內嵌在第三方設備管理軟體中。主機作業系統更新了，容器裡的 Runtime 未必更新；重新部署應用程式，也不代表套裝軟體隨附的組件同步完成了升級。
更棘手的是製造現場的相容性包袱。
一套跑了多年的看板，往往依賴特定版本的 PHP 擴充套件或舊版資料庫驅動。工程師知道該升級，卻沒人敢保證重啟 Web 服務後機台通訊不會中斷。資安團隊看著 CVSS 9.2 焦頭爛額，現場主管則堅持產線不能承擔停機風險。
這時不能只看漏洞分數決定停機順序，而要先找出真正暴露在風險中的系統。企業可以先收窄存取範圍、減少不必要的帳號權限，並利用網站前端防護阻擋異常大量或結構複雜的請求。對需要長期運作的服務，也可依官方指引調整工作程序的重用方式與部分功能設定，降低被利用的機會。這些都是爭取修補時間的暫時措施，並非永久解方。對無法立即更新的老系統，更需要網路隔離、持續監測，以及不影響產線的測試與維護計畫。
暫時的限制措施能替工程團隊爭取驗證時間，但無法取代底層修補；這項長年存在的營運拉鋸，考驗的正是企業在安全與可用性之間的權衡能力。
從 PTC 與 Oracle 的公告，看真實相依性與 CMDB 的斷層
PHP2Shell 公布後，工業軟體大廠 PTC 與 Oracle 相繼啟動影響評估。
PTC 在 Trust Center 建立應對專區，確認 ThingWorx、Windchill PLM、FlexPLM 等核心產品未受波及，並針對 PTC Cloud 執行掃描與元件更新或移除；Oracle 則於 10 月 25 日發布 Security Alert，點名 Oracle Communications 產品線中的 Diameter Signaling Router 與 EAGLE Application Processor 等電信級系統存在相依性風險，隨即釋出修補指引。
原廠的即時公告展現了成熟團隊的負責態度，但當這些指引回到終端企業時，相依性追蹤往往出現嚴重斷層。
一套上線多年的管理系統，往往經過代理商與系統整合商的多輪客製化，甚至隨附了未記錄在標準規格裡的輕量 Web 工具。原廠評估「標準產品不受影響」，現場運行的客製化環境卻未必安全。
這也是許多企業即使導入了組態管理資料庫（CMDB），重大資安事件當下依然一片混亂的原因。如果 CMDB 只記錄了「伺服器 IP、主機名稱、負責部門」，就難以反映實際部署的是哪一版容器映像檔、裡面包含哪些版本的軟體元件、第三方軟體私下內嵌的 Runtime，以及這套服務到底在內網持有哪些資料庫連線權限。
靜態的軟體物料清單（SBOM）如果只在驗收時建檔，後續沒有與 CI/CD 及動態部署連動，就只是抽屜裡的過期文件。如果企業每次遇到重大 CVE，都得花上兩三天跨部門翻合約、查程式碼才能確認受影響範圍，這種防禦空窗期，就可能讓自動化攻擊有機會在內網擴大影響。
LiteLLM 與 Trivy 的教訓：金鑰「在 GitHub 刪除」不等於「憑證失效」
PHP2Shell 點出了執行環境的盲區，LiteLLM 事件則暴露出軟體供應鏈治理中最致命的疏忽：我們以為「從官方管道下載」就代表安全，卻忘了發布管線背後的權限同樣會遭到劫持。
10 月 21 日，LiteLLM 的 v1.107.0 遭植入惡意後門，並順利推播至官方 PyPI 與容器映像檔庫。開發者即使從官方管道下載，也可能在不知情下安裝受污染的版本。這提醒我們：正式發布與數位簽章可以協助辨識來源，卻不能保證從原始碼到產品上架的每一步都沒有遭人動手腳。
事後調查揭露了一個關鍵細節：GitHub 上的官方 v1.107.0 原始碼標籤未包含此次惡意檔案，受污染的正式安裝包與容器映像則來自攻擊者控制的儲存庫。
根據 LiteLLM 於 10 月 23 日公布的調查報告，這起事故源於長達五個月的權限管理疏失：
- 五月的外洩：5 月 27 日，內部設定檔意外提交至公開儲存庫，洩漏了 Agent Platform 的 Master Key。團隊發現後從 Git 歷程清除了檔案，並在內部標記需作廢金鑰。然而，團隊只在程式庫裡刪除紀錄，卻沒有回到發放金鑰的系統將它真正作廢。只要機密金鑰曾出現在公開網站，就應立即視為外洩；即使事後刪掉檔案或修改歷史紀錄，其他人也可能早已複製、轉存或留有備份。
- 十月的橫向擴散：10 月 10 日，攻擊者持這組存活了五個月的主金鑰呼叫 API，取得了綁定在「GitHub 組織擁有者（Org Owner）」身上的 CLI OAuth Token——這是一組未經細粒度劃分、具備組織擁有者層級存取能力的憑證。攻擊者利用它在背景建立隱蔽的 CI 工作流程，取得更多維護人員的帳號憑證，並刪除部分自動發布流程的執行紀錄，試圖掩蓋行蹤；但 GitHub 組織層級的稽核紀錄仍然留存。
- 管線防禦被覆寫：10 月 21 日，攻擊者修改私有 Release Workflow，將原始碼來源指向名稱相似的惡意 Fork。原本阻止未經授權變更的保護機制一度發揮作用，但攻擊者利用高權限帳號解除限制，強行改寫發布流程。企業因此應設定更嚴格的發布規則，讓管理員也不能直接跳過審核，同時限制誰有權修改或停用這些規則。
- 審核機制的妥協：LiteLLM 原本要求發布必須由綁定實體硬體的特殊帳號簽核；但事發那一週，為了加速交付 Bugfix，團隊臨時放寬為「任兩名工程師核准即可發布」。而攻擊者早已取得多組合法帳號憑證，因而順利通過審核。這類臨時放寬的規則應明訂期限，到期自動恢復原有要求；但官方也指出，已取得組織擁有者憑證的攻擊者可能自行變更限制，因此還須限制誰能修改或停用保護規則。
受污染的版本就這樣經由已遭操控的官方發布流程完成打包與上架，推播給全球使用者。
類似的劇本在今年三月的 Trivy 事件中也上演過：團隊在發現憑證受損後啟動輪替，但輪替範圍並不完整，攻擊者仍可透過有效的殘留憑證延續存取，之後改寫其他團隊原本信任的軟體更新來源。這提醒企業：自動化流程引用的第三方工具，應固定使用經過核驗的不可變 commit 或映像 digest，不能只相信可能被重新指向的版本標籤。
這兩起事件給所有團隊敲了一記重重的警鐘：資安處置的結案條件，絕對不是「在 Git 裡清掉檔案」或「工單勾選已處理」。只要被竊取的金鑰仍然能被系統接受，這把鑰匙就隨時可能在數個月後被重新轉動。
同時，它也重新界定了數位簽章的防禦邊界。簽章可以協助確認「由誰發布」，卻無法單獨保證「發布的內容就是原本核准的版本」。企業還需要核對原始碼來源、正式版本與最終交付檔案是否一致，必要時重新製作並比對結果。即使建置環境受到嚴格隔離，只要發布流程本身被改寫，仍可能產出遭掉包的產品。
Railway 事件：內部系統入侵與環境變數中的金鑰風險
同週發生的 Railway 資安事件（官方初步時間線為 10 月 20–22 日 UTC），則把焦點拉回雲原生架構中最普遍的痛點：環境變數（Environment Variables）與系統自動使用的服務帳號與金鑰，也就是非人類身分（Non-Human Identity，NHI）。
根據 Railway 初步調查，攻擊者先取得部分內部系統的存取能力，再利用相關憑證接觸客戶儲存的機密設定，其中一部分可能已遭解密。Railway 評估，至多約 1.85% 的工作空間可能有部分資訊受影響；這不代表該比例內的全部金鑰都已確定外洩。依官方初步調查，攻擊者目標集中於 AI 與平台服務的 API Key。Railway 在 10 月 26 日更新中表示，既有使用者的事件處置已完成；影響範圍與事件細節仍應以其後續公告為準。
這起事件撕下了「機密資料只要在儲存時加密（Encryption-at-Rest）就萬無一失」的迷思：在現代架構中，應用程式運行時需要調用金鑰，解密權限就必然落在某些運算身分手中。 一旦攻擊者透過基礎設施層級的漏洞接管了該身分，儲存加密就無法單獨阻止透過既有解密能力取得資料的攻擊者；加密本身仍然是重要的防護。
Railway 事件帶來一個很重要的提醒：處理外洩金鑰時，要把「停用舊金鑰」與「啟用新金鑰」分開看。已經外洩或疑似外洩的舊金鑰，應立即到服務提供端撤銷，阻止攻擊者繼續使用；Railway 也主動通知供應商協助作廢。至於新金鑰，應在確認受入侵環境完成清理後，再安全地放回系統，避免再次外洩。簡單來說，就是「先停用有風險的舊鑰匙，再確認安全後換上新鑰匙」，不能因為環境尚待清理而延後撤銷。
這對製造業維運也是相同的原則：系統出現異常時，未必能把所有伺服器立刻關機，但必須清楚界定哪些功能路徑已成為攻擊破口、哪些可維持運作，並依照嚴謹的順序進行修復與憑證重建。
當攻擊者開始導入 Agentic AI：防禦反應時間的極限壓縮
微軟於 10 月 21 日發布的威脅情報，給這張攻防圖景補上了關鍵的演進維度：攻擊組織 Storm-0940 已使用名為「ARTEX」的 Agentic AI 滲透測試框架。
ARTEX 能將目標探索、密碼噴灑（Password Spraying）、OAuth 應用程式授權探勘與橫向移動串連成自動化閉環。微軟觀測到多起使用 ARTEX 的攻擊，從初始鎖定目標到取得雲端特權存取，不到三小時。
傳統企業的防禦節奏往往需要層層人工確認：系統告警 → 安全團隊判斷 → 通知負責人 → 評估營運影響 → 安排修補時間，整個流程可能耗費數天甚至數週。相較之下，攻擊者已能透過自動化工具在短時間內同步嘗試多條入侵路徑。速度差距，正成為企業必須正視的新風險。
更關鍵的是，攻擊者利用的往往不是什麼未公開的深奧手法，而是企業內部早已授權的第三方 OAuth 應用程式或過度寬鬆的 Service Principal。當攻擊路徑能在數小時內自動重組，平時若沒有嚴格收斂權限邊界，事後處置很難跑在損害擴大之前。
AI Agent 進入企業系統：避免把「輔助分析」變成「高特權後門」
這幾起事件反映的身分與權限問題，在當前企業導入 AI Agent（基於 Model Context Protocol, MCP 或 API Tool-Calling 架構） 時尤為明顯。
以製造現場的設備排查為例： 工程師希望 Agent 能閱讀維修手冊、查詢感測器數據以提供診斷建議，這原本是一個單純的唯讀（Read-Only）工作流程。但在實際落地時，為了串接方便，開發團隊常直接掛上一組現成的資料庫管理帳號（Service Account）。這組帳號除了查詢資料，可能還能修改生產排程、建立工單，甚至透過其他系統向設備下達變更指令。原本只負責協助診斷的 Agent，因此意外擁有了影響現場運作的能力。
這就形成了典型的過度授權問題：Agent 原本只需要協助判讀，卻可能握有更改產線設定的權限。一旦受到惡意資訊誤導，原本合法的工具反而可能成為攻擊管道。
如果該 Agent 調用的某個第三方開源套件遭遇了如同 LiteLLM 的供應鏈污染，或者模型遭遇間接提示詞注入（Indirect Prompt Injection），攻擊者根本不需要破解複雜的內網防火牆——若能誘使具備過度權限的 Agent 調用合法工具，就可能以該身分影響產線操作。
在這種情境下，Prompt 裡寫的「請不要修改生產數據」並不能構成系統層面的權限控制。真正的控制邊界，必須回到架構與 API 執行層：
- 讓 AI 放心查詢，重要變更仍由人把關：設備狀態查詢、維修資料整理等工作，可以交由 Agent 自動完成，但系統帳號必須真正只有讀取權限。即便如此，如果 Agent 能看到敏感資料、讀取外部文件，又能把資訊傳送到外部，仍可能被惡意內容誤導而外洩資料，因此對外傳輸也要設限。至於修改設備參數、建立採購單等會改變現場狀態的操作，則應先由系統攔截，再交由人員核准。簽核畫面必須清楚呈現修改前後的差異、影響哪些設備，以及可能帶來的風險，避免同仁只是習慣性地按下「同意」。
- 讓系統授權更安全：不要在程式設定裡長期保存不會到期的金鑰。不論雲端或工廠內部系統，都應朝「需要時才授權、使用後就失效」的方向設計，讓 Agent 在工作期間只拿到必要權限。這樣即使個別金鑰不慎外洩，也能縮短它被濫用的時間與影響範圍。
- 為老舊設備加上一道安全關卡：對於無法直接支援新式資安機制的老舊設備，應在 Agent 與產線之間設置一道受控的安全通道，只放行事先核准的設備、操作與使用頻率。例如，查詢設備狀態可以開放，變更設備設定則需額外授權或人工確認；辦公網路與產線網路也應分區管理，降低單一系統失守後擴散至生產現場的風險。
這也是 Profet AI 在推進 Domain Twin 落地時的核心思維：不把安全押注在「模型永遠不會犯錯或被騙」的假設上，而是從基礎設施層面，將 Agent 的分析推論與實際系統操作分開授權。 透過獨立帳號、分區網路與受控操作入口，讓 Agent 的分析環境與實際產線之間保持清楚界線。即使個別元件出現安全問題，也能降低影響持續擴大的可能，盡可能把風險限制在局部環境，保護整體生產運作。
潘朵拉盒子打開之後：將資安化為日常運作的工程機制
回頭檢視這連串事件，企業過去仰賴的資安做法依然重要，但必須認清其邊界所在：
- 程式碼維持不變，底層 Runtime（PHP2Shell）仍可能在應用程式啟動前遭觸發；
- 即使軟體來自官方、也有正式的發布證明（LiteLLM、Trivy），建置流程仍可能遭到操控；
- 資料在儲存時加密（Railway），但若長期金鑰存放在環境變數中，具備解密能力的身分遭接管時，單靠儲存加密仍不足以阻止存取；
- 微軟觀測到部分使用 ARTEX 的攻擊，從初始鎖定到取得雲端特權存取不到三小時。
面對這些變化，資安團隊如果依然把大部分精力放在「等漏洞公布後疲於奔命地打 Patch」，將永遠處於被動追趕的劣勢。
修補漏洞（Patching）是不可或缺的基本功，但它無法單獨構成防禦戰略。
這不只適用於 PHP，包含 Java（含 Tomcat）、Node.js 等廣泛使用的元件，同樣需要持續追蹤相依風險。維運團隊真正需要的，是一套能持續接收公告、判斷自身部署關聯性、評估曝險條件，並在兼顧業務穩定的前提下完成修補與驗證的工作流程。
在 Profet AI 自身的工程實踐中，這套機制正逐步轉化為日常維運常態：
面對近期的重大安全公告，團隊已完成產品層級的元件盤點與映像檔弱點掃描，並依相容性測試安排更新驗證。更進一步的改變在於回應節奏：Profet AI 已將部分漏洞監控工作導入自動化 Agent，每日自動追蹤 CVE 動態，依元件相依性過濾風險，讓研發與資安人員不必在海量公告中手動翻找，能把精力集中在實質的影響評估與相容性測試上。
在版本交付層面，除了一般功能版本的既有節奏，Profet AI 亦規劃針對 Critical 資安事件建立定期的安全修補交付管道，明確載明修補 CVE、影響範圍與驗證結果，協助企業客戶在兼顧現場稼動率的前提下，清楚掌握自己環境的安全狀態。
這些做法延伸到 Domain Twin 的架構管理上，也是相同的原則：隨著 ML 與 Agentic AI 深度參與製造現場的工程分析，所有資料存取、工具調用與操作審核，都必須建立在可管、可控、可追溯的邊界之內。軟體供應商負責確保交付產物的純淨度與修補透明度，企業客戶則負責收斂現場的網路環境與存取權限，雙方協同，防護才可能真正落地。
這正是潘朵拉盒子打開後的現實：不是每天都會遇到 PHP2Shell 等級的重大危機，而是系統每天都會產生新的依賴關係、API 串接與身分授權。
漏洞總有補完的一天，但軟體環境與授權關係的變動永遠不會停止。企業未來的資安韌性，不再取決於團隊喊出多高的安全口號，而在於這套架構在面對未知的相依性背叛時，能否精準控管權限、限制影響並完成復原。因此，企業資安的衡量標準，不該只剩下「有沒有出事」或「修補得夠不夠快」。更重要的是：當風險出現時，能否及早發現、清楚判斷、限制影響，並從每次事件中讓系統變得更穩健。真正的資安韌性，不是承諾永不失守，而是讓企業在持續變化中守住安全邊界，讓 AI 創新穩健前進。