CVE-2026-48710 的揭露時間軸——Python 維護者怎麼在 30 天內處理一張責任券

這是 Marcelo Trylesinski 五月二十八日刊在自己 blog 的長文 「A maintainer's perspective」攤出來的東西——一條從私信通報、reproducer 驗證、補丁開發、 編號申請、advisory 發佈、到 Ars Technica 電郵叩門的完整時間軸。

對 OSS 維護者，這是一份現成的劇本；對任何用 Starlette 或 FastAPI 在前線跑業務的 backend 工程師， 這是「我什麼時候會看到 patch、為什麼這次的揭露節奏這麼怪」的具體答案。

這篇文章值得記下來的不是 CVE 本身的技術細節——後者一句話就能說完：路由用原始 HTTP path 比對， request.url 卻從客戶端可控的 Host header 重新拼裝， 於是中介層拿 request.url.path 做授權判斷時，兩條 path 可能不一致。

真正值得記的，是 Trylesinski 把整條揭露管線上四個角色——通報者（X41 D-Sec）、維護者（自己）、 advisory 基礎設施（GitHub Security Advisory）、媒體（Ars Technica）—— 每個角色的誘因、權限邊界、可以踩到別人腳的地方逐一拆開。

下面這張圖把四個角色排在同一條管線上，點任何一個都會展開該角色「擁有什麼決策權、不擁有什麼」。 這是看懂後面三十天 timeline 的 prerequisite——每一個 day 的事件都是某個角色在自己權限邊界內推進的動作， 而衝突發生在兩個角色的權限交界。

X41 D-Sec 的那封信——「roughly one-month」是一張責任券

時間軸從一封私信開始。

X41 D-Sec 是一家德國的 security 顧問公司，他們的研究員找到了 Starlette 的 Host header 處理漏洞， 按照產業慣例先私下通報維護者。

Trylesinski 在文章裡形容這次接觸「mostly polite」、X41「clearly acting in good faith」 ——這不是一場敵意的揭露，雙方都同意 bug 是真的、要修。

爭執的點在後面：時間軸怎麼定，advisory 怎麼發。

X41 的初始提案有兩個元素。

第一，「roughly one-month disclosure window」——大約一個月之後公開。

第二，提議在 patch 還沒上線前先把 advisory 推出去。

對任何把「揭露」想成「公開資訊」的人來說，這兩條都看起來合理：給維護者一個月、給使用者預警的時間。 但對維護一個 3.25 億週下載量套件的人來說，這兩條把使用者風險從「降低」變成「升高」。

為什麼一個月不夠？因為「修補 + 驗證 + 發版」不是維護者一個人就能完成的工作。

Starlette 的 release 流程包含 changelog、CI 全綠、Encode 組織內部 review、下游集成測試—— FastAPI 直接建在 Starlette 上，任何 breaking change 都會立刻在下游冒煙。

這些動作如果跟「揭露日期」reverse-engineer 回來推時程，會擠掉每一個 buffer。

同時 X41 沒有支付這套發行流程的責任券： 發 advisory 是 X41 的能見度，撤回有 bug 的 patch 是維護者的能見度，兩者不對稱。

為什麼「先 advisory 後 patch」是反向操作？

因為 advisory 是把利刃同時遞給防守方與攻擊方的動作，但只有攻擊方有把握接得住。

防守方拿到 advisory 後要做的事是：讀懂、評估自己有沒有 exposure、有的話要不要關功能、要不要降權限 ——這些動作每一個都需要時間。攻擊方拿到 advisory 後要做的只有一件：跑 scanner。

Trylesinski 對這個提案的回應是「horrible practice」、「the opposite of protecting users」 ——這兩句話直接放在他自己 blog 的最 prominent 位置，因為這是他想留下的這次案例最大教訓。

X41「to their credit」（Trylesinski 的原文用詞）在這個 push back 之後把 deadline 往後挪了—— 具體挪了多久 Trylesinski 沒寫，但「walked the deadline back once this was raised」 這個轉折讓整個 timeline 從緊迫變回可控。

這是整個 case 中「使用者風險被實際壓低」的關鍵一步——不是技術補丁，是 timeline 協商。

把這條協商攤平到一張可拖曳的時間軸上會更直觀。

下面這個 scrubber 涵蓋 30 天的揭露窗口，從 day-0 的 PSRT 收信開始一路滑到 day-30 的 advisory publish。

每一格的 state 描述告訴你「在這個時刻、什麼資訊已經 public、誰還在 dark」 ——這正是 embargo 設計的本意：讓資訊以對守方有利的順序、節奏釋放。

這條時間軸的形狀有兩個重要 invariant 值得記下。

第一，使用者一直到 day 30 才會看到任何資訊—— 不是「day 0 看到 advisory、day 30 看到 patch」，而是「day 30 advisory 與 patch 同步」。

這個順序的差別不只是公關修辭：advisory 一上線那一刻，全球所有 scanner 開始掃； 如果 patch 還沒在 PyPI 上、dependabot 就沒辦法 propose 升級 PR；下游也來不及反應。

第二，press 領先 advisory 的窗口只有「a couple of hours」。

本 case 險險踩到 worst case 邊緣，因為這個窗口的 size 是 X41 控制的—— X41 決定何時把稿子餵給 Ars，維護者沒有 veto 權，只能加速 publish 自己這邊的 advisory。

Dan Goodin 那封信送來的時間點不是巧合：press 寫稿需要時間，所以 X41 必須提前把細節給媒體； advisory 太晚 publish，press 就會領先；太早 publish，攻擊面就提早張開。

這條時間軸暴露的另一個事實：「揭露」其實是個 multi-actor、multi-channel 的廣播動作， 不是單一時點的開關。

把這套協商抽象出來：揭露 timeline 不是「資訊應該在何時 public」的單變量問題， 而是「在哪些 timing 上，守方比攻方多走多少步」的多人賽局。

Embargo 不是為了延後公開，而是為了確保使用者「先看到補丁、再看到漏洞」這個順序—— 一旦這個順序反過來，無論 advisory 寫得多誠實，使用者都會落在最不利的位置。

這個觀念與 Google Project Zero 90 天政策背後的設計直覺一致： P0 強制要求 patch 必須先於 advisory，過了 90 天無 patch，advisory 才會自動 publish—— 那是逼維護者動作的最後一根棒子，不是揭露的預設姿態。

Host header 那條 path 到底錯在哪裡——技術側的三十秒

把 timeline 暫時擺到一邊看技術細節。

Bug 本身的形狀其實樸素：Starlette 內部有兩套對「request 是 hitting 哪條 path」的判定。

第一套是 ASGI router——它從 ASGI scope 拿原始的 raw path，跟註冊好的 route table 比對，決定 handler 是哪個。

這條路徑沒有 bug，路由本身正確。

第二套是 request.url 屬性——這是個方便 middleware 與 handler 在執行期讀 URL 用的 derived property。

為了讓 request.url 看起來像「完整 URL」， Starlette 把它拼成 http://{host}{path}——這裡的 host 從 Host header 抽出來。

問題在於 Host header 是 client-controlled， 並且 Starlette 的舊版本在這個位置沒有對 header 內容做嚴格驗證。

這條 divergence 變成 vulnerability 的條件是：應用使用 middleware 對 path 做授權判斷—— 例如「/admin/* 需要 admin token」——而這個 middleware 讀的是 request.url.path。

很多範例程式碼這麼寫，文件也沒有明確說不能這麼寫； 讀 request.url.path 在直覺上是最自然的選擇，誰會想到它與 ASGI scope 的 path 不同源？

下面這個 tab 切換器把三個視角放在同一個 frame： vulnerable 版本的判斷邏輯、attacker 構造的請求、patched 版本的驗證。

# middleware.py（vulnerable Starlette <= 1.0.0）
async def auth_middleware(request, call_next):
    path = request.url.path                # 從 Host header 推導出來的 url 拼回來的 path
    if path.startswith("/admin"):
        if not is_admin(request.user):
            return Response(status_code=403)
    return await call_next(request)

# ASGI router 那邊用 raw path 走 routing：
# request.scope["path"] = "/admin/delete_user"     ← router 看到的
# request.url.path            = "/"                    ← middleware 看到的（攻擊成功）

$ curl -X POST https://app.example.com/admin/delete_user \
       -H "Host: example.com/?" \
       -H "Cookie: session=NOT_AN_ADMIN" \
       -d '{"user_id": 1}'

# 內部發生的事：
# 1. ASGI scope["path"] = "/admin/delete_user"
#    → router 比對 /admin/* 命中 delete_user handler
# 2. request.url = parse("http://" + "example.com/?" + "/admin/delete_user")
#    = http://example.com/?/admin/delete_user
# 3. request.url.path = "/"
# 4. middleware 看到 path = "/", 不是 /admin/*, 放行
# 5. delete_user 被執行，沒有 admin 檢查
HTTP/1.1 200 OK
{"deleted": true}

# Starlette 1.0.1 補丁——核心兩處

# (a) Host header 驗證——遇到不合法字元直接 400
def _parse_host(raw_host: bytes) -> str:
    decoded = raw_host.decode("ascii")
    if not _HOST_PATTERN.match(decoded):  # [A-Za-z0-9.-:] only
        raise InvalidHostError(decoded)
    return decoded

# (b) request.url.path 與 scope["path"] 同源
@property
def url(self) -> URL:
    # BEFORE: url 從 host header 重新組合，path 跑掉
    # AFTER:  path 直接拿 scope["path"]，與 router 看見的一致
    return URL(
        scope=self.scope,
        path=self.scope["path"],           # ← key fix
    )

# 同時官方 docs 加了警告：
# "授權檢查應該基於 scope['path']，不要基於 url.path。"

Bug 的形狀回頭看其實樸素：

兩個 derived value 從不同 source 來但被當同一個 truth 用—— 一個從 ASGI scope（trusted），一個從 client header（untrusted）—— 只要 application 程式碼選了第二個做安全判斷，就翻車。

這類 bug 在 web framework 裡反覆出現。

Django 早年有過類似 Host header 漏洞、Rails 的 X-Forwarded-Host 也踩過、 Express 對 trust proxy 的設定也是同一個範式的不同表達。

每一次的 fix 都長得不太一樣，但 underlying 範式是「客戶端可控的字段被當作 server-side 真相用」—— 從 SSRF 到 Host header injection 到 HTTP request smuggling，都在這個 family。

Starlette 的補丁同時做兩件事。

第一是堵 source：Host header strict validation——遇到不合法字元直接 400。

第二是消 divergence：讓 request.url.path 與 ASGI scope path 對齊到同一個 source。

第一件事的副作用是會 break 那些故意傳奇怪 Host header 的 client—— 這種 client 通常是測試工具或自製 proxy，數量極少。

第二件事完全 transparent——這也是 Trylesinski 願意在 1.0.1 patch release 而不是 major bump 的原因。

Public API surface 沒變，行為對「合法 client」也沒變，只對「畸形 client」改成 400 回應。

對下游使用者：升級 1.0.1 是必須的；但即便升級之後， 把 middleware 的授權判斷從 request.url.path 改成 request.scope["path"] 仍是合理的。

這不是 paranoia，是「不依賴未來不會踩到的 footgun」的 defensive 寫法。

Trylesinski 在文章裡特別點出這條 advice 的時候， 引用了 Giovanni Barillari 在 ASGI 社群裡的長期立場： 任何 authorization 邏輯都不應該被綁在 request 的 URL 表面字串上。

URL 是 client 可以 craft 的；scope 是 server 確認過的—— 對中介層而言，永遠選後者。

四個揭露窗口的標準——「30 天」到底激進不激進

X41 的 30 天提案在產業裡是什麼位置？

把幾個常見的揭露 timeline 並排比較會看得更清楚。

下面這張表把 Google Project Zero、Microsoft MSRC、CERT/CC、Linux distros@ 與 X41 D-Sec 的初始提案放在一起 ——同時列出補丁是否要求先於 advisory（這是本 case 真正的爭執點）、可不可延展、品牌頁的存在與否。

這張表攤開看會發現 X41 的 30 天提案在「窗口長度」這個維度上算中位偏緊，但不算 outlier ——OpenSSL 自己也是 30 天，CERT/CC 還更短的 45 天。

真正的 outlier 是另外兩件事。

第一，「patch 先於 advisory」這個業界共識—— 所有列在表上的揭露主體都把 patch-first 當作 default， X41 在初始提案中沒守住，後來在 push back 之後才修正。

這條紀律不是 nice-to-have，是揭露機制能持續運作的最低門檻： 一旦有先例「advisory 可以先於 patch」、未來所有揭露提案的協商成本都會上升。

第二，「品牌頁」這個慣例。

極少數機構會做——主要是 Heartbleed 那一脈：Codenomicon 與 Cloudflare 合作做 heartbleed.com。

Heartbleed 之所以做品牌頁是因為 bug 嚴重到需要全球用戶以最快速度認識 （OpenSSL 是當時全球 SSL 流量裡相當高比例的實作）， 並且做品牌頁的單位是 finder + Cloudflare 而非 finder 自己。

換句話說，品牌頁的歷史正當性是「規模 × 跨機構合作」——不是「我發現了 bug 所以我做 logo」。

X41 為一個「authorization bypass under specific middleware pattern」做品牌頁， Trylesinski 的反應「That is marketing a vulnerability」抓到了同一個直覺： bug 的嚴重程度與行銷強度之間 should be calibrated。

Linux distros@ 的 14 天上限值得特別記下。

這條 list 專門服務於「Linux 發行版需要時間 coordinate patch shipping」的場景， 比 Project Zero 或 MSRC 對單一專案的揭露更短， 因為 downstream 是已知集合：Debian、Red Hat、SUSE、Ubuntu 等等，可以做 push-based 通知。

application-level 套件——Starlette 這種——的 downstream 是未知集合， 必須走 pull-based：dependabot 拉、使用者自己讀 changelog。

所以 application library 的揭露窗口需要更長，讓 advisory 與 dependabot infrastructure 同步上線。

一個月在這個維度上其實偏短，但「先 patch 後 advisory」這條紀律守住了，30 天可以撐。

把 X41 的初始提案抽象化：30 天本身不是 outlier， 「patch 與 advisory 的順序」與「品牌頁的存在」才是真正破壞使用者風險預算的兩件事。

Trylesinski 的 push back 把第一件事修正了，第二件事他沒辦法干預—— X41 用自己的網域、自己的 logo 做的事 maintainer 沒有 veto 權。

他能做的只有把「That is marketing a vulnerability」這句話放在自己的 blog 上、 讓讀者自己判斷產業規範應該長什麼樣。

一篇 blog 對抗一個 marketing 網域——這就是 OSS 維護者揭露議價戰的 asymmetry： 通報者擁有預算、員工、PR 通路；維護者擁有一個 markdown 編輯器。

從這條 timeline 看出來的——使用者應該帶走的三個動作

把 timeline 從 day 0 拉到 day 30 之後， 這條揭露故事對 backend 工程師（特別是用 FastAPI 或 Starlette 跑 production 的）有三個可直接照做的動作。

第一，立刻升 Starlette 1.0.1 或之後版本。

如果你的 stack 是 FastAPI，這意味著升 FastAPI 到同步依賴新版 Starlette 的對應版本 ——FastAPI 的 release notes 會在它的下游 advisory 中標示這個依賴。

Dependabot 在 GHSA-86qp-5c8j-p5mr 上線後會自動 open PR， 但「自動 PR open 之後等多久 merge」由你自己決定。

別把這個 PR 排到下次 sprint，今天就 merge。

X41 的 scanner（badhost.org 上）會掃公開的 Starlette 部署， 你 1.0.1 升完之前，scanner 看得到。

第二，code review 你的 middleware： 任何讀 request.url.path 做授權判斷的地方，改成讀 request.scope["path"]。

這不是 1.0.1 之後的必要動作——補丁本身已經讓兩條 path source 對齊—— 但是「不依賴 framework 永遠不會踩同類 bug」的 defensive 寫法。

同樣的精神延伸到 request.url.hostname、request.headers["host"] ——任何 client-controlled value 都不應該進入安全判斷的決策路徑，要用就先驗證。

更廣義地說：在你的 middleware 與 handler 程式碼裡 grep request.url， 把每一個使用點 review 一遍——這個 property 對 logging、metric、redirect URL 拼接是安全的， 但對「決定使用者能不能 access」是脆弱的。

第三，把「我們收到 PSRT 通報之後怎麼做」這條 runbook 寫進你維護的 OSS 套件（如果你維護的話）。

Trylesinski 這篇 blog 本身就是這條 runbook 的模板—— 把它 fork 到你自己的 SECURITY.md 旁邊，根據你的 release flow 改細節。

要寫清楚的條目包括：誰是第一接觸窗口、reproducer 驗證的 SLA、可接受的 disclosure 窗口下限、 patch 與 advisory 的順序、advisory 草稿在哪個 portal 寫、和通報者要不要同步、和媒體要不要互動。

這些都應該在收到第一封 PSRT 信之前就寫好，不要在 30 天倒數時邊收信邊發明流程。

runbook 的價值不是抽象規範，而是議價時的 anchor—— 當通報者提一個你不接受的條件，你可以指向 SECURITY.md 說「這不符合本專案的揭露政策」， 把對話從「你不配合」變成「政策不允許」。

Trylesinski 在文章結尾留下的觀察是： 「authorization and authentication should not be based on the request's path, host, or query string in the first place. That's a fragile pattern regardless of this bug.」

這句話與 CVE 本身關聯有，但更深的意思是： 揭露這套機制（advisory、CVE、embargo）的目的是降低 systemic risk， 而不是讓 bug 個案被處理得體面。

如果你寫的應用 architecture 本身把 client-controlled value 直接用於授權判斷， 下次踩到的 CVE 不會長得跟這次一樣，但範式是相同的。

揭露管線只能 reactive 補洞，不能讓你免於 design-level 的脆弱。

最後一個尺度感的數字：3.25 億週下載。

這是 Ars Technica 給 Trylesinski 信裡引用的 Starlette 下載量 ——意思是這個 30 天 timeline 影響的不是一個套件、是整個 Python web 生態的近一半 API 服務。

維護者一個人在 30 天裡完成的事—— push back timeline、寫補丁、走 GHSA portal、跟 press 賽跑 ——同時是一張責任券：他不能委派，也沒有可以委派的對象。

這條責任券的不對稱性是 OSS 經濟模型的最深 quirk： 使用方有 3.25 億週下載量的 leverage，維護方有一個 GitHub handle 與一個 PyPI 帳號。

OSS 維護者在揭露 timeline 中的議價力來自於他願意說「不」的次數。

「不」於 advisory 先於 patch、「不」於 30 天太緊、「不」於 marketing 一個 bug—— 每一個「不」都把使用者風險往下壓一點點。

這次的 case 中，Trylesinski 至少說了兩次「不」，並且贏了其中一次半—— timeline 延展那次他完全贏，advisory 與 patch 順序那次他完全贏， 但 badhost.org 與 Ars Technica 賽跑那兩件事，他沒贏； 那是他權限邊界之外的事。

一個維護者能贏多少次「不」、輸多少次，會直接決定下游 3.25 億下載的使用者第一眼看到的是補丁還是 headline。

這就是為什麼這篇 blog 值得 backend 工程師讀完—— 它不是技術細節文，是揭露機制這個 invisible infrastructure 的 user-facing 說明書。

Take-away： 揭露 timeline 不是「資訊在何時 public」的單變量問題， 而是「守方比攻方多走多少步」的多人賽局—— 維護者議價力來自願意說「不」的次數，而使用者議價力來自願意立刻 merge dependabot PR 的速度。