這是新的網路安全常態嗎？

上週出現大量嚴重且關鍵的軟體漏洞，影響數千個主要網站，令民眾驚慌失措。究竟發生了什麼？我們能做什麼？

漏洞

若想了解目前軟體安全領域的情勢，我們必須先掌握這些漏洞的情況。我不是網路安全專家，會引用外部說明，而非深入討論技術細節，因為專業人士會更擅長說明。

PHP2Shell – CVE-2026-109618 和 CVE-2026-109619（又稱「新聞熱點大漏洞」）

兩支不同的安全團隊，一支來自加州安全公司 Calif（屬於 OpenAI 的「Patch the Planet」計畫），另一支來自以色列-美國雲端安全公司 Wiz（看似屬於 Google Cloud），兩者皆發現 PHP 中的這兩個遠端程式碼執行（RCE）漏洞。他們都使用前沿 AI 模型（即 LLM，具體為 GPT-5.6 Sol/Gemini 4 Argon）來偵測漏洞並構建利用程式。

有趣的是，CVE-2026-109618 這個漏洞是 PHP 基金會於 2024 年進行的 安全審核發現的（由 Sovereign Tech Agency 資助，恰好是目前開源界最有趣的事之一），但他們基本上忽略了，因為他們有更大的關注點，且無法就修復達成共識。原因在於沒有人能真正根據理論問題構造實際利用程式。

LLM 的一項優勢是能將理論安全漏洞（即使描述模糊）轉化為完整利用程式。近幾個月來，這已成為重大問題，因為任何安全補丁公告都會立刻引發人們將 LLM 指向程式碼庫，代理程式可迅速閱讀差異，尋找似乎是安全補丁的內容，然後回溯至其所修補的漏洞，並一路追蹤至利用程式。

事實上，這發生得如此迅速，我認為在你宣佈安全補丁的那一刻，應視為完整利用程式尚未公開或私下散佈的最後可能日期。

這個 PHP2Shell（按其市場推廣方式，漏洞似乎已經附帶自己的行銷團隊）估計影響超過 70% 的網路，涵蓋從 Wikimedia Foundation 到 DeviantArt，再到 英國政府和日本銀行系統的大部分，以及 BBC 節目《The Traitors》網站 等數千個網站。漏洞雖被發現，但通常不會導致半數網路關閉伺服器，究竟發生了什麼？

為瞭解這個情況，讓我們看看 PHP Group 的原始貼文：

有人叫做 petecooper 在 Hacker News 釋出關於 CVE 的訊息，顯然不知道還有禁播。這（以及其他顯示的洩漏）促使 PHP Group 迅速發表宣告，將補丁提前到週三 21 號，原本定於週四 22 號。然而補丁仍未能於第二天前發布。這意外洩漏包含 CVSS 分數 10.0（即 bad，雖然實際分數是 9.2）。

幾乎立即，訊息像野火般傳播，大家開始恐慌。雖然這是由 「負責任的安全研究人員」 在 「值得信賴的公司」 發現的，但安全補丁實際發布時，已經 在野外被利用¹。PHP Foundation 指責 Calif 以及一間叫 Chainguard 的公司，說 Calif 洩露了一段利用過程的影片（配有怪異背景音樂和跳舞的動漫女孩），而 Chainguard 在禁播解除前 6 小時發布修復，兩者都讓攻擊者比系統管理員先一步。時間線很混亂，但看來多個相互關聯的事件在約 17 小時內發生。

關於 AI 是否真的能徹底革新電腦安全，已經有許多 討論。大型 AI 公司（他們很大）顯然想讓你認為它是。有人認為 PHP2Shell 被誇大，因為 LLM 會對漏洞產生偏執，提出「利用」但基於錯誤假設（例如伺服器會執行你透過現有檔案包含漏洞上傳的 PHP 程式碼）或以某種方式作弊。正如 LiveOverflow 指出，LLM 讓創造毫無效用的利用程式變得非常容易，但這並不意味漏洞不真實且易於利用 AI。你可能有 10,000 個無效的利用程式，但只要有一個有效，其他就不重要。也許我們現在只需習慣在大量無效程式中尋找重要的。

其他人指出，許多政府（英國²、歐盟、日本、美國）過度興奮，發布緊急公告說所有人必須立即拔掉電腦，導致人們恐慌。我認為大家恐慌的原因是大家大致知道 PHP 非常不安全，卻仍在使用…

對我而言，最大的收穫是——由於 LLM，從「聽說這個專案有個嚴重的 RCE」到「有精密、全自動、協調的攻擊利用此漏洞」的時間已從幾週/幾個月縮短到幾小時/幾分鐘。大量無效利用程式的存在只是證明仍需要真正的專業知識來完成這些工作——如果你不清楚自己在看什麼，就無法判斷 AI 是否作弊或做了錯誤假設。

連結：

• Hacker News: “告訴 HN：2 份 PHP RCE CVE，CVSS 10.0 來襲” (petecooper, 20 Oct 2026)
• PHP2Shell – 官方網站 – 為什麼現在每個漏洞都需要一個名稱、口號和網站？
• Wiz Research: “PHP2Shell：AI 發現影響 70% 網際網路的關鍵 RCE 漏洞” – 這些是發現漏洞的公司之一。
• PHP News Archive: “Upcoming Critical PHP Security Release” (20 Oct 2026) – 這是 PHP Group 如何宣佈漏洞的方式。請注意時間線。
• Wikipedia: PHP2Shell – 內容不太詳細，但至少他們不打算賣東西給你。
• AWS Security Blog: “Amazon Threat Intelligence identifies PHP2Shell exploitation prior to public disclosure in MadPot” – 他們想賣東西給你，但仍在做一些有趣的分析。

eMudhra (CVE-2026-111943 for Golang response)

在同一天（2026年10月20日），Mozilla 公佈他們正在封鎖由印度憑證機構 eMudhra 簽署的 8 個中間憑證。這發生在僅以「Wayne」為名的化名安全研究人員向多家大型科技公司（如 Mozilla、Apple、Google、Microsoft 等）報告該憑證機構為其中間憑證使用可笑的低品質私鑰之後。若安全鍵可能是 100 位數，eMudhra 卻使用像「115」、「56」和「4」的金鑰。他們一定是在遵循 RFC 1149.5：

沒有跡象表明這是使用 AI 或 LLM 發現或利用的，儘管研究員 Scott Helme 指出，僅憑一次提示，Claude 就能恢復中間憑證的私鑰。

撰寫時（10月23日），eMudhra 宣佈將退出憑證機構領域。與此無關的新聞，一位農民宣佈他已關上馬廄門，因為有馬匹逃跑的報導。

連結：

• Mozilla Security Blog: “Protecting Firefox users following the compromise of eMudhra intermediate certificates”
• Scott Helme: “Eight Bits of Trust; eMudhra’s CA keys cracked in milliseconds”
• eMudhra press release: “eMudhra to Exit global SSL/TLS Certificate Business”
• eMudhra Intermediate CA Compromise – research announcement and trust store checker

Railway 漏洞

第二天，雲服務供應商 Railway 公佈他們發現證據顯示駭客已存取甚至解密其平臺的環境變數，這些變數通常儲存機密資料，如資料庫憑證、API 金鑰等。在其宣告中，他們表示相信這是針對提供 AI 推論服務的公司進行協同攻擊的一部分。

這裡的最終目標會是什麼？撰寫時（10月23日），我們幾乎沒有資訊可參考。這是否是「未經授權的第三方」（官方公告「某些隨機人員闖入我們的電腦」總會把它呈現成服務條款協議，或許他們這樣想人們不會注意）試圖窺探使用 AI 推論的人，觀察他們在做什麼，甚至盜取新模型或研究？或者他們想為自己的邪惡生成 AI 目的（如尋找更多 PHP 漏洞）建立一個被攻陷的推論供應商網路？

連結：

• Railway Blog：『Security Disclosure：星期三 10 月 21 日』
• Hacker News 討論 Railway 安全披露

GitLab（CVE-2026-97229 和 CVE-2026-110264）

於 2026 年 10 月 12 日，GitLab 警告 GitLab CI/CD 的正規表示式解析中存在一個最高嚴重性漏洞，可能允許攻擊者使用特製的正規表示式執行任意程式碼（又一個 RCE）。其 CVSS 分數為 10.0，為最高分，意即「這幾乎是最嚴重的」³。2026 年 10 月 21 日又出現另一個正規表示式整數溢位 RCE，同樣 10.0。

這緊接著上個月又一個 10.0 CVSS CVE（CVE-2026-85706），那次與路徑遍歷有關。這三個漏洞均透過 GitLab 的 HackerOne bug bounty 計畫報告。當人們意識到 LLM 能夠研究漏洞並撰寫利用程式時，曾大量討論關閉 bug bounty 計畫，因為它們已經不再有意義。我相信 GitLab 很高興他們現在沒有這樣做。

雖然 GitLab 在學術界、政府機構及私營企業中被廣泛使用，但似乎並未受到太多關注。GitLab 中的 CVE 顯然非常嚴重，尤其對私營企業來說，因為大量關鍵智慧財產權存放於此，若洩露可能災難性。企業往往將 GitLab 例項置於 VPN/防火牆後，避免公開存取，這大幅降低相關風險。亦不完全清楚這些 CVE 是否需要特定條件，如公開專案、使用者自註冊等。CVE-2026-110264 看似至少需要一個公開專案，但我找不到早期 CVE 的條件資訊。

目前沒有跡象表明這些漏洞是使用 AI 或 LLM 發現的。它們可能是這樣，但目前沒有理由認為是。

連結：

• GitLab 檔案： “GitLab Critical Patch Release: 19.4.2, 19.3.5, 19.2.8”
• GitLab 檔案： “GitLab Critical Patch Release: 19.5.1, 19.4.3, 19.3.6, 19.2.9, 19.1.9, 19.0.10, 18.11.13”
• Hacker News 討論： “GitLab critical patch release”
• BleepingComputer： “GitLab warns of max severity code execution vulnerability”
• Lobsters 討論： “GitLab warns of max severity code execution vulnerability”
• GitLab Security detection rule： Org-mode render error burst
• GitLab Security detection rule： Onigmo native worker crash

musl libc 漏洞

於 10 月 21 日，musl 的 libc 出現與正規表示式相關的漏洞（libc 有正規表示式？顯然…），被宣佈至少會導致拒絕服務，甚至可能執行程式碼。就我所知，這純屬時間上的巧合，與 GitLab 的漏洞無關，兩者皆似乎是解析不受信任正規表示式時的整數溢位，其中一個於同日報告。誰會想到正則引擎會成為如此安全問題——正則是新的字型渲染嗎？GitLab 的漏洞均由瑞典人Johan Carlsson (joaxcar)發現，而 musl 的漏洞則由法國自稱「open sourcerer」的Julien Voisin報告。

連結：

• oss-security: “CVE-2026-107891: musl libc: multiple integer overflow in regcomp”
• Lobsters 討論 musl regcomp CVE

LiteLLM

啊，嗨，我的老朋友 LiteLLM。證明瞭，當你是由金屬製成、身高 200 英尺時，閃電確實能擊中兩次。當有人問你是否聽說過 2026 年的大型 LiteLLM 事件時，你必須問「是哪一個？」這並不是個好兆頭。幸運的是，整個 PHP2Shell 以及其他事件已經吞噬了大部分關注，意味著這次的衝擊並沒有像三月那次一樣受到同等關注，儘管同樣嚴重。

這一次，目標是 Python 套件索引 (PyPI) 和 Docker 映像中的惡意版本。對於不記得的人，LiteLLM 在三月時發生了 非常相似的事情，當時一個惡意套件被上傳到 PyPI 上的 litellm 套件，並使用 .pth files 自動載入惡意程式碼（是的，真的很糟）。

這次的入侵再次利用了 .pth files，並且這次也利用了 sitecutomize.py 檔案來自動載入惡意負載，當 Python 直譯器啟動時即在 preload 階段執行。根據 Wiz 的分析，負載顯示「LLM 協助開發的強烈跡象」——例如過度冗長的變數名稱、過度防禦的錯誤處理、脆弱的邊緣情況，以及所有評論「這裡才是真正的痛點」、「值得坐在那裡」、「深入挖掘」和「那是你的」反覆提及⁴。

根據 LiteLLM，事件發生是因為攻擊者取得了 GitHub CLI 的憑證，允許他們執行 CI 工作。LiteLLM 提到，Claude Code 似乎有時會將使用者的 GitHub CLI OAuth 令牌嵌入回應內容，可能導致其出現在 LiteLLM 日誌中。

連結:

• Wiz Blog: “LiteLLM Compromised, Steals Credentials”
• LiteLLM: “Contained: Oct 21, 2026 LiteLLM release v1.107.0 Compromised”
• Hacker News discussion: “Compromised LiteLLM 1.107.0 on PyPI Installs a Credential Stealer and Backdoor”

PingCAP

2026 年 10 月 19 日，一家名為「PingCAP」的企業軟體公司，開發名為「TiDB」的資料庫，公佈「未授權存取 PingCAP」且「沒有證據顯示 TiDB 中儲存的資料受到影響」。同時，一個網路敲詐組織「FulcrumSec」（又稱「Threatspians」⁵）表示已從 PingCAP 擷取 10.6 TB 資料，並公開釋出一個包含 200 GB 資料的 torrent，作為「第一階段釋出」（你得讓人們投入續集）。

他們還公佈了所取得資料的完整細節以及 PingCAP 的一些優秀安全實踐，包括 將客戶端 AWS 機密存取金鑰放入 Jira 工單 以及 將大量未刪除的日誌附加到 Jira 工單，包括 OpenAI、Anthropic、Gemini、xAI API 金鑰。哇。若你願意造訪該敲詐組織的網站，他們對此進行了相當有趣的說明。已經不再是俄羅斯人必須在沒有 LLM 幫忙的情況下寫出破爛英文、提醒他們使用定冠詞與不定冠詞的日子了。⁶

PingCAP 的好訊息是，找不到資料外流的證據其實非常容易。事實上，我現在正為數千家公司免費執行此項工作。我確信其中某處一定有商業提案。你要做的就是不去看（另見：U+1F648）。公平起見，我認為他們的論點是沒有任何資料 在 TiDB 例項內 被洩漏。若是如此，10.6 TB 看起來是相當多的資料。顯然仍有大量客戶資料。

連結：

• Hacker News 討論：「PingCap TiDB Leaks」
• PingCAP： “October 2026 Security Incident Report: Unauthorized Access to PingCAP Cloud Resources” – PingCAP 對此事件的詳細且高度可靠的分析。
• FulcrumSec： “The PingCAP TiDB Cloud Leaks” – 警告，這是已知網路勒索集團的網站。不要說我沒提醒你。雖然很有趣。

Linux 漏洞不小心貼到錯誤的群組聊天

Linux 核心開發全部透過郵件列表進行。自然，其中一些是關於安全敏感的事項，因此是私有列表。於 2026 年 10 月 21 日至 22 日之夜，Zero Day Initiative（ZDI）——由 Trend Micro 所擁有的軟體漏洞計畫，將一堆高嚴重度（CVSS 9.0 以上）的 CVE 報告釋出到公開郵件列表，而非私有列表。自然，假設任何擁有 LLM 並懷抱夢想的人，都能在幾分鐘內將這些報告轉化為活躍利用。這並不像 Pete Hegseth 不小心將即將在葉門發動的軍事攻擊細節發給 The Atlantic⁷ 那時那麼糟，但人們現在仍然非常重視此事。

連結：

• Phoronix： “Several Linux Kernel Vulnerabilities Accidentally Posted To Public Kernel Mailing List”

這是新的常態嗎？

我認為可以公平地說，這幾天在所有這些網路事件與安全披露方面都異常活躍。許多 Hacker News 討論中的評論者表示這不算什麼，情況只會變得更糟。老實說，我還沒下結論。說實話，若你四年前問我 LLM 會走到哪一步，我絕對沒想到它們會發展到現在這麼好。即便如此，人們往往對這些公告過度興奮，並暗示我們將生活在一個任何軟體都不安全、人人皆易受攻擊的世界。

值得注意的是，雖然許多網路討論聚焦於 AI 與 LLM，但只有部分披露是由 LLM 研究或建立的。我們對像 PingCAP 那樣的案例並不清楚，但有明確證據顯示許多犯罪與國家贊助組織正在使用 AI 進行更頻繁、更快速的駭客攻擊。為什麼不呢？看起來它相當擅長。許多漏洞仍是傳統的軟體漏洞，透過人手編寫發現，但網路對話聚焦於令人興奮、可怕的新事物。為什麼不呢？

你可以看到為什麼像英國國民保健署（NHS England）這樣的組織會決定 將所有開源程式碼私有化（儘管這是個愚蠢的決定）。當這些大型語言模型如此強大，以至於任何人都能將代理指向某段開源程式碼，發現大量漏洞，並為其編寫完整的利用程式，這對許多人來說是令人擔憂的。那麼解決方案是什麼？

我們能做什麼？

NHS 的做法：將所有程式碼關閉原始碼。（又稱 馬達加斯加做法）

優點：

• 你的程式碼不再上線，使用者無法將 LLM 指向它，進行如分析每一次提交以尋找安全修復、發現大量先前未知的關鍵缺陷等操作。

缺點：

• 每個被下線的開源倉庫都會讓開源社群及計算機未來略微受損。
• 你無法將全世界的所有程式碼關閉原始碼——像程式語言（常是關鍵缺陷來源）等，依賴開源才能運作。將 Python 變成封閉原始碼專案將對整個計算機世界造成災難。
• 它只是封閉原始碼，直到有人洩漏。且他們最終很可能會洩漏。當他們洩漏時，你就失去了多年公開審查所帶來的程式碼保持乾淨安全的好處。
• 有時你使用的程式語言並不會真的受到影響，例如 Python 與 Java，你可以從位元組碼還原程式碼。
• LLM 甚至能相當有效地反向工程已編譯的二進位檔。
• 如果程式碼曾經上線，舊版本仍然存在。你必須假設有人會在某處保留它。Shellshock 在 GNU Bash 中從 1989 年到 2014 年被修復之前一直存在，而它是地球上最廣泛使用的程式之一。
• 這讓我很難過 :(

AI 擁抱式做法：若無法擊敗他們，就加入他們。換句話說，如果我們已經用更好的 LLM 更快、更有資金、更優秀的模型在程式碼上執行，他們就無法利用 LLM 發現漏洞。

優點：

• 讓少數極為富有的科技 CEO 非常高興。
• 將發現大量漏洞。

缺點：

• 讓少數極為富有的科技 CEO 非常高興。
• 將發現大量漏洞。（有人必須修復它們。）
• 成本龐大。
• 儘管 AI 使事情更容易，但仍需專業知識與深厚技術才能妥善執行（目前而言）。

樂觀主義做法：普遍更優、標準化的漏洞報告、處理與緩解方法，並使所有公司皆具備頂尖安全姿態、充分理解風險、完善檔案流程等。

優點：

• 好主意。
• 為什麼沒有人想到這個？
• 哇，我們真聰明。難道我們已經解決了嗎？

缺點：

• 我們不在這個世界裡。永遠不會。
• 我有提到這其實相當困難？甚至可能不可能？
• 昂貴。

未來我們可以從這裡取得一些簡單的勝利，例如「在補丁準備好安裝之前，永遠不要公佈關鍵漏洞的細節」，但在這個案例中，無意的洩漏使得每個人都在官方公告之前就知道了漏洞。也許這已經要求太多。在這種情況下，來自多個人和公司的系列錯誤導致或加速了利用程式在補丁可用前就已被活躍使用，因而大家都把伺服器下線。AWS 之後表示，他們在10月17日就看到有人嘗試利用此漏洞，早於任何洩漏發生。

即使是像最小釋出年齡這樣的概念，在 shalk/debug、Shai-Hulud 以及 March LiteLLM 事件後變得流行，因為它意味著大型更新修復廣泛被利用的漏洞會延遲幾天，給攻擊者足夠時間將你拆解。至少，我們也許可以透過更好的客戶端管理，避免大家恐慌並把所有伺服器下線。

也許我們只需要接受，若將某事暴露於更廣泛的網路，便會被駭入，並相應地做規劃。也許是我們的期望出了問題。

結論

這裡確實有一段關於 AI 與安全的故事。它正在改變軟體世界，尚不清楚這是好還是壞。金錢像物質扭曲時空一樣，會扭曲真相，而 AI 中的資金足以造成等同於中等質量黑洞的真相效應。AI 正在投入巨額資金，並且它們都想讓你認為它將改變你生活中的一切，包括軟體與安全。這並不代表它不是真的，當然。

有人說自動化分析工具在 2010 年代導致大量新漏洞被發現，而現在同樣的情況再次發生。對我來說，感覺完全不同，但也許會有一段初期的漏洞報告激增，之後才會平息並回到以前的狀態。我懷疑不是。有人說這只因為人類最初寫了所有可疑程式碼——一旦 AI 一開始就寫所有程式碼，將不會有漏洞，因為 LLMs 在寫安全程式碼方面比人類更好。我不被這個論點說服。

雖然我不會對未來做太多預測（因為我不想在 12 個月後因不可避免地被證實錯誤而顯得像個傻瓜），但我會說軟體產業將會改變，開源也會改變，我們作為軟體社群成員的共同責任是確保這種變化對我們所有人都有利，而非僅為特殊利益和私人企業服務。

更新

這是一則正在發展的故事——我會在此記錄任何更新。我寫這篇文章時略顯匆忙，之後可能會對部分措辭和證據做逐步改進。

腳注

1. 有關是否在補丁發布前有人進行過實際、可行的利用嘗試，存在一些討論和分歧。↩

2. 免責宣告：我有點在英國政府工作。↩

3. GitLab 正在使用 CVSS 3.1，而 PHP 在此使用 CVSS 4.0，這表示它們採用略有不同的指標來計算 CVSS 分數，因而無法直接比較。↩

4. 好吧，或許不必提到最後一點。↩

5. 若這些可恥的罪犯終究受到司法審判，我提議對他們最長的刑期應針對其對文字遊戲的犯罪。實在是可怕。↩

6. 澄清一下，沒有證據表明這個團體是俄羅斯駭客。他們似乎主要以財務動機為主，因此可能來自任何地方。你明白我的意思——往昔，你可以藉由他們的語法怪異來辨識俄羅斯釣魚活動。如今，因 AI 的影響，這一切魅力已全失。↩

7. 幸好，作為一位正直且可信賴的公民，他根據國家最佳利益而非個人忠誠或對總統個人議程的虔誠，確保所有 那些 負責人 被迅速 移除 離開 他的行政團隊，從此不再出現在華盛頓。↩