資料核驗截至:2026 年 10 月 23 日(UTC) 涵蓋時段:2026 年 7 月 25 日—10 月 23 日,重點涵蓋 9—10 月的新公告與後續補丁。 適用物件:維護 Node.js、Java、Python 服務、容器、建置管線與開發環境的工程師和安全回應人員。

本文彙整 Node.js、Java、Python 運行時、標準函式庫及常見服務端框架和依賴中的近期重要安全風險,提供影響範圍、修復版本、臨時緩解措施、修補程式選擇與驗收方法。

文中列出各生態的重點風險,實際影響需結合組件版本、功能配置和可存取入口判斷。漏洞資訊以官方公告為依據,日期主要指公開揭露日期;修復包發布早於揭露時另行說明。未經官方證實的利用條件、CVSS 分數及在野攻擊情況不作推定;基於部署條件提出的措施標為實施建議。

TL;DR:修復步驟與建議

  1. 先更新真正承載服務的運作時。 Node.js 對應分支至少到 22.23.4 / 24.22.1 / 26.12.1。使用 Node 24 的服務,可在同一主版本內升級到 24.22.1 或之後包含相同修復的版本。 S1S2
  2. Node 應用程式依賴另外更新。 Next.js 建議採用 15.5.28 / 16.4.1 作為升級基線;獨立使用 React Server Components 時,核查實際安裝的 react-server-dom-* 包。只更新 Node 二進制不能覆蓋這些框架漏洞。 S8 S9 S10 S11 S12
  3. Java 同時核對兩輪更新。 直接安裝同時涵蓋 10 月 20 日 CPU 和 10 月 21 日 CVE-2026-91403 證書信任緊急修復的廠商版本。 Oracle JDK 11—27 的特定帶外版本請參閱第 2.2 節;其他發行商依自己的安全包與完整建置號驗收。 Tomcat 對應分支到 9.0.123 / 10.1.61 / 11.0.27。 S16S17S18S20S21S22S23
  4. Python 分別處理解釋器、應用程式套件和憑證套件。 解譯器基準請參考 2.3 節;certifi 建議 ≥2026.10.19,pip ≥26.2.2,使用 uv 時 ≥0.13.4。現有每個 venv 都需檢查。對 wrap_bio() 相關代碼,也必須傳入正確、非空的 server_hostname。 S29S30S31S33S35S36S37
  5. 暫時無法升級時,針對實際入口收縮暴露。 優先停止不可信 Brotli 解碼、受影響圖像/分頁/歸檔處理,隔離有問題的 LDAP 或認證入口;保持 TLS 證書與主機名校驗。入站 WAF 無法覆寫應用程式拉取惡意壓縮回應等出站路徑。 S3S11S25S27S30S32
  6. 重建、取代舊進程,再從真實業務連結驗收。 保存鎖定檔案和鏡像摘要,重建應用與鏡像,滾動取代全部 worker/JVM/容器;核對實際進程、依賴樹、信任庫和正常業務回歸。只有命令列版本變新,不能算完成。
  7. 若安裝或執行過 LiteLLM 1.107.0,走事件處置流程。 10 月 21 日官方確認該發布產物被投毒;先隔離並從乾淨環境調查、重建和輪換可訪問憑證。不要先在可疑環境啟動 Python/pip 做檢查。詳見第 9 節。 S41

1. 漏洞概覽與風險判斷

1.1 依實際暴露面安排處置

下表的「優先關注」是實施建議,漏洞等級採用廠商原始口徑,包括 Apache 的 Important。 CVSS 3.1 與 4.0 使用不同評分體系,不宜僅依分數橫向排名。

生態 / 層級重點問題官方等級或已核實分數優先關注的部署
Node.js 原生依賴CVE-2026-111497:Brotli 越界寫,有 RCE 風險Node:High解碼外部請求體或外部回應中的 Brotli 資料 S1S3
Node.js TLS / DNSCVE-2026-105482、105483、106069:解析與身分校驗不一致HighURL 抓取、代理、Webhook、動態目標位址 S1S5S6
Node.js HTTP/2CVE-2026-56846、56848:記憶體耗盡與 UAFHighNode 直接處理不可信 HTTP/2 流量 S7
React / Next.jsRSC / use cache typed arrays RCECritical;CVSS 4.0 9.5服務端 RSC、相關快取元件與資料路徑 S9S10
Next.js 影像優化CVE-2026-96889:SVG 影像處理 RCECritical;CVSS 4.0 9.5glibc Linux 上可處理不可信影像的實例 S11
Next.js Server Actions特製請求造成 CPU 耗盡High;CVSS 4.0 8.2App Router 且至少一個 Server Action S12
Java TLS 信任CVE-2026-91403:繼續信任受影響的中間 CACVSS 3.1 9.1使用受影響信任鏈的 TLS/API 場景 S17
TomcatJNDIRealm 認證繞過、HTTP/2 串線、AJP 回應洩漏Important對應 Realm / Connector / async Servlet 路徑 S21S22S23
Spring for GraphQLCVE-2026-59285:分頁反序列化 RCEHighJackson 2 + Connection 分頁 + 可利用類別路徑 S25
Spring SecurityCVE-2026-59270:內嵌 LDAP 已知管理身分暴露Critical啟用了內嵌 LDAP,且監聽埠可被攻擊者存取 S27
CPython sslCVE-2026-19445:SNI 切換上下文導致 UAFCriticalPython 自行終止 TLS,且滿足上下文生命週期條件 S29
CPython sslCVE-2026-19553:缺少 hostname 時跳過校驗Highwrap_bio() / 相關 asyncio 呼叫缺失預期主機名稱 S30
CPython tarfileCVE-2026-82049:硬連結與符號連結組合繞過High自動提取不可信 tar 歸檔 S32
Django / GeoDjangoCVE-2026-15307:空間查詢寫入檔案、SSRF,條件下 RCEHigh對不可信輸入開放空間查詢或相關管理後台 S38
Python 憑證依賴certifi:emSign 相關證書撤信Critical;GHSA,無已知 CVE仍使用受影響 CA bundle 的 TLS 用戶端和套件管理工具 S36S37

縮寫:RCE 為遠端程式碼執行,UAF 為釋放後使用,SSRF 為伺服器端請求偽造。 RCE 的直接權限通常是承載應用程式的進程權限,不能自動等同於 root 權限。

**建議的順序:**先處理外部可達且符合條件的 RCE、認證繞過、跨用戶資料外洩及憑證驗證問題;同時對公網 DoS 入口安排更新。無需為了證明可利用而在生產運行攻擊載荷。依賴存在、程式碼路徑可達、攻擊條件滿足,是三個需要分別核對的問題。

1.2 三個容易混淆的邊界

  • 運行時與依賴分開升級。 Node 、 JDK 、 CPython 的安全性更新不自動修復獨立安裝的 Next.js 、 Spring 、 Django 、 certifi 或原生擴充。
  • 修復門檻與目前部署基準分開。 某個 8 月漏洞的首個補丁,不保證覆蓋 9—10 月新問題;第 2 節採用已核實的後續更新作為實施目標。
  • 普通漏洞與已經發生的供應鏈投毒分開。 對一般漏洞,修補程式消除未來攻擊路徑;已執行惡意包時,還需調查憑證與持久化影響。第 9 節的 LiteLLM 是官方確認的事件。 S41

是否有已確認的在野利用,應以官方揭露為準。廠商未提及利用活動,也不能反向證明沒有攻擊;應依實際暴露面執行修復。

2. 修復版本與部署基線速查

參考連結: 2.1 Node.js、React、Next.js

組件 / 分支建議版本基線使用說明
Node.js 22.x22.23.410 月 21 日安全發表 S1S2
Node.js 24.x24.22.1適用於 24.x 分支;24.22.0 不包含 10 月 21 日安全性修補程式 S1S2
Node.js 26.x26.12.1同批安全發布 S1S2
Node.js 20 及更早上游分支遷移至支援分支Node 20 不接收此上游修復;廠商延長支援另核 S3
Next.js 15.x15.5.2810 月 14 日更新 S8
Next.js 16.x16.4.1同上 S8
獨立 RSC 19.0 / 19.1 / 19.2 / 19.3 分支19.0.9 / 19.1.10 / 19.2.9 / 19.3.1三種 react-server-dom-* 套件分別核對;不是只看頂層 react S10
Next 實際載入的 sharp≥0.35.5SVG 漏洞的官方臨時修復條件;不取代其他 Next.js 修補程式 S11

Node 官方對 10 月漏洞列出了受影響的維護分支,但未逐項給出最初引入的補丁版本,因此無法僅憑維護分支範圍確定各漏洞的精確起始版本。部署時優先使用同分支上述版本或確認包含相同修復的後續版本。

2.2 Java:10 月 CPU 加帶外證書更新

下表是 Oracle JDK 口徑。第二列僅代表 10 月 20 日 CPU,第三列才涵蓋官方 10 月 21 日帶外發布;不能把第二列直接作為本次全部 Java 風險的合格線。 S16S17S18

分支10 月 20 日 CPU10 月 21 日 Oracle 帶外發布
1111.0.3311.0.33.0.2
1717.0.2117.0.21.0.2
2121.0.1321.0.13.0.2
2525.0.525.0.5.0.2
2727.0.127.0.1.0.2
88u511公開發布表仍顯示 8u511;必須核對特定安全建置與信任鏈修復,不能只以短版號判定

**Java 8 需依完整建置資訊核對:**Oracle 警報將 8u511 列入受影響版本,而發布清單又以相同短名稱列出後續更新。僅憑「8u511」短版號碼無法區分修補程式狀態,應確認特定安全建置與信任鏈修復內容。 S17S18

**Temurin、Corretto、Zulu、Microsoft Build of OpenJDK、發行版 OpenJDK 等,依各自公告及完整包/建置號核對。**例如 Adoptium 的官方發布記錄說明,相關建置重新包裝以加入 eMudhra 修復;上游版本名稱相同不代表套件內容相同。 Oracle 的 .0.2 後綴規則不能機械套用其他發行商。 S20

Java 應用元件建議版本基線備註
Tomcat 9 / 10.1 / 119.0.123 / 10.1.61 / 11.0.27逐分支核對;Tomcat 10.0 已停止維護 S21S22S23
Spring for GraphQL 2.0.x2.0.5(OSS)商業支援另有 2.0.4.1 S25
Spring Security 7.1 / 7.07.1.1 / 7.0.7(OSS)對應 8 月公告的最低修復版本;部署前還需檢查後續安全公告 S27S28
Spring Security 6.5 / 6.4 / 5.8 / 5.76.5.12 / 6.4.19 / 5.8.28 / 5.7.26公告列為商業支援修復;無對應支援時評估遷移,不能假定 Maven Central 免費可得 S27

Spring 升級應尊重專案的 Spring Boot BOM、Java 最低版本和相容線。不要為了拿到一個補丁,把所有 Spring 模組直接強制改成同一個數字。

2.3 CPython、Django 與憑證依賴

下表第二列主要針對 9 月揭露的 TLS 問題;tarfile 的分支差異請參閱 5.3 節。 10 月 21 日又有打包證書更新,因此列出後續可採用基線。 S29S30S33S35

CPython 分支9 月安全批次最低版本建議部署基線
3.103.10.22上游最後一次發布,已 EOL;安排遷移或核實發行版延長支援 S34
3.113.11.173.11.17,並單獨更新每個環境中的 pip / certifi
3.123.12.153.12.15,並單獨更新每個環境中的 pip / certifi
3.133.13.163.13.17
3.143.14.83.14.9
3.15正式 3.15.0 已包含兩款 TLS 修復 S31S473.15.1

3.11、3.12 的上游安全版本可能只有原始碼發布;使用作業系統套件時,核對廠商回補公告和完整套件版本,不要求將系統 Python 強行替換成自行編譯版本。 S33S34

獨立依賴建議版本基線說明
Django 5.2 / 6.0 / 6.15.2.18 / 6.0.9 / 6.1.2納入 10 月 6 日後續修正 S38S39
certifi≥2026.10.19GHSA 初始補丁為 .18;PSF 推薦 .19 以保留未受影響證書的兼容性 S36S37
pip≥26.2.2內建的 certifi 副本需另更新 S35S37
uv(若使用)≥0.13.4依實際安裝方式更新 S37

上述基線對應已列明的補丁範圍。 10 月 22 日又揭露了一項 tar_filter 中危問題,截至 2026 年 10 月 23 日,尚未確認包含該修復的正式維護版;因此, 3.13.17 / 3.14.9 / 3.15.1 不能視為已覆蓋所有 tarfile 問題。見第 5.4 節。 S40

2.4 發行版回補如何認定

適用於 Ubuntu、Debian、RHEL 等軟體套件的實施原則:

  1. 記錄作業系統版本、倉庫來源、完整包版本和廠商安全公告編號。
  2. 確認公告包含具體 CVE,以及對應發行版的修復包門檻。
  3. 對照實際運行進程所加載的二進位/庫,而非僅對比上游短版本。
  4. 沒有廠商補丁證據時,保留“尚待確認”,不要把版本號碼看起來舊或新當作唯一結論。

不同發行版的 apt/RPM 套件版本與回補策略有差異,應以各發行版的安全公告及完整包版本為準。

3. Node.js / JavaScript 生態:成因與修復分析

3.1 CVE-2026-111497:Brotli 原生解碼器越界寫

揭露:2026-10-21;Node 官方等級:High。 Node 22.x、24.x、26.x 的受影響建造需要安裝第 2.1 節補丁。 Node 公告未列出數值 CVSS 評分。 S1

問題發生在處理畸形 Brotli 壓縮流時的原生解碼邏輯,可導致越界寫。 Vercel 的官方說明確認,研究演示涉及進程記憶體外洩與命令執行。攻擊者能否觸達解碼器,取決於應用或依賴是否實際解碼其控制的資料。 S3

需要同時檢查兩個方向:

  • **入站:**框架或中介軟體自動解壓縮用戶提交的 Brotli 請求體。
  • **出站:**HTTP 用戶端、圖片抓取器等存取攻擊者可控制來源,並自動解壓縮回內容。

因此,僅關閉伺服器向瀏覽器發送 Brotli 壓縮內容,並沒有移除「解碼」入口;只做入站 WAF 防護也覆蓋不到主動抓取回應的路徑。 S3

**補丁方向:**Node 將 Brotli 上游修復移入原生依賴,補充非法解碼狀態檢查與錯誤傳播。維護自編譯版本時,應採用正式安全發布或匹配分支的完整補丁,且不能只改一個 JavaScript 套件的版本聲明。 S4

**臨時實施建議:**停止不必要的不可信 Brotli 解碼;檢查中間件與 HTTP 用戶端的自動解壓縮行為;如果業務必須接受該格式,盡快在已修補環境完成處理。調整 Accept-Encoding 只是協商行為,不應單獨作為已阻斷惡意回應的證據。

3.2 TLS / DNS 的三個 High:校驗物件與實際目標不一致

三項均於 10 月 21 日揭露,正式升級門檻請見 2.1 節。 S1

標識已確認問題官方影響分支
CVE-2026-105482dns.resolve 對包含 NUL 的名稱發生截斷22.x / 24.x / 26.x
CVE-2026-105483全角數位形式的 IP 導致憑證主機名稱校驗繞過24.x / 26.x
CVE-2026-106069可被寬鬆解釋為 IP 的主機名稱導致 TLS 校驗繞過22.x / 24.x / 26.x

DNS 問題的本質是上層檢查的字串與底層實際解析的名稱不同。官方修補在解析入口拒絕 NUL,並增加迴歸覆蓋。 S6

TLS 兩項涉及名稱規範化、IP 解釋與證書匹配的一致性。修補使非標準 IP 輸入被拒絕或正確處理,避免將實際 IP 端點與憑證網域身分混為一談。 S5

實際排查建議: 優先檢查接收用戶 URL 、動態代理目標或 Webhook 地址的代碼;統一規範化與允許列表判斷,拒絕 NUL /控製字符,確認合法 IPv4 、 IPv6 和國際化域名仍工作。是否能進一步構成 SSRF ,需要應用鏈路證據,不能從 CVE 名稱直接推導。

不要透過 NODE_TLS_REJECT_UNAUTHORIZED=0 或 rejectUnauthorized: false 消除升級後的校驗錯誤。應修正地址、證書與業務配置。

3.3 7 月 HTTP/2 高風險與權限模型問題

7 月揭露的下列問題仍需納入檢驗,部署時建議直接採用第 2.1 節的 10 月安全版本基準。 S7

CVE成因與影響首個修復版本
CVE-2026-56846留存的 HTTP/2 header 區塊未被正確納入 maxSessionMemory 預算,可耗盡記憶體;影響 22.x / 24.x22.23.2 / 24.18.1
CVE-2026-56848HTTP/2 收包過程中重入發送路徑,造成堆疊 UAF;影響 22.x / 24.x / 26.x22.23.2 / 24.18.1 / 26.5.1
CVE-2026-58043--permission 路徑前綴邊界匹配過寬,可能存取允許清單外文件同上三條維護線

三項官方均為 High。前兩項優先檢查 HTTP/2 是否由 Node 本身處理;第三項只有在使用權限模型並依賴該邊界時才有對應意義。不能把權限模型項目一律描述為無需認證的網路 RCE。 S7

暫時把 HTTP/2 終止在獨立、已更新的代理上,並限制後端來源,是降低暴露的部署選擇;資源配額只能控制資源耗盡的後果,不能修補 UAF。

3.4 10 月 React / Next.js:兩款 RCE 與一項 DoS

A. RSC / use cache 傳回 typed arrays 的 RCE

**公開日期:2026-10-14;Critical,CVSS 4.0 9.5。**官方公告標識如下:

  • React:GHSA-xqc2-xf4c-x3h3。
  • Next.js:GHSA-673q-mjm6-r5xr。S9S10

React 上游問題涉及 RSC 回應中的多個 typed arrays 與攻擊者可控值組合。受影響的三個 react-server-dom-* 套件版本為 19.0.0 — 19.0.8 、 19.1.0 — 19.1.9 、 19.2.0 — 19.2.8 、 19.3.0 ;修復門檻見第 2.1 節。純瀏覽器端 React ,或完全不使用支持 RSC 的框架/插件的應用,不屬於此項範圍。 S10

Next.js 下游公告列出 16.0.0 — 16.4.0 ,修於 16.4.1 ;場景是 App Router 、 Cache Components 和返回多個 typed arrays 的 use cache 函數。官方沒有可靠的通用 workaround,並要求受影響版本用戶及時升級,不宜僅靠人工搜尋「好像沒有這個函數」結束處置。 S9

參考連結: B. SVG Image Optimization RCE

**CVE-2026-96889 / GHSA-2464-fhr4-w9xw,2026-10-14,Critical,CVSS 4.0 9.5。**問題在影像優化所使用的上游原生庫,官方指出 glibc Linux 場景存在 RCE 風險。 S11

官方版本欄位為:

  • >=10.0.0 <=15.5.27;
  • >16.0.0 <=16.4.0。

官方對 16.x 分支使用嚴格下界 >16.0.0,但此範圍表述不足以證明 16.0.0 已安全。實際升級目標統一採用 15.5.28 / 16.4.1。 S11

官方臨時方案是保證 Next 真正加載的 sharp ≥0.35.5。鎖定檔案、巢狀依賴和部署映像可能仍保留舊實例,因此僅在頂層新增一個新版 sharp 依賴不夠,應檢查最終依賴樹並重新建置。 S11

C. Server Actions CPU 耗盡

GHSA-p3m5-59mp-jv5r ,2026-10-14, High , CVSS 4.0 8.2 。 Next 影響 13.0.0 — 15.5.27 、 16.0.0 — 16.4.0 ,修復 15.5.28 / 16.4.1 。條件為 App Router 並且至少一個 Server Action ;惡意請求可讓 CPU 長時間被佔用,阻塞同進程後續請求。 Pages Router 或沒有 Server Actions 的應用不受此項影響。 S12

官方未給出可代替升級的 workaround。限流、併發與資源配額可減少損害,但不能作為修補程式驗收結論。

3.5 同窗口內更早的 Next.js 嚴重問題

以下項目用於避免遺漏仍停留在 8—9 月以前版本的部署;不建議現在只升到表中的舊修復門檻。

日期標識 / 場景首個修復;現行行動
2026-08-25GHSA-2xp9-vwfh-vxw4:AVIF 影像優化原生庫 RCE,Critical15.5.24 / 16.3.3;現在採用 15.5.28 / 16.4.1 S13
2026-08-25CVE-2026-75604 : Windows 上同時使用 Pages Router 與 App Router ,且未啟用 Cache Components 時的 RCE , Critical ;版本 >=13.4.0 <15.5.24 、 >=16.0.0 <16.3.315.5.24 / 16.3.3;Linux/macOS 不受此特定 Windows 問題影響 S14
2026-09-22GHSA-vcvr-r3jv-pc5j : next/og 的 Node 影像生成路徑處理不可信 SVG , Critical ; 16.2.0 — 16.3.516.3.6;Edge 實現不在此項範圍,15.x 不屬於此 RCE 影響分支 S15

4. Java 生態:運行時信任、容器與框架分開處理

4.1 JDK:常規 CPU 與 CVE-2026-91403 為兩層更新

10 月 20 日 Oracle CPU 的 Java SE 風險矩陣列出 55 個新安全補丁,其中 49 項標為可透過網路無認證利用。這並不表示 55 個 Critical,也不表示每個 Java Web 服務都存在 49 條可直接利用的 RCE 路徑;要結合矩陣中的元件、API、使用者互動和部署條件理解。 S16

隔日的 **CVE-2026-91403(CVSS 3.1 9.1)**處理另一類風險:不再信任與 eMudhra 事件相關的一組中間 CA。它影響 TLS 對端身份認證及通訊機密性/完整性,不能描述為 JVM 記憶體破壞漏洞。 S17

Oracle 公告將 10 月 20 日發布的版本列為受影響,因此還需安裝 10 月 21 日的帶外更新,具體版本請參閱第 2.2 節。 GraalVM 也有對應受影響產品,修復版本應以其專屬安全公告為準。 S17S18

**臨時官方措施:**先備份,再從每個實際使用的 truststore 移除指定根憑證:

  • emSign ECC Root CA - G3,Oracle 別名 emsigneccrootcag3 [jdk]。
  • AAA Certificate Services,Oracle 別名 comodoaaaca [jdk]。 S19

JDK 11 及以後,官方範例為:

keytool -delete -cacerts -alias "emsigneccrootcag3 [jdk]"
keytool -delete -cacerts -alias "comodoaaaca [jdk]"

這些指令應使用目標 JDK 自帶的 keytool,並確認操作的是套用實際信任庫。 Java 8 使用對應 jre/lib/security/cacerts 路徑;自訂 truststore 要單獨處理,其他發行商的別名可能不同。根憑證移除會擴大拒絕範圍,應回歸合法業務憑證鏈。 S19

官方也提供啟用撤銷檢查的選擇,但效果取決於實際 TLS 實作、撤銷服務可及性與失敗策略。對一般部署,優先安裝廠商完整更新,避免把兩個 JVM 開關當作所有 TLS 庫都已修復的證據。

4.2 Tomcat:認證繞過與跨使用者要求隔離

下列三項於 2026-10-20 公開;修復版條目日期為 10 月 12 日。 Apache 官方等級皆為 Important。 S21S22S23

CVE確認影響區間必要場景 / 結果
CVE-2026-1012969.0.0.M1—9.0.122;10.1.0-M1—10.1.60;11.0.0-M1—11.0.26JNDIRealm 設定非 GSSAPI 的 SASL 認證機制,憑證驗證缺失,錯誤密碼也可能透過
CVE-2026-1013569.0.118—9.0.122;10.1.55—10.1.60;11.0.22—11.0.26HTTP/2 的非同步 Servlet 錯誤處理錯誤回收/復用對象,造成用戶間請求或回應串線
CVE-2026-103119僅確認 11.0.0-M25—11.0.26AJP 大型非阻塞寫發生 buffer under-read,可能會把前一回應資料帶入後續請求

對應修復為 9.0.123 / 10.1.61 / 11.0.27 ; AJP 這一項按公告僅列 Tomcat 11,不能擴展成三個分支都有相同問題。 S21 S22 S23

JNDIRealm 修補程式修復實際認證流程中的校驗缺口,不能用「套用登入介面看起來正常」取代驗證。應檢查服務真正配置的 Realm、SASL 機制,並測試錯誤密碼必須失敗。 S24

**臨時實施建議:**隔離受影響認證路徑;在業務允許時暫停 Tomcat 的 HTTP/2 處理;關閉無用 AJP。僅限制 AJP 端口的直接訪問,不能證明經合法前置代理進入的流量沒有影響。正式更新後應測試兩位獨立使用者的非同步並發請求,確認身分和回應沒有串列線。

參考連結: 4.3 Spring for GraphQL:CVE-2026-59285

公開日期:2026-08-20; High 。 受影響 2.0.0 — 2.0.4 ,修復 2.0.5 ( OSS ) 或 2.0.4.1 (商業支援) 。 S25

這是分頁查詢中的不安全反序列化風險,官方要求以下條件同時滿足:

  1. 使用 Spring for GraphQL。
  2. 使用 Jackson 2.x 反序列化 JSON。
  3. 對外提供 Connection 分頁欄位。
  4. classpath 存在著可在實例化或反序列化中執行非預期邏輯的特定類別。

滿足條件時,惡意 GraphQL 請求可能造成 RCE。不能簡化為「所有使用 Jackson 的 Java 程式都可被利用」。 S25

**為何不能停留在 2.0.4:**6 月的 CVE-2026-41699 曾給出 2.0.4 等修復門檻,8 月公告又明確把 2.0.4 納入新的影響範圍。因此,修復記錄必須按後續公告更新,不能沿用舊 CVE 的最低版本。 S26

暫時無法升級時,可暫停不可信呼叫方能觸達的相關分頁欄位;縮小可反序列化類型與類路徑是縱深措施。回歸應涵蓋合法 cursor、分頁結果及異常輸入拒絕,並檢查最終應用 JAR 內的實際元件版本。

4.4 Spring Security:CVE-2026-59270 與關聯認證風險

**CVE-2026-59270,2026-08-20,Critical。**內嵌 UnboundIdContainer 預設登記已知管理員身份,並監聽所有網路卡。元件啟用且連接埠可達時,攻擊者可讀取或修改目錄資料;一般引入 Spring Security 的項目不因此自動暴露 LDAP。 S27

受影響範圍:

分支受影響首個修復 / 獲取管道
7.17.1.07.1.1 OSS;另有商用 7.1.0.1
7.07.0.0—7.0.67.0.7 OSS;另有商用 7.0.6.1
6.5 / 6.46.5.0—6.5.11;6.4.0—6.4.186.5.12 / 6.4.19,商業
5.8 / 5.75.8.0—5.8.27;5.7.0—5.7.255.8.28 / 5.7.26,商業

來源:S27。排查 spring.ldap.embedded.* 自動配置和直接實例化程式碼;生產不需要該元件時關閉它,並核對實際監聽位址。當業務確有需要時,先限制呼叫來源,再完成元件升級。

**同批認證問題附註:CVE-2026-47841(High)。**WebAuthn 使用者驗證設為 REQUIRED,且 HTTP session 經分散式儲存序列化後,錯誤的物件身分比較可能使驗證要求失效。此攻擊還需要攻擊者已掌握使用者認證器設備,不是無設備的任意遠端登入。涉及 7.1、7.0、6.5、6.4 的對應受影響版本,修復門檻與上表這些分支一致;驗證應覆蓋跨節點 session 後仍要求 PIN/生物驗證。 S28

5. Python 生態:解釋器、標準函式庫、框架與證書

5.1 CVE-2026-19445:SNI 回呼中的 SSLContext UAF

**公開日期:2026-09-30;PSF 等級:Critical。**在 Python 服務端 TLS 中,sni_callback 把連線切到另一個 SSLContext,且原上下文沒有其他存活引用時,未當機的認證 TLS 物件已釋放的物件可能已釋放。 S29

核心是 Python 物件與底層 TLS 回呼生命週期不一致。原始上下文已被釋放,底層仍可能持有回調所需狀態;需要用解釋器原生補丁修復引用生命週期。 S47

**適用邊界:**僅充當 TLS 用戶端的 Python 程式碼不受此影響;監聽 socket 長期持有原始情境的常規失效模式,也不屬於公告描述的特定失效路徑。 Nginx 終止 TLS 後只把本地 HTTP 交給 Python,和 Python 自己直接處理 SNI,是不同暴露面。 S29

對應 3.10—3.14 修復版本請參考第 2.3 節。 3.15 正式版已含修復,實際可選擇 3.15.1。只更新 pip 依賴無法替換解釋器的 _ssl 實作。 S33S35S47

**官方臨時緩解:**把所有設定了 SNI 回呼的 SSLContext 保持強引用,直到伺服器生命週期結束。此舉需涵蓋實際動態建立與切換路徑;自訂 OpenSSL 1.1.1 建置也應結合官方問題記錄檢查重協商條件,優先完整更新。 S29S47

5.2 CVE-2026-19553:開啟了 hostname 標誌,但呼叫卻缺少 hostname

公開日期:2026-09-30;High。SSLContext.check_hostname=True 時,若 wrap_bio() 沒有傳入 server_hostname,原實作可能靜默跳過主機名稱驗證。憑證鏈校驗成功不代表目標網域也已比對。 S30

修復分兩件事:

  • 更新第 2.3 節中的解釋器安全版本。
  • 檢查 wrap_bio()、相關 asyncio.create_connection() / loop.start_tls() 路徑,明確傳入預期且非空的主機名,保持憑證校驗開啟。 S30

不能省略的相容性差異: 3.10 、 3.11 、 3.12 為相容性,對缺少 hostname 的部分情況只發出 DeprecationWarning ; 3.13 及以後才拋出 ValueError 。 3.12 回補還明確區分 None 與空字串:新增警告針對 None ,空字串仍報錯。因此低分支用戶不能只憑升級,就假定原本缺少的網域校驗已經自動恢復。 S31 S33

驗收可在測試環境使用「證書鏈可信任、但主機名稱不符」的測試證書,確認真實業務 TLS 用戶端拒絕連線。僅讀取 check_hostname 布林值不構成完整驗收。

5.3 CVE-2026-82049:tarfile 過濾器中的連結組合繞過

公開日期:2026-09-14; High 。 在 CPython 3.13 及更早的相關實作中,不可信 tar 內的硬連結與符號連結組合可以繞過 data / tar 提取過濾器,使解包目錄外文件的內容在解包樹中暴露,或修改它們的權限、修改時間。 S32

此漏洞已確認的影響包括文件內容暴露及元資料修改;這些影響本身不足以證明可任意覆蓋外部文件內容或無條件實現 RCE。

3.10 — 3.13 對應修復門檻見第 2.3 節。 Python 3.14 自 3.14.0b1 起已因 os.link() 行為變化而不受這個特定問題影響 ,因此不適用上述 3.10 — 3.13 分支的受影響範圍。 S33

**臨時與縱深措施:**暫停不可信歸檔自動提取;業務必須處理時使用隔離的低權限工作進程、全新獨佔目錄,按業務拒絕符號鏈接、硬鏈接與設備條目,並限製文件數量和解壓資源。這些是部署建議。

filter="data" 對一般不可信歸檔比完全信任策略更合適,但舊版上的過濾器本身也有本次漏洞,單加這個參數不能取代更新。過濾器也不是完整檔案系統沙箱。 S32S45

5.4 補充風險:CVE-2026-114583(Medium)與補丁發布狀態

PSF 於 2026-10-22 揭露 tarfile.tar_filter 特定連結名的處理可被繞過,使後續成員寫到解包目錄外,等級為 Medium 。官方修復 PR 當天合併;截至 2026 年 10 月 23 日,尚未確認包含該提交的正式維護版。 S40

因此:

  • 此項按 Medium 單獨列示。
  • 10 月 21 日發布的解釋器版本不能視為已包含此修復。
  • 仍使用 filter="tar" 處理不可信歸檔的流程,應追蹤發行版回補;短期隔離或暫停該處理路徑。改用 data 及拒絕連結時,也必須確認符合業務要求,不能把更換過濾器描述為無條件沙箱。

5.5 GeoDjango:CVE-2026-15307 及 10 月後續補漏

**2026-08-04,Django 官方 High。**空間查詢把某些字串/字典隱式傳給 GDALRaster,驅動可能寫入檔案或發起網路請求;具備特定路徑與後續執行條件時可能形成 RCE。具有空間欄位模型檢視權限的 staff,也可能透過 admin changelist 觸達此路徑。 S38

初始修復是 5.2.17 / 6.0.8,限制空間 lookup 接受的輸入類型。這個變化可能影響原有使用字串/字典表達 raster 的業務;把不可信輸入簡單包裝成 GDALRaster,並不等於驗證了它。 S38

10 月 6 日又修復 CVE-2026-87890 (Moderate) :以 bytes 表示的 VRT 可引用外部資源,仍引發網路請求;同日也加強了 CVE-2026-15830 的嵌套幾何 DoS 防護。後兩者不能升級描述成新的高危險 RCE ,但說明部署基線應採用 5.2.18 / 6.0.9 / 6.1.2 。 S39

實作上檢查 API 與管理後台兩種入口,限制不可信空間 lookup、文件寫權限及出站存取;更新後回歸合法空間查詢及被禁止輸入的拒絕行為。沒有使用 GeoDjango 的普通 Django 應用,不應直接套用此 RCE 結論。

5.6 certifi / pip:憑證信任必須涵蓋每份副本

**GHSA-6q48-6c7w-9gw2,2026-10-20,Critical,未列已知 CVE。**這是 eMudhra 中間 CA 事件引發的憑證撤信更新,不能概括為 HTTPS 的密碼學機製或所有根憑證被破解。 S36

certifi 公告最初列 2026.10.18 為修補版; PSF 隨後明確推薦 2026.10.19 ,以保留未受影響根憑證的相容性。操作基線採用 .19。 S36 S37

需要區分:

信任材料的位置為什麼需要單獨檢查
作業系統 CA 套件鏡像或主機的系統信任材料
venv 中的 certifi應用或 Requests 等實際使用的 CA bundle
pip 內建 certifi與外部安裝的 certifi 是不同副本
uv / 其他打包工具依工具本身的更新與信任來源處理
自訂 CA 檔案、打包快照可能繼續覆蓋系統或套件的預設信任來源

以上是依據不同打包位置所製定的核查清單。 PSF 要求更新相關工具、現有虛擬環境並重建鏡像;僅更新宿主機 CA 或重裝解釋器,無法證明所有副本都已刷新。 S35S37

從舊 pip 安全開機升級時,PSF 提供了固定 wheel 及 SHA-256的指令,請參閱附錄 S37。不要以關閉 TLS 校驗或加入 --trusted-host 來繞過憑證問題。

6. 正式修復流程

以下命令適用於已確認可信任的環境。執行時應結合專案已有的套件管理器、鎖定檔案和部署流程,避免混用 npm/pnpm/yarn 或 pip/uv/Poetry 產生互相衝突的鎖定檔案。

**先處理一個例外:**若懷疑環境運行過第 9 節的投毒包,先隔離,從乾淨環境檢查磁碟、鎖定檔案和鏡像記錄;不要先執行下面的 Python/pip 指令。 S41

6.1 建立能對應真實流量的台賬

每個服務至少記錄:

  • 外部入口、反向代理、來源站直連路徑,以及後台佇列/定時任務。
  • 實際啟動命令、運行帳戶、二進位路徑、進程或容器身份。
  • 運行時完整版本、發行商/倉庫、軟體包完整版本或鏡像 digest。
  • 框架與傳遞依賴、鎖定檔案、原生程式庫、信任庫路徑。
  • 對應漏洞條件是否存在、修補程式目標、重啟範圍、負責人和驗證結果。

對開發機、CI runner、建置容器和後台任務也要依其接觸不可信內容的路徑檢查;不要只更新公網 Web 容器。

6.2 Node.js:先確定運行時,再更新應用依賴

在實際服務環境檢查:

node -p 'JSON.stringify({execPath:process.execPath,node:process.version,openssl:process.versions.openssl,brotli:process.versions.brotli},null,2)'
npm ls next react react-dom react-server-dom-webpack react-server-dom-parcel react-server-dom-turbopack sharp --all
npm audit --omit=dev

node -p 應使用服務實際執行檔或在實際容器內執行;它檢查的是新啟動的進程,本身不能證明舊 worker 已被取代。 Node 可以把補丁回補到內建 Brotli 而保留原庫版本字串,因此不要只靠 process.versions.brotli 判定是否修復,應結合 Node 安全版本或廠商回補證據。 S2S4

npm ls 用於看實際依賴樹;缺失套件或 peer 衝突也可能產生非零退出碼,應讀特定輸出。 npm audit 作為依賴檢查輔助,不能取代 Node 二進位和原生函式庫核對。

使用 mise 管理 Node 24 的環境,可依下列範例更新:

mise use -g [email protected]
mise exec [email protected] -- node -p 'process.version + " " + process.execPath'

mise use -g 設定全域版本;專案本機設定仍需另外檢查。服務若固定了舊的絕對路徑、容器基礎映像或不同帳戶的環境,也要更新對應配置並重新啟動服務。命令本身不會替換正在運行的舊進程。 S43

在 Next 專案內,按已選分支執行對應指令。 Next 15 項目:

# Next 15 分支
npm install --save-exact [email protected]

Next 16 專案:

# Next 16 分支
npm install --save-exact [email protected]

檢查 React/RSC 相容依賴、鎖定檔案和最終 sharp 實例,再按專案流程建置。 CI 中使用已更新的鎖定檔案進行可重複安裝,建置後檢查執行鏡像內的版本。不要把不受控制的跨主版本自動修復當作本次應急預設方案。

6.3 Java:核實發行商、實際 JVM 和內嵌組件

初步盤點:

java -XshowSettings:properties -version

輸出中的 java.home、java.runtime.version 與發行商,應與服務實際使用的 JVM 對齊。對於有 attach 權限的 JVM,可用該 JDK 的 jcmd 核對目標進程,而不只看登入 shell。

可信任項目中檢查依賴,依實際建置工具選擇:

./mvnw dependency:tree '-Dincludes=org.apache.tomcat.embed:*,org.springframework.security:*,org.springframework.graphql:*'

./gradlew dependencyInsight --dependency tomcat-embed-core --configuration runtimeClasspath
./gradlew dependencyInsight --dependency spring-security-core --configuration runtimeClasspath
./gradlew dependencyInsight --dependency spring-graphql --configuration runtimeClasspath

這些建置命令可能執行插件並聯網解析依賴,僅對可信任專案運行。檢查最終 JAR/WAR 或鏡像中的實際 JAR,不以建立檔案聲明取代最終產物。 Spring Boot 內嵌 Tomcat 需要重建應用;更新系統中一個獨立 Tomcat 安裝不會修改應用程式包裡的副本。

運行時更新後,逐項核對自訂 javax.net.ssl.trustStore、套用自行載入的 KeyStore、jlink runtime、GraalVM/native image 等交付形態。已有客製化信任材料的應用不能僅憑 JDK 目錄變新就結束檢查。

6.4 Python:逐解釋器與虛擬環境處理

在確認可信任的實際 venv / 容器內:

python - <<'PY'
import sys
import ssl
import importlib.metadata as metadata

print("executable:", sys.executable)
print("version:", sys.version)
print("openssl:", ssl.OPENSSL_VERSION)
print("verify_paths:", ssl.get_default_verify_paths())
for name in ("pip", "certifi", "Django", "urllib3", "Brotli", "litellm"):
    try:
        print(name + ":", metadata.version(name))
    except metadata.PackageNotFoundError:
        print(name + ": not installed")
PY

python -m pip --version
python -m pip check

這份腳本只做資訊蒐集,不執行版本合格判定。 ssl.get_default_verify_paths() 是預設路徑訊息,無法證明所有第三方客戶端都採用同一信任庫;應結合應用程式配置確認。

完成附錄 S37 的可信任 pip 引導升級後,再依專案限制更新憑證依賴,例如:

python -m pip install --upgrade 'certifi>=2026.10.19'

# 仅适用于当前就选择 Django 5.2 的项目
python -m pip install --upgrade 'Django>=5.2.18,<5.3'

python -m pip check

需要同時更新專案的 requirements/鎖定文件,否則下次部署可能會恢復舊版本。使用 uv、Poetry 或企業包倉庫時,請使用其現有鎖定與發布流程;不要只在某個生產容器內手改包。

可在已受信環境中,使用專案既有的 pip-audit 工作流程檢查已知依賴漏洞;它不是惡意程式碼掃描器,也不覆寫全部解釋器、系統程式庫和信任庫風險。 S44

**不建議把系統 /usr/bin/python3 強行指向一個新編譯版本。**使用發行版安全性更新或專案隔離運作時,避免破壞依賴系統 Python 的管理工具。這是實施選擇,不是本次漏洞的額外修復要求。

6.5 重建與替換運行實例

建議將以下步驟作為一次完整變更:

  1. 在原有可信任來源取得補丁,並保存版本/哈希和依賴鎖。
  2. 在接近生產的環境回歸關鍵功能,確認原生擴充和 JVM/框架相容。
  3. 更新運行時、應用依賴及實際信任庫;對容器刷新基礎鏡像與系統 CA,不能只重複使用舊層。
  4. 重建應用與鏡像,滾動替換服務、worker、佇列消費者與定時任務實例。
  5. 在新運行實例重新核對版本和配置,確認舊副本全部退出。
  6. 觀察錯誤率、延遲、CPU/記憶體、TLS 握手失敗和進程崩潰。

回滾應優先保留安全運行時與修補程式依賴,回滾應用程式配置或業務變更。若不得不回到有漏洞的舊產物,應同步恢復對應入口限制,明確責任人與最短恢復期限。

7. 臨時緩解與 Patch 選擇

7.1 臨時措施的覆蓋邊界

以下是根據公告利用條件整理的實施建議,除註明官方方案外,不表示廠商保證能夠完全阻斷所有變體。

風險可暫時採取的措施不能據此認定已完成的部分
Brotli 解碼停止不可信輸入解碼;檢查入站和出站自動解壓入站 WAF 或關閉回應壓縮不覆蓋全部解碼入口 S3
Next.js typed arrays RCE立即升級;必要時暫時隔離受影響服務官方沒有可靠通用 workaround S9
Next.js SVG RCE官方方案:確保實際 sharp ≥0.35.5;業務允許時暫停相關最佳化入口不覆蓋其他 Next/RSC 問題 S11
Tomcat 境界 / HTTP/2 / AJP隔離對應路徑、關閉不必要 Connector仍需對應分支修復包 S21S22S23
GraphQL 反序列化暫停受影響 Connection 欄位;限制不可信呼叫方僅做請求長度限制不能修復類型/反序列化問題 S25
Spring embedded LDAP不需要時停用;限制真實監聽連接埠的可達範圍預設管理身分與目錄完整性仍需檢查 S27
CPython SNI UAF官方方案:保留相關 SSLContext 強引用至服務結束必須覆蓋所有建立/切換路徑 S29
Python hostname 跳過官方方案:正確傳遞預期 server_hostname不能只檢查 check_hostname 標誌或忽略警告 S30S31
不可信 tar停用/隔離提取,拒絕非必要連結與設備條目過濾器與資源配額都不是通用沙箱 S32S40S45
憑證信任事件更新正確 CA 材料;Java 可依官方方案撤信關閉 TLS 校驗會擴大風險 S19S37

7.2 根據交付方式選擇補丁

交付方式優先修復方式應保留的證據
發行版管理運行時廠商對應安全更新完整包裝版本、公告、倉庫來源
官方二進位 / 運行時管理器同分支正式安全發布版本、來源與摘要、實際執行路徑
自編譯 Node / CPython分支匹配的正式原始碼版,或廠商完整回補集提交集合、建置參數、依賴函式庫與迴歸結果
Spring / Next / Django相容分支內更新,重建依賴鎖與最終應用最終依賴樹、JAR/包/鏡像中的實際版本
客製化信任庫官方撤信方案或確認包含撤信的廠商更新實際使用路徑、材料變更、TLS 正反向驗證
已被投毒的環境從乾淨可信產物重建,另行事件調查歷史包/鏡像 digest、安裝記錄、憑證輪替記錄

7.3 關鍵補丁機制與審閱重點

  • **Brotli:**關注原生解碼狀態的邊界檢查與錯誤回傳是否完整進入建置;只取代 JavaScript 套件無法改變靜態編譯進 Node 的程式碼。 S4
  • Node DNS / TLS : 關注輸入拒絕、地址規範化、 IP SAN 與 DNS 身份的區分,以及 DNS 回調式/Promise 式解析路徑和 TLS 主機名匹配測試。 S5 S6
  • **Tomcat JNDIRealm:**關注認證流程是否真正驗證憑證,而不只是獲得了一個目錄上下文;優先正式版本,不把單一來源檔案替換視為完整二進位修補程式。 S24
  • **CPython ssl:**關注 Python 引用所有權與底層 SSLContext 的生命週期;wrap_bio() 回補所有分支的實際實現。 S31S47
  • **證書撤信:**這類更新可能表現為信任材料或拒絕清單變化,而不是明顯的 API 變更。 Node 同批也納入了受影響中間 CA 的拒絕機制;Java 與 Python 各自的信任來源仍要分別驗收。 S19S37S46

**獨立 Brotli 綁定也要檢查。**Google 上游同日發表 1.0.10 / 1.1.1 / 1.2.1 修復 CVE-2026-111497。 Python 原生擴展或 JNI 產物若嵌入受影響的同一 C 實現,需要獨立更新/重建;不能推斷所有純 Java 解碼器都受影響,也不能認為升級 Node 自動替換其他語言的副本。 S42

8. 修復驗收與後續檢查

8.1 最小驗收清單

檢查項合格證據
運行時真實進程 / 容器內的完整版本或廠商回補證據正確
應用依賴最終部署產物中的 Next/RSC/sharp、Tomcat/Spring、Django/certifi 達到對應
替換範圍所有 worker/JVM/容器副本及後台任務已換新,舊實例退出
TLS合法網域憑證成功;不符合主機名稱、無效鏈按策略失敗;客製化信任庫已覆寫
eMudhra 撤信受影響中間 CA 所建證書鏈被實際運行時拒絕,或有具體廠商安全建置/相應拒絕清單已部署的證據;不能只憑一般 TLS 測試或 Java 8 短版號結案
Node 解碼與影像正常壓縮回應、上傳、影像優化與 RSC 功能可用;不可信來源策略生效
Java 認證與隔離錯誤密碼被拒絕;獨立使用者並發非同步請求沒有身分/回應混用;LDAP 監聽符合預期
Python SNI / 歸檔正常多域名 TLS 業務穩定;歸檔拒絕越界和非允許鏈接,目錄外文件不被修改
數據與功能回歸分頁、空間查詢、權限檢查和後台任務通過項目既有測試
資源與觀測CPU、記憶體、錯誤率、延遲及 TLS 錯誤沒有異常增長
可追溯性儲存升級時間、套件/鏡像摘要、配置變更、驗證結果和未解決項

這些是實施驗收建議,不要求為每個 CVE 製作攻擊腳本。涉及崩潰、資源耗盡、歸檔越界的驗證,應在隔離環境中使用上游回歸測試或專案受控測試資料。

8.2 修補與入侵調查是不同工作

檢查已有日誌中的異常解碼錯誤、worker/JVM 崩潰、可疑檔案寫入、目錄資料變更、認證異常、出站請求和憑證使用記錄。這些跡象需要結合上下文判斷:一次崩潰或 OOM 不是成功利用的證明;沒有警告也不是未受影響的證明。

發現未授權修改、憑證外洩或已確認惡意依賴時,應保存證據、隔離相關實例、從可信任環境輪調受影響憑證,並重建系統。修補程式不會撤銷已被攻擊者取得的令牌或恢復已被修改的資料。

9. 供應鏈安全事件:LiteLLM 1.107.0 投毒

**官方確認日期:2026-10-21。**LiteLLM 報告其發布流水線被入侵,PyPI 的 litellm==1.107.0 以及同期 Docker/GHCR 部分產物含竊S41

受影響判斷應查看歷史安裝記錄和鏡像 digest;latest、main-latest、main-stable 等標籤現在指向乾淨鏡像,不證明事發時拉取的產物乾淨。當時官方建議臨時固定 1.106.2;此建議針對此事件,部署時仍需核對其他安全公告。 S41

對安裝或運行過相關產物的環境:

  1. 隔離並保全安裝記錄、鏡像和日誌,從乾淨環境檢查。
  2. 不要先啟動可疑環境裡的 Python/pip;惡意 .pth / sitecustomize.py 可能隨啟動再次執行。
  3. 從可信任來源重建宿主、venv/容器;不能只卸載或降級包。
  4. 依實際可存取範圍撤銷/輪換雲端憑證、LLM provider key、LiteLLM 金鑰與資料庫憑證,並審查異常使用。 S41

這是已經確認的供應鏈事件,處置時需要同時考慮惡意程式碼執行、憑證外洩及持久化風險。截至 2026 年 10 月 23 日,官方仍在調查初始入侵過程。

附錄:引用來源與鏈接

以下來源核驗日期為 2026-10-23,包括專案官方安全公告、官方程式碼倉庫和廠商說明。正文 [Sx] 對應本附錄;執行更新時應檢查供應商是否發布了後續修訂。

S1 — Node.js:2026-10-21 安全公告

  • 用途:四項運行時 High、影響分支、10 月安全發布。
  • 參考連結: 官方安全公告

S2 — Node.js:三條維修線的正式發布說明

S3 — Vercel:Node.js Brotli RCE 安全通告

S4 — Node.js:Brotli 官方修補提交

S5 — Node.js:TLS 位址規格化修補

S6 — Node.js:DNS NUL 校驗修補

S7 — Node.js:2026-07-29 安全公告

S8 — Next.js:2026-10-14 安全性更新

參考連結: S9 — Next.js:typed arrays / use cache RCE

參考連結: S10 — React:React Server Components RCE

參考連結: S11 — Next.js:SVG Image Optimization RCE

參考連結: S12 — Next.js:Server Actions DoS

S13 — Next.js:AVIF 影像優化 RCE

參考連結: S14 — Next.js:Windows RCE

參考連結: S15 — Next.js:next/og ImageResponse RCE

S16 — Oracle:2026 年 10 月 CPU

S17 — Oracle:CVE-2026-91403 帶外警報

  • 用途:2026-10-21,JSSE 憑證信任風險、受影響產品與 CVSS 3.1 9.1。
  • 參考連結: Oracle Security Alert

S18 — Oracle:JDK 正式版本與下載

S19 — Oracle:eMudhra 臨時撤信方案

S20 — Eclipse Adoptium:發佈建置記錄

  • 用途:Temurin 受憑證事件影響而重新包裝;不能機械套用 Oracle 版本字尾。
  • 參考連結: Adoptium Release Scorecards

S21 — Apache Tomcat 9 安全公告

S22 — Apache Tomcat 10 安全公告

S23 — Apache Tomcat 11 安全公告

S24 — Apache Tomcat:JNDIRealm 修補提交

參考連結: S25 — Spring:GraphQL CVE-2026-59285

參考連結: S26 — Spring:GraphQL CVE-2026-41699

參考連結: S27 — Spring Security:CVE-2026-59270

參考連結: S28 — Spring Security:CVE-2026-47841

  • 用途:WebAuthn 使用者驗證、session 序列化與攻擊前提。
  • 參考連結: WebAuthn 安全公告

S29 — PSF:CVE-2026-19445 獨立安全公告

S30 — PSF:CVE-2026-19553 獨立安全公告

S31 — CPython:wrap_bio 正式補丁與 3.12 回補

S32 — PSF:CVE-2026-82049 獨立安全公告

S33 — CPython:9 月底 / 10 月初正式安全發布

S34 — CPython:3.10 最後一次安全發布

  • 用途:3.10.22 及上游生命週期結束。
  • 參考連結: Python 3.10.22

S35 — CPython:2026-10-21 緊急維修版本

S36 — certifi:emSign 證書撤信公告

S37 — PSF:eMudhra / emSign 對 Python 用戶的影響

S37 所引官方說明提供的 pip 引導升級指令如下。僅在已確認可信賴的 Python 環境中使用;若存在第 9 節投毒嫌疑,先依事件流程隔離和重建。它固定 wheel 內容哈希,隨後再按專案流程更新其他依賴。

python -m pip install "pip @ https://files.pythonhosted.org/packages/3f/06/3e4420302363fbb71be3c7f35ce042f54bfca330e3e66b3a2e3c4cca579f/pip-26.2.2-py3-none-any.whl#sha256=fd7f4dfa8190e014013b9f08f3e973f4e4c26ffd179a204895533a7254813a70"

S38 — Django:2026-08-04 安全發布

  • 用途:CVE-2026-15307、GeoDjango 利用條件、初始修復及相容性變更。
  • 參考連結: Django 6.0.8 / 5.2.17

S39 — Django:2026-10-06 安全發布

S40 — PSF / CPython:最新 tar_filter 附註

S41 — LiteLLM:10 月 21 日官方供應鏈事件報告

S42 — Google Brotli:官方安全版本

  • 用途:獨立 Brotli 1.0.10 / 1.1.1 / 1.2.1 及跨語言嵌入副本核查依據。
  • 參考連結: Brotli releases

S43 — mise:use 指令官方文檔

  • 用途:指定工具版本、全域配置的命令語意。
  • 參考連結: mise use

S44 — PyPA:pip-audit 官方項目

  • 用途:Python 依賴漏洞審計的用途與能力邊界。
  • 參考連結: pip-audit

S45 — Python:tarfile 提取過濾器文檔

S46 — Node.js:中 CA 拒絕機制

  • 用途:本次 eMudhra 相關信任鏈處理,不等同所有根憑證的密碼學失效。
  • 參考連結: Node.js PR #66871

S47 — CPython:SNI UAF 技術記錄與修補