MinIO 發布10分安全漏洞

老馮：這是 RustFS 朋友寫的文章，提醒大家 MinIO CVE 風險。最近 RustFS 剛剛 Beta1 了，據說七月份準備 GA，老馮也挺期待看看正式版本能不能 Drop-In Replace MinIO。如果您準備繼續使用 MinIO，除了換成 RustFS，購買 MinIO AI Stor 商業支持，也可以試試老馮維護的分支 pgsty/minio，，目前已有 1.5K Star 與十萬+ Docker Pull，一些知名開源項目比如 Grafana Loki 也已經遷移到了該分支上。

? RustFS 官方提醒：如果你的生產環境正在使用 MinIO，但尚未購買MinIO商業技術服務或缺少持續安全響應機制，請盡快完成版本核查、訪問收斂、身份認證加固與應急預案梳理。同時，建議在測試環境中驗證 RustFS，提前為對象存儲架構留出更穩妥的演進路徑。

過去一段時間，MinIO再次爆發多個安全漏洞，并且出現了10.0級別的高危漏洞。對仍在使用 MinIO 社區版本、且沒有商業技術服務保障的團隊來說，現在需要重點關注的不是某一個單點漏洞，而是三個更現實的問題：

1. 是否能夠第一時間判斷當前版本是否受影響；

2. 是否具備經過驗證的升級、回滾和補丁流程；

3. 是否有對象存儲替代方案的測試與遷移預案。

? ?? 高危預警： 本次公告涉及 6 個安全漏洞，其中 4 個評級為 CRITICAL（嚴重），最高 CVSS 評分達 10.0。建議所有使用 MinIO 或相關組件的用戶立即評估影響并采取緩解措施。

CVE 編號

涉及組件

漏洞類型

CVSS 評分

嚴重程度

CVE-2026-30240

Budibase / MinIO

路徑遍歷 / 文件讀取

9.6

CRITICAL

CVE-2026-33322

MinIO OIDC

JWT 算法混淆 / 身份偽造

9.2

CRITICAL

CVE-2026-33419

MinIO AIStor STS / LDAP

憑據暴力破解 / 用戶枚舉

9.1

CRITICAL

CVE-2026-34204

MinIO PutObject

加密元數據注入

7.1

HIGH

CVE-2026-34976

Dgraph / MinIO S3

缺失授權 / SSRF / 數據庫覆寫

10.0

CRITICAL

CVE-2026-39414

MinIO S3 Select

內存耗盡 / DoS

7.1

HIGH

從風險類型看，這些問題覆蓋身份偽造、憑據暴力破解、路徑遍歷、服務端請求偽造、數據庫覆寫、元數據注入和拒絕服務等場景。對于沒有持續安全響應機制的團隊，建議不要只做單點版本判斷，而要同時檢查外網暴露、身份源配置、訪問密鑰、Bucket 策略和備份恢復流程。

為什么要現在處理

對象存儲的風險通常不會只停留在存儲服務本身。它與 IAM、OIDC、LDAP、KMS、網關、備份系統、數據分析組件和應用 SDK 深度綁定。當對象存儲對公網暴露、控制臺弱保護、身份源配置不嚴、訪問密鑰長期不輪換時，攻擊者獲得的可能不只是一個 Bucket 的讀寫權限，而是進入整個平臺數據面的入口。

如果企業沒有購買商業技術服務，也沒有內部專職團隊持續跟蹤安全公告，就更容易遇到以下情況：

• 漏洞公告已經發布，但生產環境版本仍長期停留在舊版本；

• 修復版本可用，但缺少灰度、兼容性測試和回滾方案；

• 安全組、控制臺端口、管理 API、STS、LDAP/OIDC 接口暴露范圍過大；

• 訪問密鑰多年不輪換，權限策略過寬，審計日志不完整；

• 備份恢復流程沒有演練，真正故障時無法確認數據一致性。

這些問題在平時看起來只是“運維債務”，在漏洞窗口期就會變成直接風險。

建議立即完成的安全自查

請優先從以下幾個方向進行檢查和加固。

1. 核查版本與公告

確認當前 MinIO 服務端版本、部署方式、鏡像來源、啟動參數與依賴組件版本。對照官方安全公告、CVE 信息和內部資產清單，判斷是否處于受影響范圍。

對于生產環境，不建議在沒有測試的情況下直接升級核心存儲組件。更合理的做法是先在測試環境復現現有配置，再驗證升級路徑、客戶端兼容性、權限策略、生命周期規則、復制任務、加密配置和備份恢復流程。

2. 收斂網絡暴露面

檢查對象存儲 API 端口、控制臺端口和相關管理接口是否對公網開放。非必要場景下，應通過安全組、防火墻、ACL、反向代理或 VPN 將訪問范圍限制在受信任網絡內。

重點關注以下對象：

• 對象存儲 API 端口；

• Web Console 或管理控制臺；

• OIDC、LDAP、STS、KMS 等身份與密鑰相關接口；

• 備份、同步、數據分析組件使用的對象存儲憑據。

對象存儲的長期訪問密鑰應被視為高敏感憑據。建議立即梳理所有 AccessKey、SecretKey、服務賬號、臨時憑據與外部身份源配置。

建議動作包括：

• 清理不再使用的訪問密鑰和服務賬號；

• 按業務最小權限原則重寫策略；

• 對高權限賬號執行密鑰輪換；

• 檢查是否存在共享 root 憑據、腳本明文憑據或長期未輪換憑據；

• 為認證接口增加限速、告警和異常登錄檢測。

請重點檢查公開讀寫策略、匿名訪問、跨賬號訪問、預簽名 URL 使用方式，以及業務系統中是否存在過寬的 s3:* 權限。

許多數據泄露并不是來自復雜攻擊，而是來自“臨時開了公開讀，后來忘了關”“測試賬號沿用到生產”“應用服務拿了管理員權限”這類長期存在的配置問題。

5. 建立補丁、回滾和應急流程

對象存儲升級應有明確的變更流程，包括測試驗證、數據備份、灰度發布、監控觀察、回滾策略和責任人。對于沒有商業技術服務保障的團隊，尤其需要提前把流程跑通，而不是在漏洞公開后臨時決策。

同步建議：在測試環境驗證 RustFS

RustFS 是面向云原生與企業級場景設計的高性能分布式對象存儲。對于正在評估對象存儲長期架構的團隊，我們建議不要等到生產環境出現風險時才開始尋找替代方案，而是盡早在測試環境中完成驗證。

你可以從以下場景開始：

• 使用現有 S3 SDK 或應用接入 RustFS，驗證基礎讀寫、分片上傳、預簽名 URL；

• 遷移一組非核心 Bucket，測試對象元數據、目錄約定和業務兼容性；

• 驗證 IAM 策略、訪問密鑰管理、Bucket Policy 與審計日志；

• 測試備份恢復、節點故障、擴容和重啟場景；

• 對比關鍵業務負載下的吞吐、延遲和資源占用；

• 將 RustFS 納入現有監控、告警、日志和變更流程。

測試的目標不是“一步替換生產”，而是讓團隊在安全、成本、性能和可控性之間有更多選擇。當真正需要調整架構時，已經有數據、有流程、有驗證結論。

給運維與安全團隊的一份短清單

如果你今天只能做幾件事，建議按以下順序處理：

1. 盤點所有 MinIO 實例、版本、部署位置和公網暴露情況；

2. 關閉非必要公網訪問，尤其是控制臺和管理接口；

3. 核查是否使用 OIDC、LDAP、STS、KMS 等高風險集成；

4. 輪換高權限訪問密鑰，清理長期不用的賬號；

5. 檢查 Bucket Policy，移除不必要的公開訪問；

6. 建立升級測試環境，驗證補丁、回滾和備份恢復；

7. 在測試環境部署 RustFS，完成 S3 兼容性和業務鏈路驗證。

對象存儲是企業數據基礎設施的重要一環。安全加固不應只在漏洞公告發布后才被動進行，也不應完全依賴某一個產品版本或某一次升級。

RustFS 建議所有仍在使用 MinIO 且缺少商業技術服務保障的團隊，盡快完成安全自查和訪問收斂，建立可驗證的升級與應急流程，并在測試環境中評估 RustFS。越早驗證，越能在關鍵時刻保持主動。

如需開展 RustFS 測試驗證，可準備以下信息：當前對象存儲規模、Bucket 數量、對象數量、典型對象大小、客戶端 SDK、認證方式、部署環境、性能指標和備份恢復要求。基于這些信息，團隊可以更快形成可執行的測試方案。

本文為 RustFS 官方安全提醒文章，旨在幫助對象存儲用戶提升風險意識并開展安全加固。具體生產變更請結合自身環境、官方公告和內部變更流程審慎執行。

請盡快開始測試RustFS，為安全升級預留出可靠的時間。