# MongoBleed 취약점에 대한 간단 설명 > Clean Markdown view of GeekNews topic #25422. Use the original source for factual precision when an external source URL is present. ## Metadata - GeekNews HTML: [https://news.hada.io/topic?id=25422](https://news.hada.io/topic?id=25422) - GeekNews Markdown: [https://news.hada.io/topic/25422.md](https://news.hada.io/topic/25422.md) - Type: GN+ - Author: [neo](https://news.hada.io/@neo) - Published: 2025-12-30T06:34:36+09:00 - Updated: 2025-12-30T06:34:36+09:00 - Original source: [bigdata.2minutestreaming.com](https://bigdata.2minutestreaming.com/p/mongobleed-explained-simply) - Points: 2 - Comments: 1 ## Topic Body - **MongoBleed(CVE-2025-14847)** 은 2017년 이후 모든 **MongoDB 버전**에 존재한 심각한 메모리 누출 취약점으로, 공격자가 데이터베이스의 **힙 메모리 임의 데이터**를 읽을 수 있음 - 취약점은 **zlib 압축 경로의 버그**로 인해 발생하며, 인증 없이 단순히 데이터베이스에 연결만 해도 악용 가능 - 공격자는 **조작된 압축 요청**을 보내 서버가 잘못된 크기의 버퍼를 할당하도록 유도하고, 그 안의 **이전 작업 메모리(비밀번호, API 키 등)** 를 노출시킬 수 있음 - MongoDB는 2025년 12월 19일 패치를 배포했으나, **EOL 버전(3.6, 4.0, 4.2)** 은 수정되지 않음 - 8년간 존재한 이 취약점은 **인터넷에 노출된 21만 개 이상 MongoDB 인스턴스**에 영향을 주며, 클라우드·온프레미스 환경 모두에서 **즉각적 패치 또는 압축 비활성화**가 필요함 --- ### MongoBleed 개요 - **MongoBleed(CVE-2025-14847)** 은 MongoDB의 **zlib 1 메시지 압축 경로**에서 발견된 취약점으로, 2017년 이후 모든 버전에 영향을 미침 - 공격자는 인증 없이 데이터베이스에 연결만 하면 **임의의 힙 메모리 데이터**를 읽을 수 있음 - MongoDB 3.6, 4.0, 4.2 등 **지원 종료(EOL)** 버전은 수정되지 않음 - 이 버그는 2017년 5월의 PR에서 도입되었으며, **2025년 12월 19일** 공식적으로 공개됨 - MongoDB는 **Atlas 클라우드 서비스**를 포함한 모든 인스턴스에 패치를 적용했다고 발표 ### MongoDB 통신 구조 - MongoDB는 **HTTP 대신 자체 TCP 프로토콜**을 사용하며, 메시지는 **BSON(Binary JSON)** 형식으로 전송됨 - 모든 요청은 **OP_MSG** 명령으로 구성되며, 압축 시 **OP_COMPRESSED** 메시지로 감싸짐 - 메시지에는 `uncompressedSize`, `originalOpcode`, `compressorId` 등의 필드가 포함됨 - `uncompressedSize`는 압축 해제 후의 예상 크기를 나타냄 ### 익스플로잇 단계 1 — 잘못된 버퍼 할당 - 공격자는 `uncompressedSize` 값을 실제보다 **과도하게 큰 값**으로 설정해 서버가 큰 버퍼를 할당하도록 만듦 - 예: 실제 1KB 메시지를 1MB로 선언 - MongoDB 서버는 압축 해제 후 **실제 크기를 검증하지 않고** 사용자가 지정한 크기를 신뢰함 - 결과적으로 메모리에는 `[실제 데이터 | 미참조 힙 쓰레기]` 형태의 구조가 남음 - C++ 기반 MongoDB는 메모리 초기화를 수행하지 않기 때문에, 이 영역에는 **이전 작업의 민감 데이터**가 포함될 수 있음 - 예: 비밀번호, 세션 토큰, API 키, 고객 데이터, 시스템 설정 등 ### 익스플로잇 단계 2 — 데이터 유출 - 공격자는 **잘못된 BSON 입력**을 전송해 서버가 메모리의 쓰레기 데이터를 문자열로 파싱하도록 유도 - BSON의 첫 필드는 문자열이며, C 언어의 **널 종료 문자열(null-terminated string)** 규칙을 따름 - 공격자가 **널 종료 문자가 없는 문자열**을 보내면, 서버는 메모리 내 다른 데이터까지 읽어들임 - 예시: `[ { "a | password: 123\0 | apiKey: jA2sa | ip: 219.117.127.202 ]` - 서버는 이를 잘못된 BSON 필드로 인식하고 오류 메시지에 해당 내용을 포함해 응답 - `"errmsg": "invalid BSON field name 'a | password: 123'"` - 이 과정을 반복하면 공격자는 **힙 메모리 전체를 스캔**하며 민감 정보를 수집 가능 ### 영향 및 위험성 - **인증 전(pre-auth) 단계**에서 발생하므로, 공격자는 로그인 없이 데이터에 접근 가능 - **인터넷에 노출된 MongoDB 인스턴스**는 즉시 위험에 노출됨 - Shodan 검색 기준 **213,000개 이상**의 MongoDB 인스턴스가 공개 상태 - **2017년부터 2025년까지 약 8년간** 존재한 취약점으로, 단순한 구조 탓에 실제 악용 가능성이 높음 - MongoDB는 “현재까지 악용 증거는 없다”고 밝혔으나, **공식 사과나 상세 타임라인은 공개하지 않음** ### 완화 방법 - **최신 패치 버전(8.0.17 이상)** 으로 업데이트 - 단기적으로는 **zlib 네트워크 압축 비활성화**로도 완화 가능 - MongoDB Atlas 사용자는 이미 패치 적용 완료 ### 추가 정보 및 관련 논의 - Elastic 보안팀 리드가 **‘MongoBleed’** 라는 이름을 붙이고 **PoC(Python 스크립트)** 를 공개 - MongoDB와 Elastic은 **검색 및 분석 기능** 영역에서 경쟁 관계 - 관련 리소스: - CVE 공식 페이지: [CVE-2025-14847](https://nvd.nist.gov/vuln/detail/CVE-2025-14847) - 버그 도입 PR: [GitHub PR #1152](https://github.com/mongodb/mongo/pull/1152) - 수정 커밋: [505b660a14698bd2b5233bd94da3917b585c5728](https://github.com/mongodb/mongo/commit/505b660a14698bd2b5233bd94da3917b585c5728) - 탐지 도구: [mongobleed-detector](https://github.com/Neo23x0/mongobleed-detector) ### 요약 - MongoBleed는 **zlib 압축 처리 버그**로 인해 발생한 **메모리 누출 취약점** - 공격자는 **조작된 압축 요청**을 통해 **이전 메모리 데이터(비밀번호, API 키 등)** 를 획득 가능 - **2017~2025년 모든 MongoDB 버전**이 영향받으며, **패치 또는 압축 비활성화**가 필수 - **인터넷 노출 인스턴스 21만 개 이상**이 잠재적 피해 대상 - MongoDB는 패치를 배포했으나, **EOL 버전 미지원 및 공개 대응 지연**이 지적됨 ## Comments ### Comment 48421 - Author: neo - Created: 2025-12-30T06:34:36+09:00 - Points: 1 ###### [Hacker News 의견들](https://news.ycombinator.com/item?id=46414475) - 몇 년 전 나는 Cloudflare Workers 런타임의 **메모리 할당기(memory allocator)** 를 수정해, 해제 시 모든 메모리를 고정된 바이트 패턴으로 덮어쓰도록 했음 덕분에 초기화되지 않은 메모리에는 의미 있는 데이터가 남지 않게 되었음 성능 저하를 예상했지만 실제로는 **측정 가능한 영향이 전혀 없었음** 메모리 안전하지 않은 언어를 쓰는 사람이라면 모두 이렇게 해야 한다고 생각함. 이번 Mongo 버그도 이런 방식으로 완화할 수 있었을 것임 - 최신 macOS는 메모리 해제 시 자동으로 **zero-out**을 수행함 이 덕분에 메모리 압축 효율이 높아지고, 평균적으로는 오히려 성능이 향상된다고 함 - FreeBSD에서는 `MALLOC_CONF=opt.junk=free` 환경 변수를 설정하면 malloc이 같은 동작을 수행함 즉, 이미 많은 구현체가 이런 기능을 옵션으로 제공하고 있음 - 2025년에는 **모든 일반 할당기**가 기본적으로 메모리를 0으로 초기화해야 한다고 생각함 성능이 더 필요하면 특정 용도에 맞게 커스텀 할당기를 작성하면 됨 시스템 할당기에서는 불가능한 다른 최적화도 가능해질 것임 - OpenBSD는 새로 할당된 메모리를 `0xdb`, 해제된 메모리를 `0xdf`로 채움 덕분에 **use-before-initialization**이나 **use-after-free** 버그를 빠르게 잡을 수 있음 이게 기본 설정으로 되어 있음 - 혹시 이게 커널의 `init_on_free=1` 옵션을 켜는 것과 같은 동작인지 궁금함 - 글쓴이가 Mongo의 내부 개발 프로세스를 잘 몰랐던 것 같음 Mongo는 내부 **비공개 저장소**에서 개발 후, [Copybara](https://github.com/google/copybara)를 통해 공개 저장소로 커밋을 옮김 날짜 혼란은 이 과정에서 생긴 것임 - 나도 몰랐음. PR 리뷰가 없다는 점이 이상하다고 생각했는데 이제 이해됨 글을 업데이트해서 이 사실과 날짜 차이를 설명할 예정임 - 글쓴이가 타임라인을 잘못 이해한 듯함 우리 **Atlas 클러스터**는 CVE가 발표되기 며칠 전에 이미 업그레이드가 완료되었음 - 고마움. 글을 업데이트했음 - 데이터베이스 같은 시스템에서는 메모리 해제 시 **zeroing 또는 poisoning**을 하는 게 좋은 선택임 요즘은 대부분의 할당기가 기본적으로 그렇게 해야 함 Blink에서 Chris가 이 부분을 개선했고, 그 결과가 Chromium 전체로 확산되었음 관련 문서도 흥미로움 [Chromium 블로그 글](https://blog.chromium.org/2021/04/efficient-and-safe-allocations-everywhere.html) [PartitionAlloc 문서](https://chromium.googlesource.com/chromium/src/+/master/base/allocator/partition_allocator/PartitionAlloc.md) - Mongo 인스턴스가 인터넷에 얼마나 자주 노출되는지 궁금함 SQL 쪽에서는 드물지만 가끔 있긴 함 - 내 경험상 MongoDB의 존재 이유는 **“게으름”** 임 스키마, 내구성, 읽기/쓰기, 연결성 등 아무것도 신경 쓰지 않아도 된다는 철학임 그래서 보안도 신경 쓰지 않는 게 놀랍지 않음 - 내가 아는 “진지한” 조직 3곳 모두 Mongo를 쓰는 이유가 스키마 설계를 피하기 위해서였음 이런 태도는 “지금 당장 편하자”는 생각으로 이어지고, 결국 **공개 DB 인스턴스** 같은 보안 문제로 연결됨 - 이런 의견들 너무 극단적인 것 같음 실제로는 **SQL과 NoSQL을 함께** 사용하는 게 일반적임 NoSQL은 대규모 데이터의 고가용성에 강점이 있고, SQL은 관계형 데이터 저장에 적합함 예를 들어 iMessage나 EA의 매치메이킹 시스템도 NoSQL을 사용함 결국 둘 다 필요함. 경쟁 관계가 아니라 **보완 관계**임 - [Shodan 검색 결과](https://www.shodan.io/search?query=Product%3A%22MongoDB%22)에 따르면 21만 3천 개의 Mongo 인스턴스가 노출되어 있음 - SQL 서버를 노출하면 더 심각한 결과가 생김 예를 들어 PostgreSQL은 기본 설정만으로도 시스템 전체 권한을 가질 수 있음 그래서 대부분의 사람들은 공개 SQL 서버의 위험성을 잘 알고 있음 - MongoDB가 12월 24일에 “CVE 악용 증거가 없다”고 발표했는데, **“증거가 없다는 건 존재하지 않는다는 증거가 아니다”** 라는 점을 잊지 말아야 함 - 그렇다면 그들이 뭐라고 말했어야 한다고 생각함? - 왜 아직도 Mongo를 쓰는지 이해가 안 됨 - **복제(replication)** 가 쉽고, Postgres의 JSONB보다 빠름 개인적으로는 쓰고 싶지 않지만, **DynamoDB나 MongoDB**가 기술적으로 적합한 경우도 있음 - “web scale”이라서 쓴다는 농담도 있음 [관련 영상](https://www.youtube.com/watch?v=b2F-DItXtZs) - 예전에는 NoSQL이 유행이었지만, 결국 단순한 **key-value DB**로 귀결되었음 - 이건 너무 공격적인 논리라 받아들이기 어려움 - OWASP Top 10이 주요 취약점을 해결할 거라는 **낙관론**을 떠올리게 됨 하지만 버퍼 오버플로우는 2003년부터 여전히 존재함 - 결국 **footgun**을 모두에게 쥐여준 셈임 이런 문제는 언어 차원에서 막지 않는 한 영원히 반복될 것임 Mongo 개발자들에게 위로를 보냄 - NoSQL 관련 글이 올라올 때마다, 많은 “개발자들”이 **대규모 트래픽을 다뤄본 적이 없다는 사실**이 드러남 - 이번엔 그냥 너 혼자 그런 것 같음 - MongoDB는 항상 별로였음… 하지만 “webscale”이라 불림 차라리 **ToroDB**나 PostgreSQL의 **JSONB**를 쓰는 게 낫다고 생각함