同一週的修補潮：eMudhra 憑證、LiteLLM 投毒與 Railway 環境變數外洩，開發團隊的處理順序

文／Laban（優創智能 AI 導入工程師）

「修補潮」指的是多個語言執行環境、套件與平台在同一段時間內各自發布安全更新，讓開發團隊必須同時判斷、排序與驗證。結論先講：2026 年 10 月 19 日至 22 日這一波，最該先處理的不是分數最高的 CVE，而是「你已經裝過、已經被利用、或金鑰已經可能外流」的項目。LiteLLM 1.107.0 遭投毒與 Railway 環境變數外洩屬於這一類；憑證信任鏈則在同週出現三方調整：certifi 與 Node.js 點名 eMudhra，Go 封鎖一組未具名的中繼憑證，升級前要先確認自家服務的憑證。

本文分三部分：官方公告中的已知事實、我們的編輯分析，以及開發團隊可以照做的六個步驟。每一項都附官方來源；查不到官方原文的數字，本文一律不寫。

一、已知事實：10 月 19 日至 22 日的官方公告

以下資料截至 2026 年 10 月 30 日，日期以各官方公告為準。

1. 憑證信任鏈：Node.js、Python、Go 同週調整

• certifi：GHSA-6q48-6c7w-9gw2（2026-10-20）指出，2026.10.18 之前的 certifi 內含 emSign ECC Root CA - G3 根憑證，其下有八張 eMudhra 中繼憑證的私鑰已遭洩漏，持有私鑰者可以為任何網域簽出看似有效的憑證。certifi 2026.10.18 移除了所有 emSign 根憑證，2026.10.19 再補回未受影響的部分。公告建議升級到 2026.10.19 以上，並重建內含 certifi 的容器映像檔。公告點名的受影響用戶端包含 requests、urllib3、pip。
• Go：golang-announce（2026-10-20）宣布 Go 1.27.3 與 1.26.10，crypto/x509 封鎖「一小組中繼憑證」，Verify 會過濾掉含這些中繼憑證的鏈。Go 漏洞資料庫 GO-2026-6809 列出受影響範圍為 go1.26.10 之前，以及 go1.27.0 至 go1.27.3 之前。Go 官方沒有點名是哪一家憑證機構，也沒有給 CVSS 分數，只說「強烈建議立即升級」。
• Node.js：10 月安全更新的相依套件更新裡，列有「ca-cert (eMudhra Intermediate CA Compromise)」，三個支援分支都有。

2. 執行環境與平台修補

• Node.js（2026-10-21）：修補 10 個 CVE，4 個 High、3 個 Medium、3 個 Low，官方寫「本次修補的最高嚴重等級為 HIGH」。High 項目包含 Brotli 解碼器的越界寫入（CVE-2026-111497）與數個 TLS／DNS 驗證繞過。修補版本為 v26.12.1、v24.22.1、v22.23.4；官方提醒已停止支援的版本在每次安全更新時都會受影響。
• CPython tarfile（2026-10-22 轉發至 oss-security）：Python 安全公告指出 CVE-2026-114583 為 MEDIUM 等級，特製的連結項目可繞過 tarfile.tar_filter，讓 extractall(filter="tar") 把檔案寫到目標資料夾之外。
• GitLab（2026-10-21）：緊急修補版涵蓋 19.5.1、19.4.3、19.3.6、19.2.9、19.1.9、19.0.10、18.11.13，共 12 個安全修補（1 個 Critical、2 個 High、5 個 Medium、4 個 Low）。CVE-2026-110264 是正規表示式編譯器的整數溢位，CVSS 10.0，官方說它「可能讓未登入的使用者在 GitLab 伺服器上執行任意程式碼」。官方沒有提供暫時緩解方法，只建議盡快升級；GitLab.com 已完成修補。
• Wasmtime（2026-10-19）：GHSA-897f-g5gm-fmxm 影響所有架構，GHSA-mghf-wjfp-p5xm 只影響 aarch64，兩者都可能讓惡意 Wasm 模組逃出沙箱。兩份公告列出的修補版本範圍不同，請依各自公告升級。
• Chrome 156（2026-10-20）：Chrome Releases 穩定版公告寫明「本次更新包含 353 個安全修補」。
• Oracle Java SE：日本 IPA 注意喚起指出 Oracle 於 2026 年 10 月 21 日（日本時間）公布 Java 安全更新，受影響版本包含 Java SE 27、26.0.2、25.0.4.1、21.0.12.1、17.0.20.1、11.0.32.1、8 Update 503。

3. 供應鏈投毒與金鑰外洩

• LiteLLM 1.107.0：依 LiteLLM 官方事件報告（2026-10-21），PyPI 上 litellm==1.107.0 的七個 wheel 於 UTC 11:39:51 至 13:23 上架；Docker Hub 標籤 11:46:56 至 14:20、GHCR 標籤 11:46:56 至 13:51 指向受汙染映像檔，受影響標籤為 v1.107.0、latest、main-latest、main-stable。GitHub 上官方 v1.107.0 原始碼標籤不含惡意檔案；私有企業版用戶不受影響。安全版本為 litellm==1.106.2 或事件前發布的明確版本。
• 攻擊鏈：LiteLLM 10 月 23 日的攻擊鏈說明指出，起點是 5 月 27 日一把內部平台的管理金鑰被提交到公開 repo，四個多月後仍然有效。攻擊者 10 月 10 日用它取得一個沒有限縮範圍的 GitHub CLI OAuth token，再透過 CI 工作流程偷到另外兩位維護者的 token，最後從名稱只差一個連字號的 Berri-AI 分叉 repo 建置並發布。
• Railway：Railway 官方揭露（2026-10-21）偵測到存放客戶環境變數的系統出現異常活動，未授權第三方可能取得加密的環境變數，其中部分已取得解密內容；初步分析影響可能限於部分用戶。Railway 建議所有用戶立即輪替存在 Railway 的環境變數（含 API 金鑰）與私有映像庫憑證，並檢查服務日誌；調查期間暫停所有部署。Railway 認為這是一系列鎖定平台公司、目標為 AI 推論服務商的攻擊之一。
• Plex Media Server：CISA KEV 於 2026-10-20 加入 CVE-2026-96652、CVE-2026-96654、CVE-2026-96655、CVE-2026-96656，代表 CISA 已確認遭實際利用。

同週另有 PHP2Shell 與 Linux 核心 ksmbd 的消息，我們已分別寫過：PHP2Shell 自查與修補、Linux 核心 ksmbd 漏洞報告外洩。

二、編輯分析：這一週真正的風險在哪裡

第一，信任鏈變動會「修好了卻壞掉」。 certifi、Go、Node.js 三邊同週調整，但做法不同：certifi 曾先全部移除再部分補回，Go 用內建黑名單，Node.js 更新 CA 憑證。只升級主機上的執行環境不夠，Go 程式要重新編譯，內含 certifi 的容器映像檔要重建。反過來，如果你的對外網站或內網服務剛好用了受影響的憑證鏈，升級後就是用戶端連不上。

第二，投毒事件的處理單位是「主機」，不是「套件」。 LiteLLM 官方提醒，Python 啟動時會重新執行惡意檔案；Datadog Security Labs 的分析也指出，就算程式沒有 import LiteLLM 一樣會執行，只移除套件不會刪掉那些檔案。所以要問的不是「我們有沒有用 LiteLLM」，而是「哪些主機、CI runner、映像檔在那兩小時內拉過它」，以及「那些主機能讀到哪些金鑰」。LiteLLM 這類 AI 閘道通常握有多家模型供應商的 API 金鑰，一次外流就是全部。

第三，分數不是排序依據。 這一週的分數橫跨 CVSS 3.1 與 4.0 兩種版本，不能直接比大小。更實際的排序是：已裝過受影響版本或已被利用 → 對外開放的服務 → 其餘依分數。

第四，兩起事件的起點都是「金鑰沒換」。 LiteLLM 的起點是一把四個多月前就公開、卻沒有撤銷的金鑰；Railway 則是環境變數集中存放在平台。這和我們在 Zeabur 事件看到的結構一樣：金鑰放在別人那裡，就要能隨時換掉。

三、開發團隊的六個處理步驟

步驟 1：先列出你實際在跑什麼

用 SBOM 工具或套件鎖定檔（package-lock.json、poetry.lock、go.sum、Cargo.lock）列出所有服務的語言版本與相依套件，包含 CI runner 與容器映像檔裡的版本。重點欄位：Node.js 分支、Python 的 certifi 版本、Go 編譯版本、是否用到 LiteLLM、Wasmtime、自架 GitLab、Plex。

步驟 2：查有沒有裝過 LiteLLM 1.107.0

在每台可能裝過的主機、CI 快取與映像檔中，查 pip show litellm、litellm-1.107.0.dist-info、cook.pth、cook.py、sitecustomize.py，並比對是否跑過受影響標籤的映像檔。LiteLLM 官方提醒：在受影響環境不要直接 pip install 修復，因為 Python 啟動時會重新執行惡意檔案。官方建議從頭重建虛擬環境與映像檔，鎖定 litellm==1.106.2。若該主機能連外網，就假設資料已外流。

步驟 3：從乾淨機器輪替金鑰

LiteLLM 受影響主機：輪替該主機能讀到的所有憑證，包含雲端 IAM 角色、代理資料庫裡的所有模型供應商金鑰、master key 與 virtual key、DATABASE_URL 密碼與行程環境變數裡的機密。Railway 用戶：依官方建議輪替所有環境變數與私有映像庫憑證，並檢查服務日誌。輪替後到雲端稽核日誌查這段期間是否有來自外部的使用紀錄。

步驟 4：鎖版本、驗來源

相依套件一律鎖定明確版本，不用 latest 或 main-stable 這類會被改指向的標籤；容器映像檔用 digest 固定。LiteLLM 這次的惡意版本是從名稱只差一個連字號的分叉 repo 建置，所以 CI 拉取來源要寫死組織名稱，並比對套件雜湊或簽章。

步驟 5：升級前先測憑證鏈

升級 certifi（2026.10.19 以上）、Go（1.27.3／1.26.10）、Node.js（v26.12.1／v24.22.1／v22.23.4）之前，先清點對外網站、API 與內網服務用的 TLS 憑證是由誰簽發。若有 eMudhra／emSign 簽發的憑證，先換憑證再升級；升級後在測試環境實際連一次所有對外呼叫的 API。Go 服務要重新編譯，內含 certifi 的映像檔要重建。

步驟 6：依「已利用＞公網暴露＞分數」排修補

已列入 CISA KEV 的 Plex Media Server、對外開放的自架 GitLab（CVE-2026-110264）先修；GitLab 官方沒有暫時緩解方法，只能升級。接著處理 Node.js、Chrome、Wasmtime、CPython tarfile 與 Java SE 的例行升級。每一項記下修補日期與驗證結果，下次修補潮時就有基準可比。

驗收標準：完成後應能回答三個問題——哪些主機在 10 月 21 日拉過 LiteLLM 1.107.0；Railway 與其他平台上的金鑰是否已全部換新；升級憑證相關套件後，所有對外 API 是否仍能正常連線。三題都能回答，這一波才算處理完。

四、結語：修補要快，但順序更重要

一週內同時出現這麼多公告，最常見的錯誤是照 CVSS 分數由高到低修，結果把已經外流的金鑰留到最後。先處理「已經發生的事」，再處理「可能發生的事」，是這一週最實用的原則。

如果你的團隊正在導入 AI 閘道、代理或自動化流程，需要一起盤點相依套件、金鑰存放位置與輪替流程，歡迎與我們聯繫，我們可以從一份相依清單與金鑰清單開始。

免責說明：本文依各官方公告整理，資料截至 2026 年 10 月 30 日。各項修補版本、影響範圍與建議可能更新，實際處理前請以官方最新公告為準。本文不構成資安顧問意見。

參考來源

• Node.js，〈Wednesday, October 21, 2026 Security Releases〉，2026-10-21：https://nodejs.org/en/blog/vulnerability/october-2026-security-releases
• certifi／OSV，〈GHSA-6q48-6c7w-9gw2〉，2026-10-20：https://osv.dev/GHSA-6q48-6c7w-9gw2
• Go team，〈[security] Go 1.27.3 and Go 1.26.10 are released〉，2026-10-20：https://groups.google.com/g/golang-announce/c/66pojueaQek
• Go Vulnerability Database，〈GO-2026-6809〉，2026-10-21：https://pkg.go.dev/vuln/GO-2026-6809
• Python Security（經 oss-security 轉發），〈CVE-2026-114583〉，2026-10-22：https://openwall.com/lists/oss-security/2026/10/22/33
• 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〉，2026-10-21：https://docs.gitlab.com/releases/patches/patch-release-gitlab-19-5-1-released/
• GitHub Advisory Database，〈GHSA-897f-g5gm-fmxm（Wasmtime）〉，2026-10-19：https://github.com/advisories/GHSA-897f-g5gm-fmxm
• GitHub Advisory Database，〈GHSA-mghf-wjfp-p5xm（Wasmtime）〉，2026-10-19：https://github.com/advisories/GHSA-mghf-wjfp-p5xm
• Google Chrome Releases，〈Stable Channel Update for Desktop〉，2026-10-20：https://chromereleases.googleblog.com/feeds/posts/default/-/Stable%20updates?alt=rss&max-results=15
• IPA 情報處理推進機構，〈Oracle Java の脆弱性対策について(2026年10月)〉，2026-10-21：https://www.ipa.go.jp/security/security-alert/2026/1021-jre.html
• LiteLLM，〈Security incident: October 21, 2026〉，2026-10-21：https://docs.litellm.ai/blog/security-incident-oct-21-2026
• LiteLLM，〈Attack chain〉，2026-10-23：https://docs.litellm.ai/blog/security-incident-oct-21-2026-attack-chain
• Datadog Security Labs，〈LiteLLM compromised on PyPI and Docker〉，2026-10-21：https://securitylabs.datadoghq.com/articles/litellm-compromised-pypi-docker/
• Railway，〈Security Disclosure: Wednesday, October 21st〉，2026-10-21：https://blog.railway.com/p/security-disclosure-wednesday-october-21st
• CISA，〈Known Exploited Vulnerabilities Catalog（Plex）〉，2026-10-20：https://www.cisa.gov/known-exploited-vulnerabilities-catalog?search_api_fulltext=plex

相關推薦與延伸閱讀

• Zeabur 宣布結束營運：兩起資安事件的攻擊路徑，與企業該補的五個缺口：Zeabur 於 2026 年 10 月 17 日宣布結束營運，12 月 31 日前全面關閉。不到七週內兩度遭駭，環境變數與 API 金鑰外流。本文整理時程、退
• Claude Opus 5.5 上線：成本降 40%、長任務更穩，企業 AI 導入該怎麼評估與切換：Anthropic 於 2026 年 9 月 22 日發布 Claude Opus 5.5，官方表示預設設定下執行成本比 Opus 5 低約 40%，Token
• Uber 一週只有 4 趟叫車來自 AI 代理：台灣企業該不該現在為代理下單開入口？：AI 代理下單目前仍是極小眾，台灣企業應先縮短自家 LINE 與官網的下單步驟，再決定要不要為代理開專用入口。Uber 財報會議揭露，十月最忙一週約 3.2 億