2026 黑色十月安全復盤，從 PHP2Shell 與 LiteLLM 投毒看 AI 時代開源底座危機

2026 年 10 月 21 日，全球互聯網經歷了一場久違的物理級恐慌。英國政府一口氣關停 32 項公共服務，芬蘭政府 ICT 中心（Valtori）臨時切斷全部面向公眾的政務網站，維基百科的程式碼協作平台、互聯網檔案館乃至日本全日空與《賽馬娘》的伺服器紛紛掛出維護公告。引發這場全球「拔網線」浪潮的導火線，是潛伏在 PHP 直譯器核心長達 14 年的兩枚遠端程式碼執行漏洞——PHP2Shell（CVE-2026-109618 與 CVE-2026-109619）。

如果把視野從單一語言拉寬就會發現，這根本不是一次孤立的事故。在 10 月 17 日至 30 日這兩週裏，Google Brotli 解碼器越界寫入（Node2Shell）、潛伏 16 年的 TianoCore UEFI 韌體預啟動漏洞、潛伏 12 年的 GitLab 滿分遠端程式碼執行、印度 CA 機構 eMudhra 把中間憑證私鑰生成為單字節數字 4，以及當紅 AI 閘道器 LiteLLM 的供應鏈投毒相繼引爆。

這一輪被安全界稱為「黑色十月（Black October）」的危機，標誌着攻防邏輯的分水嶺。當 GPT-5.6 Sol 與 Gemini 4 Argon 把挖掘十年級複雜狀態機缺陷的週期從「頂尖團隊數月」壓縮到「單人一週」，真正被算力擊穿的不只是底層 C 程式碼的記憶體邊界，還有靠 13 名受資助開發者和業餘志願者苦撐全球 70% 網站的開源治理防線。

十月斷網潮與六場並發的底座危機

過去十年裏，安全圈習慣了每一次超級漏洞都有一個唯一的「主角」，比如 2014 年的 Heartbleed 或 2021 年的 Log4Shell。但 2026 年 10 月中下旬的荒誕之處在於，互聯網從硬件韌體、加密憑證、壓縮演算法、伺服器端直譯器到 AI 供應鏈的六個核心層級，在短短十幾天內同時失守。

把這六場危機的核心參數放在同一張表裏，能更直觀地看清當時的應急響應有多窒息：

除了這六大支柱，同一週裏還夾雜着趨勢科技 ZDI 在 10 月 21 日誤將未修復的 Linux 內核 KSMBD 遠端程式碼執行漏洞（ZDI-CAN-33549、ZDI-CAN-33774，CVSS 9.0）抄送公開郵件列表，以及月末幣安（Binance）63 億美元加密資產失竊與無印良品（MUJI）2,726 萬用戶數據洩露。

在所有並發事件中，真正讓各國政府拉閘斷電的還是 PHP2Shell。根據 W3Techs 的統計，PHP 依然驅動着全球約 69.2% 至 70% 已知伺服器端語言的網站；Wiz Research 的雲端環境遙測顯示 65% 的企業組織在生產環境中運行 PHP，而 Palo Alto Networks Cortex Xpanse 在全網掃出了超過 2,260 萬台直接暴露在公網的 PHP 實例。

更糟糕的是，官方原本計劃在 10 月 22 日按協調披露流程發版，但禁運防線在最後關頭連環失守：

• 披露前 4 天已遭在野搶跑：AWS 威脅情報團隊透過全球蜜罐網絡 MadPot 證實，早在 10 月 17 日就有威脅行為體透過商用匿名代理網絡發送針對 PHP2Shell 的利用載荷；
• 論壇洩密與演示影片誤公開：Andreas Scherzer 的分鐘級復盤時間線記錄顯示，10 月 20 日 15:00 UTC，Hacker News 出現匿名帖（item?id=50167754）捅出「PHP2Shell」代號與兩枚 CVE 編號；PHP 官方被迫將發版時間提前 24 小時；緊接着 20:00 UTC 左右，Calif 研究團隊在準備材料時不慎將一段橫掃 WordPress 7.1.3、MediaWiki 1.46.2、Magento 2.4.9、Laravel 13.36.0、Drupal 11.4.10 等 10 款主流框架的 RCE 演示影片設為公開；
• 容器映像提前 6 小時破窗：10 月 21 日 06:07 UTC，容器廠商 Chainguard 違反禁運協議，提前逾 6 小時在公開倉庫推送了打好修補程式的 PHP 映像，讓外部攻擊者得以直接透過二進制差分（Binary Diffing）逆向定位漏洞函數。

當 PHP 官方在 10 月 21 日 13:31 UTC 緊急放出 8.5.12、8.4.27、8.3.36、8.2.35 修補程式（並罕見地為早已停止支援的 PHP 7.4、8.0、8.1 提供源碼級最小回移修補程式）時，英國國家網絡安全中心（NCSC）向全英機構發出了 50,000 份緊急警報，明確建議「如果無法立即部署緩解措施或耗時過長，應考慮將系統下線」。日本首相高市早苗也在社交平台公開呼籲企業必要時暫停服務。隨後 48 小時內，英國 32 項政務服務、芬蘭全部公共政務網、荷蘭議會下院（Tweede Kamer）與 DigiD 登入系統、維基媒體基金會的 Phabricator 與 Toolforge 平台，以及日本全日空（ANA）、JR 西日本、三菱日聯銀行（MUFG）部分網頁相繼預防性停機。

把十四年老洞寫成 SKILL.md，大模型如何拆穿 PHP 記憶體邊界

為甚麼這兩枚潛伏在 PHP 直譯器最底層的漏洞，能夠繞過上層業務程式碼，通殺從 WordPress 到自研框架的幾乎所有應用？

答案藏在 PHP 處理記憶體耗盡（Out-of-Memory，OOM）時的緊急跳出機制，以及長生命週期 Worker 行程的跨請求狀態管理裏。

在 PHP 引擎內部，當單次請求分配的記憶體觸碰 memory_limit（預設 128M）時，引擎會呼叫 zend_bailout()——底層直接基於 C 語言的非局部跳轉 longjmp()——立刻跳出當前執行棧並中止請求。這種設計假設所有底層 C 函數在分配記憶體前都處於「隨時可以安全中斷」的一致狀態。但 Calif Research 的 Ryan Austin 與 Wiz Research 團隊揭開了兩類致命破綻：

1. 前置突破（用不到 8MB 報文撐爆 128MB 記憶體）：很多人起初以為 PHP 預設的 post_max_size = 8M 會擋住超大記憶體消耗。實際上攻擊者有兩條繞過路徑：一是發送省略 Content-Length 標頭的 HTTP/1.1 Transfer-Encoding: chunked 請求或無 content-length 偽標頭的 HTTP/2 流，讓 PHP 持續緩衝直至撞上 128MB 牆；二是在解析 multipart/form-data 檔案上傳（main/rfc1867.c）時構造深層嵌套空陣列變數名（如 files[a][b][c]...），迫使 PHP 為每個欄位在 $_FILES 中重複初始化 name、type、tmp_name、error、size 五棵 HashTable 子樹，不到 8MB 的原始 POST 報文就能在記憶體中膨脹出逾百兆字節的結構體分配。
2. CVE-2026-109618（OOM 中斷導致的未初始化記憶體破壞）：在 Zend/zend_hash.c 的 _zend_hash_str_add_or_update_i 函數中，程式碼先把雜湊表已用計數 ht->nNumUsed++ 加一，隨後才呼叫 zend_string_init 為鍵名分配記憶體。如果恰在此時觸發 OOM longjmp()，槽位計數已經增加，但對應槽位的 Bucket.val 仍是未初始化的垃圾數據；緊接着請求清理階段 zend_hash_destroy 遍歷銷毀該表時，就會把未初始化的野指標當作合法 zval 呼叫解構函數，直接劫持控制流。
3. CVE-2026-109619（跨請求陳舊全局狀態 UAF 與「PHPBleed」）：在 Apache mod_php 或 PHP-FPM 等多請求複用同一 Worker 行程的架構下，PHP 存在多個臨時指向單次請求堆記憶體的全局變數。例如當請求帶有 PHP_SESSION_UPLOAD_PROGRESS 欄位（session.upload_progress.enabled=1 預設開啟）時，PHP 在請求極早期（PG(modules_activated) 仍為 0）就將全局變數 PS(mod_data) 指向請求記憶體；若此時觸發 OOM，引擎會因模組尚未標記激活而跳過所有 RSHUTDOWN 清理函數，導致請求記憶體釋放後 PS(mod_data) 仍保留懸垂指標。同理，在 ext/standard/var_unserializer.re 中，unserialize() 內部 OOM 會令 RSHUTDOWN 將 BG(unserialize).level 遞減為 -1，在下一請求引發 used_slots 整數溢位與跨請求釋放後重用（UAF）。而當 php_session_start() 期間發生 OOM 導致會話 ID 指標 PS(id) 未清零時，下一請求的 Set-Cookie: PHPSESSID=... 響應標頭更會像當年的 Heartbleed 一樣，直接把 Worker 記憶體裏的環境變數、數據庫密碼、API 金鑰乃至用於繞過 ASLR 的共享庫基址回傳給攻擊者（即「PHPBleed」）。IBM 全球對手模擬負責人 Patrick Fussell 對此打了個精準的比方：「這就好比你退了酒店房間，但房卡依然有效；你稍後推門回去，房間裏已經擺滿了下一位住客的行李。」

真正讓人背脊發涼的不是漏洞本身有多精巧，而是它們被挖出來的方式。

利用 memory_limit 中斷製造狀態不一致的思路，早在 2004 年就由 PHP 安全專家 Stefan Esser 提出；2020 年，安全研究員 jr@coredu.mp 也曾提交 Bug #78876 指出 multipart/form-data 可繞過限制觸發 OOM。但在長達十幾年裏，要在數百萬行 C 程式碼中人工追蹤跨模組巨集展開、引用計數、堆佈局與非局部跳轉的排列組合，幾乎處於人類精力的極限邊緣。

2026 年夏天，遊戲規則變了。6 月 22 日，OpenAI 聯合 Trail of Bits 啟動「Patch the Planet」開源安全審計計劃；7 月 30 日，安全公司 Calif 加入該計劃審計 PHP 源碼。Calif 研究員 Ryan Austin（@lcfr_hax）藉助 OpenAI 的 GPT-5.6 Sol 模型，在啟動審計後第 2 天（8 月 1 日）就揪出了 _zend_hash_str_add_or_update_i 的 OOM 中斷原語。更關鍵的是，他在找到第一個漏洞後，直接讓大模型將該缺陷抽象成了一份可供 AI 智能體反覆呼叫的 SKILL.md 結構化狩獵模式：

publish or destroy state (發布或銷毀狀態)
  -> perform fallible work (執行可能觸發 OOM 的可失敗分配)
  -> nonlocal fatal (觸發 zend_bailout / longjmp 非局部致命跳轉)
  -> commit/rollback skipped (跳過正常提交或 RSHUTDOWN 回滾清理)
  -> surviving consumer trusts false state (同一 Worker 的後續消費者信任殘留的錯誤狀態)

拿着這份 SKILL.md，AI 智能體在百萬行 C 程式碼裏按圖索驥，迅速掃出了 session.upload_progress 與 var_unserializer 等一整串同類原語。幾乎在同一時期（8 月 19 日至 24 日），Wiz Research 團隊在毫不知情的情況下，動用自研安全智能體 Wiz Atlas、Google Gemini 4 Argon 與 GPT-5.6 Sol，僅由單名研究員在 1 週內就獨立發現了這組漏洞並打通了覆蓋 mod_php 與 PHP-FPM 的四條利用鏈：

"The underlying flaws had been present for decades, but demonstrating their exploitability required an exceptionally complex chain of steps, at the edge of what human researchers could practically achieve. Frontier AI models substantially reduced that barrier, turning a longstanding flaw into an exploit. With frontier AI models and the right tools, a single researcher completed in a week what previously would have taken a world-class team months of work." （這些底層缺陷已經存在了數十年，但證明其可利用性需要極其複雜的步驟鏈條，處於人類研究人員實際可達成能力的邊緣。前沿 AI 模型大幅降低了這一門檻，將長期存在的缺陷轉化為漏洞利用。藉助前沿 AI 模型和適當的工具，單名研究人員在一週內就完成了過去需要世界級團隊耗時數月才能完成的工作。）

同樣的劇本貫穿了整個「黑色十月」：引發 Node.js、.NET、Bun 與 微軟全線產品帶外更新的 Google Brotli 越界寫入漏洞（CVE-2026-111497），其修復提交 0ed4268a 早在 2026 年 2 月 27 日就已合入倉庫卻無人意識到是安全漏洞，直到 OpenAI Codex Security 研究員 Khai Tran 與 Sylvie Mayer 用模型將其挖出；而潛伏在 TianoCore EDK II 韌體裏整整 16 年的 PXE 預啟動漏洞（CVE-2026-97631），同樣是由 Anthropic 研究員 Alex Matrosov 與 Google 研究員 Dan Holmes-Mitra 聯手翻出（後因韌體廠商 AMI 提前提交公開 Pull Request 打破了原定 2027 年 1 月的禁運，詳見 Ars Technica 報道）。

當 AI 工具鏈開始反噬，LiteLLM 投毒案的 101 分鐘驚魂

如果說 PHP2Shell 和 Brotli 展現的是 AI 算力對「舊世界 C 語言底座」的降維清算，那麼在 2026 年 10 月 21 日「黑色星期三」同一天爆發的 LiteLLM 供應鏈投毒案，則赤裸裸地暴露了「新世界 AI 基礎設施」自身的脆弱與燈下黑。

LiteLLM 是當前企業與開發者接入 OpenAI、Anthropic、AWS Bedrock 等百餘種大模型最核心的開源 Python 閘道器之一。10 月 21 日 11:39 UTC——就在全球運維團隊焦頭爛額地等待 PHP 官方修補程式落地的同一時刻——攻擊者向 PyPI 官方源推送了篡改版 litellm==1.107.0，並在 11:46 UTC 至 14:20 UTC 之間同步污染了 Docker Hub 與 GitHub Container Registry（GHCR）上的 v1.107.0、latest、main-latest 和 main-stable 容器映像。

根據 BerriAI（LiteLLM 母公司）的事後官方復盤與 Wiz Research 的逆向報告，整條入侵鏈從源頭到變現都帶着濃重的 AI 時代烙印：

• 源於 Claude Code 響應體日誌的令牌洩露：BerriAI 內部在公網暴露了一台開啟了詳細響應體日誌記錄的 LiteLLM 實例。研究團隊發現，Claude Code 在特定場景下會將用戶的 GitHub CLI OAuth 令牌直接嵌入到響應體（Response Body）中，結果導致 BerriAI 內部 3 名核心工程師的 GitHub CLI OAuth 令牌被原原本本記入了 LiteLLM 日誌。攻擊者拿到這 3 枚令牌後，直接觸發並批准了 v1.107.0 的正式發版流水線。
• 101 分鐘狂攬 4.9 萬次下載與雙持久化鈎子：儘管 PyPI 在 13:20 UTC（上線 101 分鐘後）緊急隔離了該版本，但 ClickPy 統計顯示，這短短一個多小時內惡意套件已被自動化 CI/CD 流水線和開發者拉取了約 49,000 次。Wiz 逆向發現，惡意載荷具有明顯的 LLM 輔助編寫特徵，且首次在野採用了 .pth + sitecustomize.py 雙持久化並行機制——只要宿主機上啟動任意 Python 直譯器，cook.pth 就會自動匯入 cook.py，在 /tmp/.pc_once_72129118c59f5636c0bb 寫入單次執行鎖後，呼叫內部名為 privcollect 的 16 個採集模組，把瀏覽器密碼、AWS/GCP/Azure 雲端憑據、OpenAI/Anthropic API 金鑰乃至 PostgreSQL 數據庫表 "LiteLLM_CredentialsTable" 中的前 500 條金鑰一網打盡，經 AES-256-CBC 與 RSA-4096 加密後回傳至仿冒域名 www.litellm.dev/healthcheck；與此同時，sitecustomize.py 則在 Linux 和 macOS 後台每小時輪詢一次 GitHub 死信箱（letters9813/pythonclient-test/main/domain.txt），隨時準備拉取二階段遠控腳本。
• 4.5 小時極速轉入算力劫持（LLMjacking）：在憑據外洩僅 4.5 小時後的當日 16:20 至 17:01 UTC，攻擊者就已經開始批量呼叫 sts:GetCallerIdentity 與 bedrock:ListFoundationModels，直接盜用受害企業的 AWS Bedrock 配額實施大模型算力劫持。

一邊是防守方用大模型挖穿潛伏 14 年的傳統開源底座，另一邊是攻擊者從 AI 編程工具與 AI 閘道器的日誌漏洞裏順走鑰匙，用大模型寫的木馬反過來收割雲端大模型算力。這兩幕在同一天上演，構成了 2026 年「黑色十月」最諷刺的畫面。

泛用腳本碰壁與 25 台伺服器失守，AI 攻擊鏈的真實水位

在 PHP2Shell 公開後的頭幾天裏，安全社群一度陷入兩極分化的爭吵。

一方面，Cloudflare 行政總裁 Matthew Prince 披露，在漏洞正式公布前 10 小時就已觀測到數千次嘗試，公布後 45 分鐘內飆升至數萬次，24 小時內突破數百萬次。但另一方面，Wiz Research 在 10 月 27 日的實測拆解與 Bishop Fox 的應急指南均指出，GitHub 上瘋傳的兩大主流開源 PoC 家族——針對 CVE-2026-109618 的 archive/legacy-8m/exploit.py 和針對 CVE-2026-109619 的 pure/mk_a1.py + mk_leak_b.py——在離開預設 Docker 靶機後，面對真實生產環境幾乎全軍覆沒。

原因並不複雜：legacy-8m 強依賴 Apache mod_php 且未加 chunked 編碼時會被預設 8M 限制直接攔下；而針對現代主流 PHP-FPM 的 pure/mk_a1.py 不僅硬編碼了特定編譯版本的堆風水偏移量（Heap Feng Shui offsets），還苛刻地要求先後兩次請求必須命中同一個 PHP Worker 行程。在高並發或多 Worker 負載均衡的生產伺服器上，正常業務流量隨手就會打亂堆佈局，或者直接把 Worker 撞崩重啟。GitHub 上甚至還冒出了像 WoYinDao/CVE-2026-109618-CVSS-9.2-Critical 這樣掛羊頭賣狗肉的假 PoC（底層其實是在掃陳舊的本地檔案包含 LFI 路徑），被腳本小子和殭屍網絡拿去全網盲掃，製造了漫天無效的 HTTP 500 噪音。

但這絕不意味着 PHP2Shell 只是一場虛驚。當腳本小子拿着泛用腳本到處碰壁時，真正具備工程化能力的高級威脅行為體，已經用行動證明了甚麼叫「外科手術式狙擊」。

2026 年 10 月 29 日，Dream Research 與 Palo Alto Networks Unit 42（及 Cybersecurity Dive 通報）聯合公開了首起經過完整取證驗證的高級在野入侵行動（追蹤代號 CL-UNK-1280）。取證人員在攻擊者的基礎設施裏發現了已安裝的 Claude Code，以及一套早在 10 月 8 日就配置好、接入了 DeepSeek 與 Kimi 大模型的自動化攻擊平台 aiscan。

這批攻擊者根本沒有去碰充滿隨機性的公開 Web 站點，而是把準星死死鎖在了環境高度標準化、且管理平面（appweb）內嵌了高記憶體上限 PHP 8.0.30 與 7.4.33 的 Palo Alto Networks PAN-OS 邊界防火牆上：

1. 漏斗式精準測繪與韌體逆向：攻擊者先透過 FOFA 檢索出全球約 19,000 台暴露管理界面的防火牆（約佔全球安裝基數的 0.02%），用 200 執行緒存活探測篩出 5,000 台在線設備，再按美國、日本、中國台灣和韓國四地及 PHP 8.0.30 版本過濾出 240 個高價值目標。動手前，攻擊者已提前解密了 PAN-OS 韌體，針對不同小版本逆向提取了 11 份精確到字節的 libphp.so 記憶體偏移檔案（Profiles）。
2. 四階段 PHP2Shell + 內核提權 Fragnesia 一擊拿 Root：為了繞過防火牆的 SELinux httpd_t 沙箱限制，攻擊者設計了一套四階段連招——A1 發送 383MB 載荷耗盡記憶體製造懸垂狀態，B1 從 Set-Cookie 響應標頭洩露 libphp.so 基址繞過 ASLR，A2 發送 500MB 載荷建立陳舊引用，最後在 B2 請求中偽造 HashTable 解構函數呼叫 zif_system，並在同一次 HTTP 請求內直接串聯 Linux 內核 XFRM ESP-in-TCP 本地提權漏洞 Fragnesia（CVE-2026-46300），透過頁快取覆寫 774 字節的 /etc/pam.d/su 為 pam_permit.so。從發起請求到奪取無密碼 root 權限並植入 103 字節的 Webshell（/unauth/php/change_password.php），全程僅需 15 分鐘。
3. 穿透反向隧道攻陷美國政府關聯內網：10 月 23 日 18:14 至 21:55 UTC，攻擊者一口氣拿下了 24 台邊界防火牆的 root 權限。10 月 24 日 10:09 UTC，攻擊者針對其中 2 台隸屬於某美國政府關聯機構（啟用了 CAC 智能卡認證）的防火牆發起專項行動，在 /usr/local/lib/.panops/ 下建立開機自啟的 8 端口反向 SSH 隧道；11:35 UTC，攻擊者穿過隧道，對原本嚴格隔離在內網的第 25 台伺服器（中央防火牆管理伺服器）再次發射同一套 PHP2Shell 利用鏈奪取 root，用主金鑰解密了管理服配置裏的 LDAP 服務賬號明文密碼，並在網域策略 lockoutThreshold=0（無賬號鎖定）的條件下，對整個 Active Directory 網域發起了全量枚舉、密碼噴灑、後門機器賬號創建與 Keycloak SAML 簽章金鑰提取。

正是這起乾淨利落的實戰狙擊，連同安全研究員 Adel Karimi 蜜罐被破、英國滲透測試員 Jaydip Modhwadia（killa）攻破 2,000 美元比特幣實機懸賞靶標，促使美國 CISA 在 10 月 26 日至 28 日連續三天將 CVE-2026-109618、CVE-2026-109619、Brotli CVE-2026-111497 以及內核提權漏洞 Fragnesia（CVE-2026-46300）悉數列入「已知被利用漏洞目錄（KEV）」，JPCERT/CC 與日本 IPA 也隨即發出最高級別追加通報。

更嚴峻的是防守方的長尾困境。Wiz Research 的連續遙測顯示，儘管從 10 月 22 日到 25 日，全網暴露的受影響 PHP 主機總數下降了 67%，但擁有至少 1 台未修復暴露主機的企業組織比例在首日降到 63.0% 後便迅速放緩，到 10 月 25 日仍有 52.1% 的組織沒能清零（累計降幅 47.9%）。大量不直接對外宣告 PHP Banner 的邊界閘道器、硬件防火牆管理口、老舊 NAS 和停留在 EOL 分支的內部系統，依然暴露在自動化攻擊平台的瞄準鏡下。

13 個人的基金會與 48 小時不眠的志願者，開源底座還撐得住嗎

復盤完技術細節與攻防實況，最後必須回到那個最刺痛工程界的問題：為甚麼一個早在 2004 年就有理論先例、2020 年就有 Bug 報告的隱患，會一直留到 2026 年被 AI 挖穿？

很多人不知道的是，構成 CVE-2026-109618 的核心 OOM 錯誤處理缺陷，其實早在 2024 年 6 月——在德國主權技術局（Sovereign Tech Agency）出資、OSTIF 與 Quarkslab 組織的 PHP 安全審計中——就已經被一名 PHP 核心開發者親手指出了。

2026 年 10 月 21 日，PHP 基金會執行董事 Roman Pronskiy 在官方復盤網誌中寫下了一段極其坦誠的自我剖析，公開承認那次長達兩年的擱置是一場**「結構性失靈（structural failure）」**：

"In 2024, during the security audit facilitated by OSTIF and Quarkslab and funded by the Sovereign Tech Agency, a PHP core developer identified the out-of-memory error handling issue that forms part of CVE-2026-109618. At the time, no concrete exploit path was known, and the proposed fixes carried trade-offs that delayed consensus. Looking back, failing to resolve this earlier was a structural failure." （2024 年，在由主權技術局資助、OSTIF 與 Quarkslab 促成的安全審計期間，一名 PHP 核心開發者識別出了構成 CVE-2026-109618 一部分的記憶體耗盡錯誤處理問題。當時尚未發現具體的漏洞利用路徑，且提議的修復方案伴隨着權衡取捨，推遲了共識的達成。回過頭看，未能更早解決這一問題是一次結構性失靈。）

為甚麼發現了卻修不掉？《The Next Web》與 BBC News 的深度調查揭開了開源底座光鮮外表下的窘迫家底：

• 13 個人扛起 70% 的互聯網：驅動全球近七成網站的 PHP 基金會，全職與兼職受資助的核心開發人員加起來只有 13 個人。團隊既沒有專職的安全項目經理，也沒有強制升級裁決機制。當 2024 年那名開發者指出 OOM 隱患時，由於當時沒人能手寫出完整的端到端 RCE PoC，而徹底修補又需要在底層引入破壞向後兼容性、甚至可能導致第三方擴展模組崩潰的侵入式改動，幾套競爭性方案在「共識驅動」的郵件列表裏爭論不休，最終被擱置了整整兩年。
• 一個捷克志願者的 48 小時極限孤戰：上游發了源碼修補程式，成百上千萬台生產伺服器並不能直接用上。全球 Debian 與 Ubuntu 生態中最核心的 PHP 軟件套件倉庫（deb.sury.org），長期以來完全由捷克志願者開發者 Ondřej Surý 一個人利用業餘時間維護。在 PHP2Shell 爆發的那兩天裏，這位志願者幾乎整整 48 小時沒有合眼，獨自一人完成了從新版本到老舊分支的全部回移打包，才讓全球數百萬台 Linux 伺服器能夠敲下一行 apt upgrade 救命。
• 「找洞已經變成了最廉價的部分」：正是在 PHP2Shell 爆發的同一週，OpenAI 行政總裁 Sam Altman 公開坦言「我不再認為我們能夠修補所有漏洞」；Anthropic 副 CISO Jason Clinton 警告行業正迎來一場「沒有足夠時間給關鍵基礎設施打修補程式的漏洞海嘯」；美國前 CISA 局長 Chris Krebs 更在 CNBC 專訪中估算，「人類歷史上發現的所有嚴重（Critical）漏洞中，約有 3% 是在剛剛過去的一個月內被發現的」。

正如 Trail of Bits 工程團隊在復盤「Patch the Planet」計劃時寫下的那段判詞：

"If it wasn't already clear from the last several months of security news, this week makes one thing clear: the expensive part of security work has moved... The advantage is no longer in finding bugs, but everything after: confirming a finding, getting its severity right, writing a patch a maintainer will accept, hardening the surrounding code, making long-term improvements to prevent similar issues in the future, and coordinating a disclosure." （如果過去幾個月的安全新聞還不夠清楚的話，本週讓一件事變得無比明確：安全工作中昂貴的部分已經轉移了……優勢不再在於發現漏洞，而在於發現之後的一切：確認發現、準確評估嚴重程度、編寫維護者能夠接受的修補程式、加固周邊程式碼、做出長期改進以防止未來出現類似問題，以及協調披露。）

過去二十年，開源安全的預設假設是「深層架構漏洞極難被串成穩定利用鏈，只要還沒人寫出 PoC，維護者就有幾年時間慢慢討論兼容性」。大模型把這條緩衝帶徹底抹平了。當 AI 可以在幾天內把二十年前埋下的狀態機裂縫變成 15 分鐘拿 Root 的自動化武器，而開源社群依然指望十幾個兼職開發者靠用愛發電去接住每秒鐘都在產生的算力洪流，這種錯配註定無法持續。

對於科技巨頭和前沿 AI 實驗室來說，光靠跑大模型刷 CVE 排行榜、把成百上千份漏洞報告甩給精疲力竭的志願者維護者，並不是真正的安全貢獻——出資為關鍵開源底座配備專職安全工程團隊、用 AI 協助編寫經過完整回歸驗證且兼顧向後兼容的高質素修補程式，才是償還技術債的唯一出路。

而對於我們每一個在一線維護產品的開發者和運維團隊，「黑色十月」留下的工程教訓同樣無比具體：

1. 立即核查並收斂運行時邊界：將 PHP 升級至 8.5.12、8.4.27、8.3.36、8.2.35 或發行版對應安全修補程式版本；若受限於遺留系統暫無法升級，第一時間在 php.ini 中顯式設置 session.upload_progress.enabled = 0，避免在運行時透過 ini_set 動態切換 session.serialize_handler（防範關聯漏洞 CVE-2026-115560），並在反向代理（Nginx / Cloudflare）層嚴格限制分塊傳輸與請求體大小、縮短 PHP-FPM pm.max_requests 週期以加速回收 Worker 行程。
2. 排查跨語言底層依賴與內嵌設備：同步升級 Node.js（22.23.4 / 24.22.1 / 26.12.1）、Bun（1.4.4）、.NET（8.0.33 / 9.0.22 / 10.0.14）及 Python 環境中的 brotli 解碼庫（修復 CVE-2026-111497）；重點清查防火牆、VPN 閘道器、NAS 等內部嵌套了舊版 PHP 管理界面的硬件設備，嚴禁將管理平面直接暴露於公網。
3. 清查 AI 工具鏈與憑據衛生：凡在 2026 年 10 月 21 日拉取過 litellm==1.107.0（PyPI 或容器映像）的環境，僅降級軟件套件遠遠不夠，必須排查宿主機 Python site-packages 下的 cook.pth、cook.py、sitecustomize.py 及 /tmp/.pc_once_* 痕跡，並全量輪換機器上接觸過的所有雲端廠商金鑰、大模型 API Key 與數據庫憑據；同時嚴禁在代理閘道器中開啟未脫敏的完整響應體日誌記錄。