續(xù)命 MinIO：承諾兌現(xiàn)

兩個月前，我在《》里立了一個 flag，接盤上游跑路留下的爛攤子，跟 CVE 修 Bug。那篇文章上了幾個小時(shí)的 Hacker News 首頁頭條。鼓勵不少，質(zhì)疑也不少：一個人，真維護(hù)得了這種項(xiàng)目嗎？

這個問題其實(shí)問得很好。因?yàn)檎嬲娬嬲碌臅r(shí)刻，不是點(diǎn) fork 按鈕，也不是改 README 文檔，而是當(dāng)安全漏洞真砸下來的時(shí)候。現(xiàn)在，這件事可以交賬了。

4 月 15 日到 17 日，三天時(shí)間，pgsty/minio 發(fā)布了 RELEASE.2026-04-17，連續(xù)修掉并關(guān)閉了 4 條 CVE 加幾條同期披露的安全漏洞，OIDC JWT 算法混淆（CVSS 9.8）、LDAP 登錄用戶名枚舉與暴力破解、復(fù)制頭元數(shù)據(jù)注入導(dǎo)致對象不可讀、S3 Select 超大記錄打穿內(nèi)存，以及兩條 unsigned-trailer 寫入路徑上的簽名繞過。

A promise made, a promise kept.

上游發(fā)生了什么

2025 年 12 月，MinIO 把開源倉庫改成 維護(hù)模式[3]。README 里寫著 “安全修復(fù)會逐例評估”。 到 2026 年 2 月，倉庫直接歸檔，首頁變成了 “當(dāng)前倉庫已經(jīng)不再維護(hù)”。但同一個倉庫的 SECURITY.md[4] 還留著：“我們總會為最新版本提供安全更新”。

而最近一個月，MinIO 又暴漏出四個高危漏洞，兩個中危，覆蓋最后的開源版本。而在官方公告里寫道：他們的商業(yè)版本 AIStor 修復(fù)了這些問題，給開源用戶的建議是：“升級到 AIStor”。

順便一提，MinIO AIStor 入門起步價(jià)約 10 萬美元/年，400 TiB，單價(jià)基本跟 AWS S3 差不多 —— 離了大譜，畢竟這是純軟件。一種很精致的玩法。倉庫歸檔了，道義責(zé)任撇清了；但 CVE 通告照發(fā)，既能刷一波 “我們很負(fù)責(zé)任” 的存在感，又恰好能把用戶趕進(jìn)商業(yè)版的羊圈。

只是還得有人得把這坑填上。

這次修了什么

這篇文章我不想寫成漏洞分析報(bào)告。具體每一條的 CVSS 分?jǐn)?shù)、攻擊鏈、PoC 代碼，我在 發(fā)布注記[5] 里都一一列了，感興趣的朋友可以去看。這里只說一句話版本：

?CVE-2026-33322（OIDC JWT 算法混淆，CVSS 9.8）：在特定 IdP 配置下可以偽造任意身份，包括 consoleAdmin。攻擊者只要知道 OIDC ClientSecret，數(shù)學(xué)上就能簽出一張 “我是管理員” 的通行證，MinIO 會乖乖驗(yàn)證通過。影響范圍從 2022 年 11 月到今年 3 月，三年半。?CVE-2026-33419（LDAP STS 登錄枚舉與暴力破解）：攻擊者可以先用登錄接口枚舉出真實(shí)用戶名，再無速率限制地爆破密碼，最后直接拿到 STS 憑證。整個鏈條從頭到尾沒有一道閘。?CVE-2026-34204（復(fù)制頭元數(shù)據(jù)注入）：普通 PUT / COPY 請求里夾一些 X-Minio-Replication-* 頭，就能把對象寫成永久不可讀狀態(tài)，數(shù)據(jù)還在，但你再也讀不出來。?CVE-2026-39414（S3 Select 內(nèi)存耗盡）：一條惡意請求，就可以把 MinIO 進(jìn)程吃到 OOM。?GHSA-hv4r-mvr4-25vw / GHSA-9c4q-hq6p-c237：unsigned-trailer 路徑上的兩條簽名校驗(yàn)繞過，匿名或偽造簽名的請求可以在某些路徑下成功寫入對象。

再加上 go-jose、go.opentelemetry.io 和 Go 1.26.2 自身吸收的一連串標(biāo)準(zhǔn)庫與依賴 CVE，這一版本聚合了接近二十條安全條目。

有的能偽造身份拿到高權(quán)限訪問，有的能把登錄入口拿去枚舉和爆破，有的能把對象寫成永久不可讀，有的能用一條請求把服務(wù)吃到 OOM，還有的能在缺失簽名校驗(yàn)時(shí)直接寫入對象。這不是小修小補(bǔ)，這是實(shí)打?qū)嵉木S護(hù)責(zé)任。

這次怎么修的

在之前那篇文章里，我明確說過我會用 AI Coding Agent 來維護(hù)這個項(xiàng)目，事實(shí)上我也是這么做的。這一輪修復(fù)里，我扮演了一個 Blind Manager 的角色。

簡單解釋一下我的工作范式。具體到每一條漏洞，流程大致是：

1.Codex 先打鐵：根據(jù) CVE 描述和相關(guān)代碼路徑，產(chǎn)出第一版補(bǔ)丁。2.Claude Code 做 review：站在對抗視角挑毛病。3.回到 Codex：我要求它，如果你同意 Claude Code 的意見，那就返工；如果不同意，那就反駁，把理由寫清楚。4.把所有思路攤開，再交給 Claude Code 做一輪 review。必要時(shí)來回再跑幾輪，直到兩邊收斂。5.進(jìn)行測試：依然是類似的對抗操作，由 Codex 設(shè)計(jì)測試用例，Claude 補(bǔ)充。然后由 Codex 去實(shí)際執(zhí)行并產(chǎn)出結(jié)果，再由 Claude Code review。6.我來定奪：看 diff，跑測試，做最后決策與驗(yàn)收。

這個過程中，我自己不寫一行代碼。我的工作是定義問題、約束邊界、挑方案、看 diff、跑驗(yàn)收、拍板。

公開提交頁上，你能直接看到 Vonng、Codex、Claude Code 三個名字同時(shí)出現(xiàn)在幾條關(guān)鍵安全提交的 Co-authored-by 里。這不是作秀。這就是 2026 年一個人維護(hù)一個中型基礎(chǔ)設(shè)施項(xiàng)目的真實(shí)樣子。

這種協(xié)作模式有幾個實(shí)際的好處。

第一，兩個 agent 對抗能篩掉大部分“聽起來都對、實(shí)際上不對”的方案。 單獨(dú)一個 agent 在修復(fù)安全漏洞時(shí)會有一種 “幻覺級自信”，寫出一份解釋流暢、看起來干凈的補(bǔ)丁，但漏掉了一個邊界條件。讓另一個 agent 從敵對視角審視它，這種方案很難活過第一輪。

第二，逼出顯式的權(quán)衡。 兩家不同實(shí)現(xiàn)路徑撞上了，自然就要回答 “為什么你選 A 而我選 B”。這個對話本身就是在把隱性假設(shè)顯性化，而顯性化的假設(shè)，才是我作為 Blind Manager 能拍板的東西。

第三，真正的維護(hù)是“補(bǔ)丁打補(bǔ)丁”，而不是一把梭。 拿 LDAP STS 這條洞來說，首版修復(fù)推出來以后，很快發(fā)現(xiàn)成功請求不該消耗限流額度、默認(rèn)不該信任 X-Forwarded-For、限流賬戶要按 “源 IP + 歸一化用戶名” 雙維度算賬。 然后又連著補(bǔ)了三次提交才算收斂干凈。這個過程如果沒有 agent 的火力支持，單個 maintainer 要一邊讀代碼一邊迭代，成本是完全不一樣的。

有些事還是要人來拍板

但也正因?yàn)檫@個模式運(yùn)轉(zhuǎn)得不錯，maintainer 唯一的不可替代性，就凸顯在那些 AI 給不出最后答案的地方。

最典型的就是 OIDC 那條 fix。表面上，它是一個 JWT 算法混淆漏洞；但實(shí)質(zhì)上，它是一個兼容性和安全性之間的取舍。

簡單解釋一下。JWT 的簽名算法分兩類：非對稱（RS256、ES256 這類，簽名用私鑰、驗(yàn)簽用公鑰）和對稱（HS256 這類，簽名和驗(yàn)簽用的是同一個密鑰）。OIDC 的標(biāo)準(zhǔn)姿勢是 IdP 用自己的私鑰簽 token、MinIO 用公開的 JWKS 拿到公鑰來驗(yàn)簽。公鑰是公開的，攻擊者拿不到私鑰，所以沒法偽造。

而 HS256 這類對稱算法的問題在于：簽名和驗(yàn)簽用的是同一個密鑰。這個密鑰就是 MinIO 自己也存著的 ClientSecret。于是攻擊者只要拿到這個 “共享秘密”，就既能當(dāng)裁判又能當(dāng)運(yùn)動員。自己用它簽一張 token，MinIO 拿自己存的同一個密鑰一驗(yàn)，當(dāng)然通過。

這在教科書上是 JWT 的經(jīng)典反模式，但歷史代碼就是這么走過來的。修法有幾條路可選：

?繼續(xù)容忍這條歷史路徑，只在某些條件下收窄：保留向后兼容，但安全邊界依舊模糊。?嚴(yán)格 JWKS-only，拒絕 HS256 等對稱簽名 token：一刀切、安全邊界清晰，但少數(shù)本來就配得模糊的用戶會感到配置失效。

兩個 agent 可以給我列出每個方案的 trade-off，可以寫好任何一個方案對應(yīng)的補(bǔ)丁，但它們不會替我決定。最后我的選擇是后者，恢復(fù)嚴(yán)格的 JWKS-only 驗(yàn)證路徑，明確拒絕不該接受的 HS256。

這個決定也許會讓少數(shù)模糊配置失效，但安全邊界終于清楚了。AI 可以提三個方案，真正承擔(dān)后果的人還是 maintainer。

這就是 Blind Manager 模式的上限，也是下限：機(jī)器負(fù)責(zé)窮盡方案，人負(fù)責(zé)選擇方向。

不是情懷，是必需

我一直說，這個 fork 不是情懷，也不是 cosplay。它存在，首先是因?yàn)檫@是我自己要用的東西。

MinIO 是 Pigsty 的生產(chǎn)依賴。我需要可用的二進(jìn)制、完整的控制臺、持續(xù)可得的包，以及真正有人處理的 CVE 補(bǔ)丁。也正因?yàn)槲易约涸谟茫赃@條線沒有太多空話空間：它不是拿來講故事的，而是拿來頂生產(chǎn)環(huán)境的。

這也決定了我的策略很保守。不會去追求 “新特性很酷”，也不會把倉庫弄成另一個方向的實(shí)驗(yàn)場。我的目標(biāo)一直都很明確：保持兼容，守住供應(yīng)鏈，在該修的時(shí)候把問題修掉。

到現(xiàn)在，這個分支在 GitHub 已經(jīng)有了 1300 star，在 Docker Hub 也累計(jì)了 五萬+ 下載。數(shù)字本身不算什么驚人的成就，但它至少說明了一件事：需要這條線的人，并不只有我自己。

對已經(jīng)在用 MinIO 開源版的人來說，遷移到這個分支的成本其實(shí)很低：

?Docker 鏡像：把 minio/minio 換成 pgsty/minio，一行的事。?RPM / DEB：GitHub Release[6] 里都有，或者用 pig 一鍵裝。?源代碼倉庫：pgsty/minio[7]?文檔鏡像站：silo.pigsty.cc[8]?英文文檔：silo.pigsty.io[9]

你不需要換掉整個系統(tǒng)，也不需要重新學(xué)習(xí)一套對象存儲；多數(shù)情況下，只是把一個失去維護(hù)的上游，替換成一個還會繼續(xù)交付補(bǔ)丁的分支。

如果你需要完整的生產(chǎn)級部署方案，Pigsty 里也提供了開源免費(fèi)、開箱即用的 MinIO 生產(chǎn)級高可用部署支持。

承諾是什么

對老馮來說，這就是一件很普通的事情，用的東西壞了，自己修一下。僅此而已。

只是到了 2026 年，“自己修一下” 這件事的門檻，被 AI Coding Agent 重新定義了。一個人，加兩個 agent，加一點(diǎn)點(diǎn)判斷力，足以把一個六萬 star 的中型基礎(chǔ)設(shè)施頂起來。這不是我厲害，這是時(shí)代變了。

以前我們談?wù)撻_源的韌性，談的是 “社區(qū)”，幾十上百個志愿者眾籌時(shí)間。現(xiàn)在這套劇本還在，但底下多了一層保險(xiǎn)：哪怕社區(qū)散了，只要有一個人還愿意按下 fork 按鈕，項(xiàng)目就能續(xù)命。

承諾是什么？承諾是 “下一個 CVE 出來的時(shí)候，我還在”。

下一個 CVE 出來的時(shí)候，老馮還在。

就這樣。

References

[1] MinIO 已死，MinIO 復(fù)生: https://vonng.com/db/minio-resurrect/
[2]RELEASE.2026-04-17:https://github.com/pgsty/minio/releases/tag/RELEASE.2026-04-17T00-00-00Z
[3]維護(hù)模式: https://github.com/minio/minio/commit/27742d469462e1561c776f88ca7a1f26816d69e2
[4]SECURITY.md: https://github.com/minio/minio/security
[5]發(fā)布注記:https://silo.pigsty.cc/reference/release-note
[6]GitHub Release:https://github.com/pgsty/minio/releases
[7]pgsty/minio:https://github.com/pgsty/minio
[8]silo.pigsty.cc:https://silo.pigsty.cc
[9]silo.pigsty.io: https://silo.pigsty.io

數(shù)據(jù)庫老司機(jī)

點(diǎn)一個關(guān)注 ??，精彩不迷路

對 PostgreSQL， Pigsty，下云，AI 感興趣的朋友

歡迎加入 PGSQL x Pigsty 交流群 QQ 619377403