2026 年 10 月 21 日資安風暴：LiteLLM 遭供應鏈攻擊、HTTPS 憑證失守，PHP 與 Node.js 緊急修補

一天之內，網際網路真的壞掉了嗎？

2026 年 10 月 21 日，全球資安社群接連傳出多起重大安全事件。從 HTTPS 憑證信任體系、Python AI 開發套件，到 PHP、Node.js 與雲端部署平台，幾乎涵蓋現代網站從開發到正式營運的整條技術鏈。

社群媒體甚至出現「THE INTERNET BROKE TODAY」的說法，將這一天描述為網際網路安全史上的重大轉折。

但首先必須釐清：這不是一場已證實的全球網路癱瘓，也沒有證據顯示所有事件由同一個攻擊組織策動。

真正值得關注的，是多個不同層級的安全防線，在相近時間內暴露出各自的弱點。

這些弱點包括：數位憑證可能被偽造、官方軟體發布管道可能被劫持、程式語言執行環境存在記憶體安全問題，以及託管平台保存的機密資訊可能遭到存取。

對一般使用者而言，這些技術名稱或許陌生；對網站經營者、AI 開發團隊與企業資訊部門而言，卻可能直接影響服務的可信度與安全性。

一、LiteLLM：攻擊者沒有修改你的程式，而是污染你信任的官方套件

這波事件中，最值得 AI 產業警惕的案例之一，是 LiteLLM 1.107.0 供應鏈攻擊。

LiteLLM 是一套協助開發者整合不同大型語言模型 API 的 Python 工具與代理服務。開發團隊可以透過它統一管理模型呼叫、API 金鑰、流量與成本，而不必為每一家模型供應商重新撰寫完整的整合邏輯。

問題在於，這類工具通常處於 AI 系統的核心位置。

它可能接觸 OpenAI、Anthropic 或其他模型供應商的 API 金鑰，也可能取得資料庫連線資訊、雲端平台憑證，以及應用程式執行環境中的敏感設定。

一旦這個核心元件遭到污染，攻擊者便可能透過單一套件接觸多個原本互不相關的服務。

官方發布流程如何遭到劫持？

根據 LiteLLM 於 10 月 21 日發布的事件說明，攻擊者利用遭入侵的開發者 GitHub 憑證操作發布流程，讓惡意版本 1.107.0 進入 PyPI 與 Docker 映像儲存庫。

官方指出，事件涉及三組開發者 GitHub 憑證，攻擊者不僅修改發布工作流程，還利用其他帳號完成核准，並嘗試刪除部分工作流程紀錄。

這意味著攻擊並非單純上傳一個名稱相似的假套件，而是利用合法專案原有的發布管道，讓使用者下載到看似可信的官方成品。

更令人警惕的是，官方 GitHub 原始碼標籤並不包含那些惡意檔案。遭污染的是實際發布的編譯套件與容器映像。

換句話說，即使開發者檢查了公開原始碼，也不代表下載的安裝成品必然與原始碼一致。

惡意程式會做什麼？

安全研究指出，遭污染的 Python wheel 套件加入了能在 Python 啟動階段執行的額外檔案。

其中一部分負責蒐集憑證與環境機密，另一部分則提供從遠端取得並執行程式碼的能力。

這類設計尤其危險，因為惡意行為不一定需要應用程式主動呼叫 LiteLLM 的功能。只要相關啟動機制被載入，就可能觸發攻擊程式。

對 AI 服務而言，潛在風險包括 API 金鑰外洩、雲端權限遭濫用、資料庫密碼暴露，以及後續的橫向入侵。

官方確認的暴露時間

LiteLLM 公告指出，PyPI 上的 1.107.0 惡意 wheel 於 10 月 21 日 11:39 至 13:23 UTC 之間可被取得。

Docker Hub 的受影響標籤則在 11:46 至 14:20 UTC 之間指向遭污染的映像。

除了明確的 1.107.0 標籤，當時的 latest、main-latest 與 main-stable 等可變動標籤也受到影響。

官方已撤除或重新指向相關成品，並建議曾執行受影響版本的使用者將執行環境視為可能遭到入侵，重新建立乾淨環境並輪替可存取的機密資訊。

這不是只要降級套件就能完全解決的問題。若金鑰已經被讀取，移除惡意程式並不會讓洩漏的金鑰重新變得安全。

二、eMudhra：當 HTTPS 的信任根基出現裂縫

另一個影響層級截然不同的事件，來自印度數位憑證機構 eMudhra。

一般人在瀏覽器看到網址列上的 HTTPS，通常會認為網站與伺服器之間的連線受到加密保護。

然而，HTTPS 不只需要加密演算法，也需要一套確認網站身分的信任機制。

這就是公開金鑰基礎設施（PKI）與憑證授權機構（CA）的角色。

瀏覽器透過受信任的根憑證與中繼憑證，確認某張網站憑證是否由具備授權的機構簽發。

問題不是加密演算法被破解，而是私鑰太容易猜

Google Chrome 安全團隊於 10 月 20 日說明，研究人員在 10 月 17 日通報八張 eMudhra 中繼 CA 憑證的私鑰存在重大問題。

這些私鑰在產生時使用了不足的隨機性，使得攻擊者可能從公開資訊快速推回私鑰。

印度 CERT-In 的公告進一步指出，受影響的 P-384 橢圓曲線私鑰數值竟小於 256。

這件事在密碼學上極不尋常。

P-384 的安全性建立在極大規模的私鑰搜尋空間上。若實際使用的私鑰只落在極少數可能值之中，即使演算法本身沒有被攻破，攻擊者仍能以極低成本找出正確答案。

可以把它理解為：保險箱使用了非常堅固的鎖，但管理者把密碼設定成幾個極容易猜中的數字。

問題出在金鑰生成與管理，而不是 P-384 這項密碼學技術突然失效。

為什麼中繼 CA 私鑰外洩如此嚴重？

網站憑證的私鑰外洩，通常首先危及特定網站。

但中繼 CA 私鑰具備簽發下層憑證的能力，風險層級更高。

若攻擊者掌握受信任中繼 CA 的私鑰，理論上可能製作能冒充其他網站的憑證，並試圖讓尚未封鎖相關 CA 的用戶端接受這些憑證。

不過，成功冒充網站還涉及網路流量控制、用戶端信任狀態等其他條件，不能直接推論所有 HTTPS 連線都已遭到攔截。

Google 如何處理？

Google 表示，Chrome 團隊在收到通報後快速確認問題，並透過 CRLSet 機制封鎖受影響中繼 CA 的公開金鑰識別資訊。

這種處理方式可以讓 Chrome 使用者在不必手動更新瀏覽器或重新啟動的情況下，取得相關信任撤銷保護。

另一方面，eMudhra 表示事件涉及特定中繼 CA，並未發現其根 CA 私鑰遭到入侵。該公司也稱受影響中繼 CA 並未簽發終端實體憑證。

因此，應將已確認的「中繼 CA 私鑰不安全」與尚未證實的「大規模網站冒充已經發生」分開看待。

三、PHP2Shell：網站後端的記憶體安全問題

PHP 是長期廣泛使用的伺服器端程式語言，支撐大量內容管理系統、電子商務網站與客製化網頁服務。

10 月 21 日，PHP 公開兩項重大漏洞：CVE-2026-109618 與 CVE-2026-109619。

加拿大網路安全中心與英國 NHS England 的資安公告指出，這兩項問題涉及記憶體生命週期管理，可能讓未經驗證的攻擊者在特定條件下執行遠端程式碼。

Cloudflare 也確認已部署相關 WAF 防護規則。

Use-After-Free 是什麼？

程式在執行時，會向作業系統或執行環境申請記憶體，用來儲存資料與處理請求。

當某塊記憶體不再需要，系統便可能將它釋放，供其他操作重新使用。

Use-After-Free（釋放後使用）指的是程式仍然存取已經被釋放的記憶體。

若攻擊者能控制記憶體內容與程式執行時機，就可能利用這種錯誤干擾正常流程，造成服務崩潰、資料暴露，甚至在符合利用條件時執行惡意程式碼。

這類漏洞與一般 SQL Injection 或跨站腳本攻擊不同。它不是單純把危險字串送進資料庫或網頁，而是利用執行環境對記憶體狀態的錯誤假設。

是否代表所有 WordPress 網站都能被入侵？

不能如此推論。

Cloudflare 指出，相關問題涉及 PHP 5.4 之後的伺服器環境，且可能透過特製 HTTP 流量觸發。

但「使用 PHP 的網站很多」不等於「所有 PHP 網站都能被同一種攻擊直接入侵」。

實際風險仍取決於 PHP 版本、修補狀態、部署架構、流量是否能觸及漏洞條件，以及其他安全防護措施。

因此，社群流傳的「70% 網站全部受到直接威脅」並不是可以從現有官方公告直接得出的結論。

網站管理者應優先確認伺服器使用的 PHP 版本，套用 PHP 安全團隊提供的修補版本，並將 WAF 視為額外防護，而非取代更新的永久方案。

四、Node.js：DNS、TLS 與壓縮元件同時修補

Node.js 是現代 JavaScript 後端的重要基礎設施，廣泛應用於 API 服務、網站建置工具、即時通訊與雲端應用。

10 月 21 日，Node.js 專案針對 22.x、24.x 與 26.x 分支發布安全更新。

官方列出的修補版本分別為 Node.js 22.23.4、24.22.1 與 26.12.1。

此次更新涵蓋 DNS 輸入處理、TLS 憑證主機名稱驗證、Brotli 壓縮相關元件，以及其他相依套件的安全問題。

其中，CVE-2026-105482 涉及 DNS 名稱中 NUL 字元的處理；CVE-2026-105483 則涉及使用全形數字表示 IP 位址時的 TLS 主機名稱驗證問題。

另一項 CVE-2026-111497 與 Brotli 相依元件有關，也被列入安全修補內容。

為什麼 DNS 與 TLS 驗證錯誤值得關注？

許多應用程式不只接收使用者輸入，也會依據輸入內容連線到其他服務。

例如，網站可能允許使用者提供圖片網址、Webhook 位址或外部 API 端點。

若程式對主機名稱的解析結果與安全檢查結果不一致，就可能讓原本應被拒絕的連線通過某些驗證步驟。

這類問題是否能構成實際攻擊，仍須依照個別漏洞的利用條件判斷，但它們提醒開發者：網址、DNS、IP 位址與憑證名稱的處理方式，都是安全邊界的一部分。

對使用 Node.js 的開發團隊而言，最直接的工作是確認正式環境實際執行的版本，而不只是檢查 package.json。

容器基底映像、CI 建置環境與正式部署平台，可能各自使用不同的 Node.js 版本。

五、Railway：雲端平台的環境變數也可能成為攻擊目標

10 月 21 日，雲端部署平台 Railway 公開一份安全事件說明，表示偵測到涉及客戶環境變數儲存系統的異常活動。

Railway 指出，調查顯示未授權第三方可能存取了部分加密環境變數，並取得其中部分資料的解密內容。

環境變數經常被開發者用來保存資料庫密碼、API 金鑰、服務憑證與第三方整合設定。

這些資料通常不會直接寫入公開原始碼，但它們仍然必須在應用程式執行時被讀取。

因此，將機密資訊放入環境變數，並不代表它們不可能外洩。

為什麼輪替金鑰比單純修改程式重要？

假設攻擊者已取得某個資料庫密碼，即使平台之後阻止新的未授權存取，舊密碼仍可能繼續有效。

因此，Railway 建議使用者輪替儲存在平台上的環境變數與相關憑證，並檢查服務日誌是否存在異常操作。

10 月 22 日，Railway 進一步說明已主動重設部分儲存空間憑證與 GitHub 連線權杖。受影響使用者可能需要重新部署服務、重新連接 GitHub，並更新私有容器儲存庫的認證資訊。

這也顯示資安事件的善後不只涉及阻止攻擊，還包括恢復正常部署能力，以及確認舊憑證是否曾被濫用。

六、這些事件有沒有共同的攻擊者？

目前沒有足夠公開證據證明上述所有事件屬於同一場協調攻擊。

LiteLLM 是軟體發布供應鏈遭到劫持；eMudhra 是憑證金鑰生成安全失敗；PHP 與 Node.js 涉及程式碼漏洞修補；Railway 則是平台機密資料可能遭未授權存取。

它們的技術根因、受影響對象與攻擊條件並不相同。

將這些事件放在同一篇新聞中，是因為它們共同反映現代軟體基礎設施的信任問題，而不是因為已證實存在單一幕後主使者。

對於同時在社群流傳的其他 GitLab、Plex 與個別資料外洩指控，仍應等待可核對的官方公告、CVE 紀錄或可信調查報告，不宜僅憑截圖與轉貼內容判定受影響範圍。

七、真正的危機：軟體系統的安全建立在一連串信任之上

從使用者在瀏覽器輸入網址，到 AI 應用程式成功回傳答案，中間可能經過多層彼此依賴的系統。

瀏覽器信任憑證機構，開發者信任套件儲存庫，CI/CD 平台信任開發者身分，雲端應用信任環境變數，而後端程式又信任執行環境與相依套件。

其中任何一層出現問題，都可能讓原本設計完善的其他安全措施失去效果。

LiteLLM 案例說明，原始碼安全不代表發布成品安全。

eMudhra 案例說明，密碼學演算法安全不代表金鑰生成程序安全。

PHP 與 Node.js 的漏洞提醒我們，即使是成熟、廣泛使用的技術，也仍需要持續維護。

Railway 事件則說明，將密碼移出原始碼只是機密管理的第一步，並非終點。

八、開發者現在應該做什麼？

第一，盤點實際使用的軟體版本與相依套件，尤其是自動更新、未鎖定版本與使用 latest 標籤的部署。

第二，若曾在官方確認的受影響時間內執行 LiteLLM 1.107.0，應依官方事故應變指南處理，並評估所有可存取金鑰的暴露風險。

第三，使用 PHP 或 Node.js 的服務應儘速確認修補版本與正式環境部署狀態，不要只完成程式碼修改卻忽略伺服器執行環境。

第四，Railway 使用者應依官方建議輪替機密資訊，確認 GitHub 連線與儲存空間憑證狀態。

第五，網站管理者應確保瀏覽器、作業系統與憑證信任儲存庫維持更新，避免繼續信任已遭撤銷的憑證鏈。

最後，企業應將軟體成品驗證、最小權限、機密輪替與事故日誌保存納入日常流程，而不是等到發生外洩才開始處理。

結論：網際網路沒有在一天內毀滅，但信任不能再被視為理所當然

10 月 21 日的資安事件並沒有證明全球網際網路已經崩潰。

相反地，官方公告、研究人員通報、瀏覽器封鎖機制與安全修補的快速發布，也顯示網路安全生態系仍在運作。

然而，這一天揭露了一個越來越重要的現實：我們所依賴的安全，不只存在於程式碼裡，也存在於發布流程、憑證管理、第三方平台與每一次授權決策之中。

當 AI 系統開始同時持有大量模型 API 金鑰、資料庫權限與自動部署能力時，軟體供應鏈的安全問題，也正在成為 AI 產業本身的基礎設施問題。

Tech English｜本文技術名詞

1. Software Supply Chain Attack（軟體供應鏈攻擊）：攻擊者透過套件、建置系統或發布流程污染軟體，讓使用者從原本信任的管道取得惡意成品。

2. Certificate Authority, CA（憑證授權機構）：負責簽發與驗證數位憑證的信任機構，是 HTTPS 網站身分驗證的重要組成部分。

3. Cryptographic Entropy（密碼學熵／隨機性）：衡量金鑰生成過程不可預測程度的概念。隨機性不足可能讓攻擊者猜出私鑰。

4. Remote Code Execution, RCE（遠端程式碼執行）：攻擊者透過漏洞讓目標系統執行其指定的程式碼，實際影響取決於執行權限與漏洞條件。

5. Use-After-Free, UAF（釋放後使用）：程式繼續存取已釋放記憶體的錯誤，可能造成崩潰、資料洩漏或更嚴重的安全問題。

6. Credential Rotation（憑證輪替）：撤銷或更換 API 金鑰、密碼與存取權杖，降低已洩漏機密被持續利用的風險。