WEBVTT NOTE Title: [2026-10-22] PHP2Shell衝擊全球七成網站、LiteLLM爆發PyPI後門與八位元CA私鑰大崩潰 1 00:00:00.000 --> 00:00:57.000 歡迎收聽今天的每日放送，我是 Cordelia。今天科技圈最震撼的消息，絕對是席捲全球網路的 PHP 核心遠端代碼執行漏洞 PHP2Shell，以及 LiteLLM 在 PyPI 上被植入後門的嚴重供應鏈攻擊。我們先從 LiteLLM 說起，就在昨天我們才聊到 Respan 試圖用 Rust 微核心架構來解決 LiteLLM 程式碼龐大難維護的問題，沒想到今天 LiteLLM 官方釋出的 1.107.0 版本就爆出重大安全危機，安裝後會直接在系統上植入竊密程式與後門！ 2 00:00:57.000 --> 00:02:02.510 這個事件非常典型，而且手段極其陰險。攻擊者並不是在 BerriAI 的公開 GitHub 上提交惡意 commit，而是疑似掌握了發布流程或內部憑證，在打包發布的私有管線上動了手腳。在產出的 source distribution 裡，`pyproject.toml` 被加了一行 `data = "cook"`。這會指示打包工具 maturin 把包含惡意程式碼的 `cook/` 目錄直接放進 wheel 的 `purelib` 裡面。這意味著只要用 pip 安裝，這三個檔案就會直接進入 Python 的 `site-packages`。 3 00:02:02.510 --> 00:02:54.300 最恐怖的是，它的啟動機制完全不需要你的應用程式主動 `import litellm`。攻擊者利用了 Python 的內部載入機制，只要有任何 Python 行程在該主機上啟動，惡意 payload 就會自動執行，去搜刮 SSH 金鑰、雲端憑證、甚至連 LiteLLM 代理資料庫裡存的各大 LLM API Key 都被打包偷走。這在開發者社群引發了極大的恐慌，甚至有人主張以後新套件發布至少該強制冷凍冷卻 24 到 48 小時。 4 00:02:54.300 --> 00:03:58.630 技術上它是透過 `cook.pth` 的 `import cook`，以及 Python 啟動時會自動載入的 `sitecustomize.py` 雙重常駐。`cook.py` 收集完環境變數、瀏覽器憑證、AWS IMDS 中繼資料與各家金鑰後，用 AES 加密再以 RSA 公鑰封裝回傳；而 `sitecustomize.py` 則是 fork 出獨立常駐行程，每小時去檢查攻擊者的 GitHub 取得指令。至於所謂的「依賴冷卻期」，坦白說防得了這種粗糙的快速攻擊，但如果攻擊者潛伏數個月才發作，冷卻機制就形同虛設，它並不是萬靈丹。 5 00:03:58.630 --> 00:05:04.140 說到安全防線的全面瓦解，今天的重頭戲絕對是 PHP 核心的雙重重大 RCE 漏洞，社群甚至稱之為「PHP2Shell」。PHP 官方發布了緊急安全性公告，修復了 CVE-2026-109618 和 CVE-2026-109619。根據 Wiz 的研究，這兩組漏洞影響了全網近七成的網站，涵蓋 WordPress、Drupal、Joomla 甚至維基百科底層的 MediaWiki。令人震驚的是，這竟然是研究團隊藉由 Gemini 4 Argon 與 GPT-5.6 Sol 等前沿 AI 模型挖掘出來的，深埋在 C 核心底層超過十年的架構缺陷！ 6 00:05:04.140 --> 00:06:24.310 我們把底層機制拆開來看。第一個漏洞 CVE-2026-109618 本質是記憶體耗盡（OOM）時的狀態損毀。在處理 RFC 1867 multipart 請求時，如果 PHP 遇到記憶體上限中斷，請求堆疊會被直接銷毀，但部分全域或解序列化狀態指標卻沒被重置，導致後續清理程式碼把未初始化或殘留的資料當成有效指標，造成 Use-After-Free。甚至在 Apache 的 mod_php 下，不需要身分驗證，在任何應用程式代碼執行前就能觸發未認證 RCE！而第二個漏洞 CVE-2026-109619 則是請求間的過期全域狀態殘留，像是 fatal error 的 backtrace 或 OPcache 在跨行程映射時的型別混淆，讓攻擊者能精準控制記憶體位址跳轉。 7 00:06:24.310 --> 00:07:18.000 這真的改變了資安攻防的賽局。Wiz 指出，過去要串聯這種複雜的記憶體排列、繞過隨機化位址，可能需要頂尖白帽團隊花費數月手動微調；但在 AI 輔助下，研究人員只要幾天甚至幾小時就能自動產出適配不同版本與記憶體佈局的可用 Exploit。不過這起事件的揭露過程充滿戲劇性，原本預計協調揭露，卻因為社群洩漏、Calif 誤發測試影片，再加上 Chainguard 提前六小時私自發布已修復映像檔打破禁運，逼得 PHP 官方不得不緊急提前釋出修正版本。 8 00:07:18.000 --> 00:08:23.750 Chainguard 提前發布映像檔確實破壞了協調揭露的默契，等於把修補後的二進位差異直接攤給全世界的攻擊者看。更危險的是，網路上在官方修補前流傳了一份所謂的「官方通融解法」，聲稱只要關閉 `session.upload_progress` 就能防護。但開發者 Rohit Bhadani 隨後發文打臉，PHP 官方的諮詢公告寫得很清楚：multipart 解析器的核心 Use-After-Free 獨立於 session 存在，只要收到 POST 表單請求就會觸發，光改那行設定根本無法阻擋漏洞，這就是典型依賴未驗證外流資訊導致的虛假安全感。 9 00:08:23.750 --> 00:09:15.540 Netsec 社群和 Reddit 上現在也是一片哀嚎，因為除了升級到 8.5.12、8.4.27、8.3.36 或 8.2.35 之外，真的沒有能保證百分之百安全的組態繞過方式。對於還停留在 PHP 7.4 或 8.0 等已經 EOL 版本的伺服器，雖然官方破例提供了最小原始碼 backport，但很多舊系統根本無人維護。這也再次凸顯出開源基礎設施的脆弱，PHP 基金會今天也特別發布了長文說明這兩年來的困境與安全體系改革。 10 00:09:15.540 --> 00:10:17.740 PHP 基金會的說明非常坦誠。他們承認早在 2024 年由德國主權技術基金資助的外部審計中，就已經發現了 OOM 處理的理論缺陷，但因為當時團隊缺乏可重現的 RCE 向量，加上任何修復都牽涉到向後相容性、可能引發阻斷服務，或是需要大幅改動第三方擴充套件，導致全靠共識決策的小型核心團隊陷入長達數月的決策僵局。直到今年藉由 Patch the Planet 計畫，AI 輔助研究直接端出了未認證的可用漏洞利用鏈，才讓問題被列為最高優先級。這也印證了我常說的：沒有足夠的專職工程資源，底層架構債就會一直拖到變成全球災難。 11 00:10:17.740 --> 00:11:07.640 既然提到 AI 在資安上的雙面刃效能，Anthropic 今天剛好發布了一篇非常有意思的研究報告，探討如何利用 Claude 來縮小程式碼的「攻擊面」。他們不主張單純去大海撈針找單一 Bug，而是透過 Claude 進行三階段分析：找出預設組態下非必要的暴露路徑、偵測組態互相衝突導致防禦失效的邊界條件，以及把敏感程式碼往後移，從未認證推到已認證階段。他們在 25 個開源專案中找出了 493 個非必要的曝險點！ 12 00:11:07.640 --> 00:12:16.230 這篇報告的案例研究非常扎實，特別是針對 OpenSSH 的審查。OpenSSH 已經是公認審查最嚴苛的 C 專案之一，但 Claude 在 10.4 版本中發現，即便管理者沒有啟用後量子簽章演算法 ML-DSA-44，其相關的 4500 行實驗性程式碼依然在連線認證前就能被未經授權的客戶端觸發解析。更細緻的是，當 OpenSSH 在 10.5 試圖修復時，Claude 還抓出了型別字串偽造以及 CA 簽章驗證缺乏白名單門禁的深層邊界問題，最終促成了 10.6 的完整重構。這種在靜態解析與動態追蹤之間收緊「可達性」的方法，確實比單純找記憶體錯誤更能從架構上減輕負擔。 13 00:12:16.230 --> 00:13:02.110 不過 Hacker News 上的工程師們也忍不住吐槽，Anthropic 自己對網路安全的嚴苛審查機制，常常讓正當防禦者碰壁。許多開發者反應，當他們嘗試讓 Claude 或 ChatGPT 協助驗證本地安全性修補或產生防禦測試時，模型常常無端觸發「安全護欄」拒絕回應，反而是攻擊者轉向無審查的開源模型長驅直入。防禦者如果無法流暢使用這些工具，AI 賦能防禦的美意就會大打折扣。 14 00:13:02.110 --> 00:13:54.850 這是目前各家大模型 API 面臨的嚴肅矛盾。把資安能力的門檻鎖得太死，結果就是白帽工程師在緊急修復漏洞時被自己的工具卡死。說到基礎信任架構的崩塌，昨天我們才在節目中提到 eMudhra 中繼 CA 私鑰崩潰的荒謬慘劇，今天資安專家 Scott Helme 就釋出了完整的技術還原文章《Eight Bits of Trust》，揭露這家合格憑證機構的私鑰究竟有多離譜——竟然直接就是單一位元組的整數，他在筆電上只花了幾毫秒就全部暴力破解！ 15 00:13:54.850 --> 00:14:47.110 這篇分析看得人目瞪口呆。在 P-384 橢圓曲線演算法中，私鑰應該是一個 384 位元的超大隨機數，但在 eMudhra 簽署的八組中繼憑證中，私鑰竟然只有一個位元組有效值，前 47 個位元組全部是零！Scott 測出的私鑰數值竟然是 4、56、115 這種個位數或百位數。這意味著任何人只要算個幾十次到兩百多次的基點乘法，就能逆向推導出私鑰。而這些中繼憑證甚至還得到了 Sectigo 根憑證的交叉簽署，讓全球信任鏈全面大開後門！ 16 00:14:47.110 --> 00:16:13.670 Scott 指出這件事「無法被遏制」的核心在於非瀏覽器生態系。現代瀏覽器有 Certificate Transparency 和 CRLite、OneCRL 的即時黑名單機制，所以 Chrome 和 Firefox 能迅速封鎖。但成千上萬的伺服器後端呼叫、Python 的 requests、Node.js、Go、嵌入式 IoT 設備、甚至 `curl | sh` 的安裝腳本，它們往往依賴系統靜態的 CA bundle，根本不檢查憑證吊銷清單，也不驗證 CT log。Scott 在本地實測偽造 `api.stripe.com`，curl 和各大程式語言全部顯示憑證有效。這代表只要有中間人網路能力，攻擊者可以在未來十幾年內任意攔截解密未更新設備的流量。這種 HSM 儀式腳本的人為失誤，簡直是把整個網路公鑰基建當兒戲。 17 00:16:13.670 --> 00:17:01.920 看完這些沉重的基礎架構漏洞，我們來轉換一下心情，看看 AI 在科學研究領域的正面突破。OpenAI 今天與 PerturbAI 以及 Scripps 研究所聯合發表了一項成果，他們利用數千個由 GPT-Rosalind 驅動的 AI Agent，在短短 32 分鐘內分析了數百萬個小鼠腦細胞的 CRISPR 基因擾動資料庫，試圖尋找阿茲海默症與帕金森氏症的新線索，並建立了跨領域的「生物推理圖譜」。 18 00:17:01.920 --> 00:18:05.770 這項研究的核心在於「分散式生物推理」。以往要分析一個全腦 CRISPR 圖譜，人類專家面對上千種基因敲除與對應的百萬細胞反應，往往只能把精力集中在訊號最強的少數顯著基因上，整體梳理可能要花上幾個月甚至一年。OpenAI 的架構是為每個基因突變指派一個專屬 Agent，平行化讀取單細胞表現數據、跨文獻比對上萬篇論文並提出因果假說。實驗顯示，比起讓單一 Agent 處理整份資料，分散式架構引用了超過 700 篇文獻，而單一 Agent 到了後期只查了 11 篇，盲測下人類專家有 75% 的機率偏好分散式 Agent 的深入分析。 19 00:18:05.770 --> 00:18:54.970 但社群的評價其實相對冷靜，甚至有人質疑這又是公關宣傳大於實質突破。例如論文中提到 DCTN1 基因與膽固醇代謝的關聯，雖然專家認可具備新穎性，但許多生物學家指出，提出假說在生物醫學界向來不是瓶頸，實驗室的博士生每天都能產出幾十個合理的假說；真正的瓶頸是昂貴的試劑、漫長的動物實驗以及臨床試驗驗證。AI 可以加速文獻整合，但在實體科學裡，沒有濕實驗室的閉環驗證，這些假說離真正的疾病治癒依然有非常遙遠的距離。 20 00:18:54.970 --> 00:19:38.010 沒錯，這正是計算科學與實體科學的本質差異。在純數學或寫程式碼的領域，驗證成本極低，編譯器或證明器跑一下就知道對錯；但生物學是一個複雜的熱力學與動態生化系統，充斥著雜訊與個體差異。如果無法大幅降低濕實驗的驗證週期，產出再多高品質的假說，最終也只能堵在臨床前研究的瓶頸前。不過，能用 32 分鐘完成原本需要數百人天的文獻初篩，工具本身的輔助價值確實無庸置疑。 21 00:19:38.010 --> 00:20:26.490 接著來關注一則雲端與商業版圖的大地震：OpenAI 正式宣布，其前沿模型與 Codex 代理工作流將登陸 Google Cloud 的 Model Garden！企業用戶將可以直接使用 GCP 的支出承諾來購買並呼叫 OpenAI 模型，甚至未來還能整合進 Google Antigravity 與 Gemini Agent。這項合作讓整個業界感到意外，畢竟微軟一直是 OpenAI 的核心戰略夥伴。 22 00:20:26.490 --> 00:21:36.730 這雖然看似震撼，但在雲端商業邏輯上非常合理。雖然公告結尾特別加了一句「微軟依然是 OpenAI 的主要雲端夥伴」，但對 OpenAI 來說，他們需要更龐大的推論收入來支撐高昂的研發成本，而許多大型傳統企業的預算早已綁定在 AWS 或 GCP 的年度最低承諾消耗中，如果不進駐這些平台，OpenAI 就吃不到這塊肥肉。至於 Google Cloud，主管 Thomas Kurian 的思維一向務實，GCP 要跟 AWS Bedrock 競爭，就不能只靠自家 DeepMind 的 Gemini，平台必須提供所有頂級選項，把客戶的雲端預算留在 Google 基礎設施上才是最實在的算盤。 23 00:21:36.730 --> 00:22:13.150 這也證明了模型本身的護城河正在被推論基礎設施的便利性所攤平。而談到高吞吐的推論基礎設施，今天 GitHub Trending 上最亮眼的明星非 vLLM 莫屬，星標數已經突破了 94,000 顆大關！作為開源社群最受歡迎的 LLM 部署與推論引擎，vLLM 幾乎成了現代 AI 服務的底層標準配備。 24 00:22:13.150 --> 00:23:27.180 vLLM 的地位之所以無可撼動，關鍵在於它從柏克萊 Sky Computing Lab 發跡時所奠定的 PagedAttention 架構。傳統 LLM 推論最浪費記憶體的就是 KV Cache，動態長度造成大量的記憶體破碎化；PagedAttention 借鑑了作業系統的虛擬記憶體分頁機制，將 KV Cache 切割成固定大小的 page，極大化了記憶體利用率與連續批次處理能力。再加上後續整合的 FlashAttention、FlashMLA、推測解碼，以及對 FP8、NVFP4 等各種量化格式的原生支援，讓它在伺服器端的高併發場景下具備了極高的性價比。它已經是開源生態系對抗閉源 API 壟斷的最核心基石。 25 00:23:27.180 --> 00:24:13.300 在開源模型的應用端，今天 LocalLLaMA 社群熱烈討論的焦點，是 Recursive 團隊推出的全新混合專家模型 Flint！這是一個總參數 40B、每次推論僅啟動 2.5B 的 MoE 程式碼模型，而且完全開源了權重，採用 Apache 2.0 授權。在評測中，它在 SWE-bench Verified 拿下了 74.2% 的高分，甚至在終端基準測試中直逼專用頂級模型。 26 00:24:13.300 --> 00:25:19.280 Flint 的架構設計非常耐人尋味。總共 49 層中，只有前 2 層是密集層，後面 47 層全是 MoE；在注意力機制上，它採用了 35 層 512 token 的滑動窗口，搭配 14 層全局注意力，這顯然是為了兼顧長文本解析與極致的推論速度。最特別的是它每層有 256 個路由專家，每個 token 選取 6 個，外加一個常駐的共享專家。這種極度稀疏化的設計，讓它在維持強大編程推理能力的同時，能以極低的活化參數在單張消費級或伺服器級 GPU 上飛快運行。這對於想要自架本地編程 Agent、又擔心隱私外洩的開發團隊來說，是個極具吸引力的生力軍。 27 00:25:19.280 --> 00:26:05.630 開源模型與推論引擎的進步，讓個人與企業在本地處理資料的能力越來越強。而說到本機高效能分析，今天資料庫領域也有一個歷史性的里程碑——DuckDB 正式推出了 2.0.0 LTS 長期支援版本，代號「Cinnamon Teal」！距離 1.0 的發布不到兩年，DuckDB 2.0 帶來了近兩萬次 commit 的龐大更新，正式從一個嵌入式分析引擎，進化為功能全面的全方位現代資料系統。 28 00:26:05.630 --> 00:27:20.370 DuckDB 2.0 這次的技術升級非常扎實。首先是正式支援非同步 I/O，這讓讀取 Parquet、CSV 和本地原生格式時，I/O 排程能與運算管線完全解耦，多個請求同時在線，社群回報在 EC2 高核心數機器上進行大規模 S3 運算時，CPU 利用率能一路線性擴展到近兩百核，處理數十億筆資料的比對時間直接縮短到十分鐘內。其次是把半結構化資料的 VARIANT 型別扶正為一等公民，底層具備自動切碎與向量化執行能力，讀寫效能遠超傳統 JSON 字串。最後，他們的 Quack 通訊協定與 CONNECT 語法，讓 DuckDB 能無縫切換到遠端伺服器架構，甚至把查詢直接下推給遠端的 Postgres 或 MySQL。 29 00:27:20.370 --> 00:28:24.700 更貼心的是，DuckDB 2.0 還針對現代開發環境加入了「Agent 模式」！當 CLI 偵測到自身是由 Claude Code、Cursor 或 Codex 等 AI Agent 驅動時，它會自動放棄傳統的美化邊框，改為輸出緊湊的 Markdown 表格、以 JSON 回報錯誤，並在長查詢前預估成本，直接減少了 59% 的 token 消耗。此外，他們還放棄了歷史悠久的 Bison 語法解析器，全面改用 PEG 解析器，讓擴充套件可以自由掛載客製化 SQL 語法。這種對開發者與現代工作流的敏銳度，難怪會成為資料工程師的最愛。 30 00:28:24.700 --> 00:29:09.870 從技術架構來看，PEG 解析器的替換具有深遠意義。傳統 LALR(1) 語法在新增語法時極容易引發 shift-reduce 衝突，而 PEG 具備優先順序排序的特性，完全解決了語法擴充時的歧義問題，這跟 Python 當年升級 3.9 時換用 PEG 解析器的動機如出一轍。DuckDB 還在此版本加入了觸發器（Trigger），讓增量維護物化視圖成為可能，實用性大增。 31 00:29:09.870 --> 00:29:58.820 在節目的最後，我們把視角拉回到前端開發者每天都在接觸的領域。知名前端導師 Josh W. Comeau 發布了一篇長文，列出他心目中 Interop 2027 最值得期待的十個 CSS 未來特性。隨著跨瀏覽器相容性計畫 Interop 的持續推動，現代 CSS 的發展速度簡直像是坐上了火箭，許多以前必須靠龐大 JavaScript 函式庫或 SASS 編譯器才能達成的效果，現在都逐步被瀏覽器原生吸收。 32 00:29:58.820 --> 00:31:22.310 清單裡有幾個提案確實直擊前端長年以來的痛點。第一名就是 CSS 原生函式 `@function`，允許開發者定義具備參數與回傳值的樣式邏輯，例如極座標轉換或漸層模板，完全不需經過編譯工具；還有為了解決彈出式選單與提示框方向問題的「錨點容器查詢」（Anchored Container Queries），能在 Tooltip 翻轉到元素下方時動態改變小箭頭樣式；另外像是 `interpolate-size` 解決了數十年來無法將 `height: auto` 平滑過渡展開的頑疾，以及 `reading-flow` 讓網格排列在響應式變化時，鍵盤 Tab 焦點能依照視覺順序而非 DOM 順序瀏覽，大幅改善無障礙體驗。這些特性一旦在所有瀏覽器普及，前端的 JavaScript 負載將能顯著下降。 33 00:31:22.310 --> 00:32:29.000 不過社群裡也有不少老牌工程師感嘆，CSS 正在變得越來越像一門複雜的圖靈完備程式語言，各種複雜的邊角與幾何控制像是 `corner-shape`、`border-shape` 雖然強大，卻也讓瀏覽器引擎的複雜度爆炸性成長。但無論如何，能夠以原生的方式寫出簡潔、高效且不需要一堆 polyfill 的網頁介面，對使用者體驗絕對是好事一樁。今天我們從最底層的 C 語言記憶體漏洞、私鑰災難，聊到上層的 Agent 生態、推論架構與現代樣式標準，技術世界總是在混亂與進步中不斷迭代。感謝大家的收聽，DAVID888 Daily 每日放送，我們明天同一時間再見！