2026-05-31 — CVE-2026-48710 BADHOST Starlette、TanStack 供應鏈蠕蟲、iOS MTE 深度解析

CVE-2026-48710 BADHOST：Starlette Host Header 繞過影響 FastAPI、LiteLLM、vLLM 整個 Python AI 生態

marcelotryle.com / NVD · 2026-05-28

Starlette 框架（FastAPI 底層）存在 Host header 注入漏洞 CVE-2026-48710（BADHOST），允許攻擊者透過一個字元繞過路徑型授權中介件（middleware）。受影響範圍涵蓋 FastAPI、LiteLLM、vLLM、text generation inference、大多數 OpenAI shim proxy、MCP server 與 Agent harness。CVSS 3.1 基礎分數 6.5（Medium），CWE-444（HTTP Request/Response Smuggling）。

漏洞機制

Starlette 在路由時使用原始 HTTP path，但在 request.url 屬性的建構時使用 Host header。攻擊者發送如下請求：

GET /admin/potato HTTP/1.1
Host: example.com/?

路由器正確分派至 /admin/potato 端點，但 request.url 重建後為 http://example.com/?/admin/potato，request.url.path 返回 / 而非 /admin/potato。中介件的路徑型 ACL 讀取 request.url.path，看到的是 /（允許），而路由實際執行 /admin/potato（應拒絕）。

受影響版本

Starlette 1.0.1 以前所有版本。觸發三個條件須同時存在：

應用程式使用路徑型授權中介件
網路層不驗證 Host header
授權邏輯依賴 request.url.path 而非 request.scope["path"]

修補與緩解

升級至 Starlette 1.0.1（依照 RFC 9112 §3.2 / RFC 3986 §3.2.2 驗證 Host header，無效時使用 scope["server"] 作為 fallback）。短期緩解：將授權邏輯改為使用 request.scope["path"]，此值直接來自 ASGI server 的路由決定，不受 Host header 影響。此外，在反向代理層（nginx、Envoy）過濾 Host header 中的 /、?、# 字元也可降低攻擊面。Starlette maintainer Marcelo Trylesinski 在修補完成後公開了維護者視角的披露過程批評，指出研究者在補丁可用前建立品牌化漏洞頁面（badhost.org）的做法對使用者沒有實際幫助。

原始來源：維護者部落格、NVD CVE-2026-48710

Mini Shai-Hulud：TanStack npm 三層攻擊鏈事後分析，160+ 套件遭供應鏈蠕蟲感染

TanStack · 2026-05-21

2026 年 5 月 11 至 12 日，威脅組織 TeamPCP 透過「Mini Shai-Hulud」行動，在不到 26 分鐘內發佈 84 個惡意 npm 版本並感染 160 餘個套件，包含 Grafana Labs 在內的多個組織程式碼庫遭竊，收到勒索要求。

攻擊向量：三層可組合漏洞

Pwn Request（pull_request_target 濫用）：TanStack 的 bundle-size.yml workflow 使用此 trigger，允許 fork PR 在 base repo runner 上執行任意指令。

GitHub Actions Cache Poisoning：惡意步驟將感染的建構工具鏈寫入共用 cache，後續合法 workflow 在 restore 步驟載入受污染二進位。

OIDC Token 記憶體提取：從 runner 行程記憶體 dump 出 npm Trusted Publishing 的 OIDC token，取得無需 2FA 的套件發佈能力。

Payload 行為與蠕蟲傳播

惡意 payload 竊取 AWS、GCP、Kubernetes、Vault、GitHub、npm、SSH 憑證，透過 Session/Oxen 加密 messenger 外傳。蠕蟲特性使感染以受害者維護者身份自我複製至其他套件，這是 160+ 套件被感染的主要機制。Grafana Labs 在輪換 workflow token 時遺漏一個，導致 5 月 16 日原始碼遭竊及勒索要求，公司拒絕支付。

系統性修復

禁用或嚴格限制 pull_request_target workflow
設定 GitHub Actions cache 隔離（只能由同一 repository 恢復）
為 npm Trusted Publishing 設定 environment protection rules
啟用 npm Provenance 使套件版本可追溯至 CI job
部署 StepSecurity Harden-Runner 進行 runner 行程監控

原始來源：TanStack Postmortem、Orca Security、Grafana Labs

iOS Memory Tagging Extension 深度解析：ARM MTE 在 Apple Silicon 的實際防護能力

Fuzzing Labs · 2026-05-30

ARM Memory Tagging Extension（MTE）是 ARM v8.5-A 引入的硬體記憶體安全機制，透過為每個記憶體分配單元加上 4-bit tag 並在指標中嵌入對應 tag，在存取時硬體驗證 tag 是否匹配。Fuzzing Labs 發表 iOS MTE 實作的深度技術分析，探討 Apple 如何在 A14+ 晶片上啟用 MTE，以及其對實際利用技術的影響。

iOS MTE 實作特徵

Apple 在 iOS 上以 Async MTE 模式為預設，在高風險分配（如 NSObject 子類別、XPC 訊息緩衝區）使用 Sync MTE。關鍵設計選擇：

Quarantine 機制：釋放後的 heap chunk 不立即重用，以隨機 tag 標記，使 use-after-free 利用更難穩定
Tag Entropy：分配時從 PRNG 生成 4-bit tag，攻擊者需暴力猜測（最多 16 次嘗試），在 Sync 模式下每次猜錯觸發 SIGSEGV
IOKit 整合：核心態 IOKit 物件同樣受 MTE 保護，提升 kernel exploit 難度

對利用技術的影響

傳統 heap feng shui 技術在 MTE 下需要額外步驟：攻擊者必須同時控制 tag（tag oracle 攻擊）才能建立穩定的讀/寫原語。研究者展示 tag oracle 攻擊的可行性：透過計時側信道或特定 API 的行為差異間接推斷 tag，但成功率與穩定性顯著低於 non-MTE 環境。MTE 不能完全阻止利用，但將有效利用的開發成本提升 2–5 倍，並增加利用的可偵測性（tag 錯誤觸發明確的崩潰）。

原始來源：Fuzzing Labs

End of article