CVE-2025-14847，又稱為「MongoBleed」（因 Heartbleed 而得名），是 MongoDB 伺服器中未經驗證的資訊外洩漏洞，影響多個受支援的舊版伺服器，並允許未經驗證的遠端攻擊者竊取敏感資料和驗證憑證。
此漏洞是由於基於 zlib 的網路訊息解壓縮邏輯中對長度欄位的處理不當造成的，該邏輯在身份驗證檢查之前執行。根本原因在於 message_compressor_zlib.cpp 檔案中。據 Censys 稱，全球約有 87,000 個實例暴露於該漏洞，而 Wiz 的研究表明，42% 的雲端環境至少託管了一個易受攻擊的實例。
2025年12月26日，可用的漏洞程式碼被公開，隨後不久便確認漏洞已被實際利用。受影響的版本包括8.2.x、8.0.x、7.0.x、6.0.x、5.0.x、4.4.x、4.2.x、4.0.x和3.6.x，但尚未提供4.2.x及更早版本的修復程序。 MongoBleed Detector工具已發布。
從： 
MongoBleed（CVE-2025-14847）現已在野外被利用
【社論】
「MongoBleed」這個名稱源自於2014年震驚世界的OpenSSL漏洞「Heartbleed」。 Heartbleed漏洞讓攻擊者讀取任意記憶體區域，原因是TLS/SSL協定的心跳函數中長度參數的驗證不當。 MongoBleed在技術上與之非常相似，它也是由於長度欄位不匹配而導致記憶體內容洩漏。
此漏洞最大的特點在於它可在身份驗證之前被利用。通常情況下，存取資料庫需要進行身份驗證，但在 MongoBleed 漏洞中，壓縮訊息的解壓縮過程在身份驗證檢查之前執行，因此攻擊者無需任何憑證即可發動攻擊。
問題的根源在於 MongoDB 用於網路通訊的 zlib 壓縮方法。 zlib 壓縮率很高，但同時也會為 CPU 帶來沉重的負擔。 MongoDB 也支援其他壓縮方法，例如 snappy 和 zstd，建議切換到這些方法作為緩解措施。 Snappy 速度快且 CPU 佔用低，而 zstd 在壓縮率和速度之間取得了良好的平衡。
尤其令人擔憂的是，不會為舊版的 MongoDB（包括 4.2、4.0 和 3.6）提供任何修復程序，迫使使用這些版本的組織要么升級，要么禁用 zlib 壓縮。
Wiz 的調查發現，42% 的雲端環境受到影響，凸顯了 MongoDB 在現代基礎架構中的普及程度。其廣泛應用，尤其是在微服務架構和容器環境中，要求企業能夠跨多個執行個體進行可見性管理。
該漏洞利用代碼於2025年12月26日公開，僅僅幾天後就被證實已被實際利用，這凸顯了該漏洞的危險性以及攻擊者的迅速反應。 MongoBleed Detector等工具的快速發布也反映了安全社群的高度緊迫感。
[術語]
MongoBleed
這是在 MongoDB 伺服器中發現的 CVE-2025-14847 的別名。它之所以得名，是因為它與 2014 年的 Heartbleed 漏洞在技術上非常相似。基於 zlib 的網路訊息解壓縮過程中對長度欄位的驗證不足，導致在身份驗證之前未初始化的堆記憶體區域洩漏。
心臟出血
2014年，OpenSSL被發現有一個嚴重漏洞（CVE-2014-0160）。此漏洞允許攻擊者讀取伺服器記憶體的內容，原因是TLS/SSL協定心跳擴充中的長度參數驗證不當。它影響全球各地的Web伺服器，被認為是安全史上最嚴重的漏洞之一。
CVE
CVE是通用漏洞揭露（Common Vulnerabilities and Exposures）的縮寫。它是分配給已公開披露的安全漏洞的唯一識別編號。 CVE編號由非營利組織MITRE管理，使世界各地的安全專家能夠分享有關相同漏洞的資訊。
zlib
這是一個資料壓縮庫。它實作了 deflate 壓縮演算法，壓縮率很高，但對 CPU 的佔用也很大。 MongoDB 使用它來提高網路通訊效率。
堆記憶體<br>這是程式動態分配記憶體的區域。與堆疊記憶體不同，堆記憶體由程式設計師明確管理。未初始化的堆記憶體可能包含先前使用的資料片段，如果這些資料洩露，可能會暴露敏感資訊。
snappy/zstd
MongoDB 支援另一種壓縮方法。 Snappy 是 Google 開發的高速壓縮函式庫，它優先考慮速度而非壓縮比。 Zstd 是 Facebook 開發的壓縮演算法，它在壓縮比和速度之間取得了很好的平衡。與 zlib 相比，這兩種方法的 CPU 佔用率都較低。
微服務架構<br>一種將應用程式劃分為小型、獨立服務的設計方法。每個服務通常都有自己的資料庫，因此通常選擇像 MongoDB 這樣靈活的資料庫。越來越多的組織正在運行多個 MongoDB 實例。
[參考連結]
MongoDB 官方網站（外部連結）
一個典型的NoSQL資料庫。它以靈活的模式設計和可擴展性為特點，並廣泛應用於微服務架構中。
Censys （外部）
掃描網路上可公開存取的設備，以視覺化安全風險，有助於確定 MongoBleed 的影響範圍。
Wiz （外部）
雲端安全平台顯示，42% 的雲端環境託管著存在漏洞的 MongoDB 實例。
[參考文章]
MongoBleed：MongoDB Zlib 漏洞 (CVE-2025-14847) – Aikido （外部）
本書對 MongoBleed 進行了詳細的技術解釋，包括實作問題、攻擊原理以及如何切換到 snappy 或 zstd 作為緩解措施。
MongoDB 新漏洞允許未經身份驗證的攻擊者讀取敏感資料 – Hacker News （外部連結）
本文強調，MongoBleed 漏洞可以在驗證之前被利用，並且還探討了其對其他軟體（如 rsync）的影響以及檢測工具的開發。
CVE-2025-14847：MongoDB 記憶體洩漏警報 – Orca Security （外部）
本文解釋了 Orca Security 如何發現並報告 MongoBleed 漏洞，並詳細分析了堆疊記憶體洩漏機制及其與 Heartbleed 漏洞的相似之處。
[編者註]
在看到MongoBleed漏洞的新聞後，許多人可能開始擔憂公司係統的安全性。資料庫是我們通常不會特別關注的基礎設施，但像這樣在身份驗證之前就能被利用的漏洞，即使是最嚴格的存取管理措施也會形同虛設。
貴組織是否清楚其正在使用的 MongoDB 版本和壓縮方法？尤其是在微服務環境中，多個實例往往分散部署，因此藉此機會進行盤點有助於預防未來可能出現的重大風險。我認為安全並非僅靠個人就能完成，整個組織都應具備這種意識。
