MongoBleed 긴급 대응과 데이터베이스 패치 거버넌스 설계

MongoBleed가 드러낸 데이터베이스 운영의 빈틈

2025년 12월 MongoDB의 전체 메이저 라인에 영향을 주는 사전 인증 메모리 노출 취약점 MongoBleed(CVE-2025-14847)가 공개됐다. MongoDB는 8.2.3, 8.0.17, 7.0.28, 6.0.27, 5.0.32, 4.4.30을 동시에 릴리스해 대응했다.

같은 시기 PostgreSQL 13은 2025년 11월 공식 EOL(End of Life)에 진입하며 보안 패치 지원이 끝났다. 이 두 변화는 단순한 버전 업데이트 문제가 아니다. 서로 다른 버전을 동시에 운영하는 환경의 긴급 패치 체계, NoSQL 공격 면의 방어, 오픈소스 RDBMS의 수명 주기 관리가 한 흐름으로 연결돼야 한다는 점을 보여준다.

OP_COMPRESSED의 zlib 처리 경로에서 발생한 메모리 노출

CVE-2025-14847의 CVSS 점수는 8.7(Critical)이다. 문제 지점은 MongoDB 와이어 프로토콜의 OP_COMPRESSED 메시지 처리다. MongoDB는 네트워크 대역폭 절감을 위해 snappy, zlib, zstd 압축 알고리즘을 지원하며, 취약점은 zlib 경로의 uncompressedSize 필드 검증 결함에서 비롯됐다.

공격자는 압축 헤더의 uncompressedSize를 실제 페이로드보다 크게 조작해 보낼 수 있다. 서버는 이 값만큼 힙 버퍼를 할당하고 압축 해제를 수행하지만, 실제 해제 데이터 길이가 아니라 할당된 버퍼 크기를 반환한다. 초기화되지 않은 힙 메모리가 응답에 섞여 클라이언트로 전달되는 구조다. 인증 이전(pre-authentication)에 처리되므로 자격 증명 없이 악용될 수 있다.

⤢✕

노출 대상에는 힙에 남은 평문 자격 증명, API 키, AWS 세션 토큰, PII 등이 포함될 수 있다. 2025년 12월 26일 공개 PoC가 등장했고, CISA는 12월 29일 KEV(Known Exploited Vulnerabilities) 목록에 등재해 연방 기관에 2026년 1월 19일까지 패치를 적용하도록 의무화했다. 인터넷에 노출된 취약 인스턴스는 약 146,000개로 추정된다.

메이저 라인	취약 범위	패치 버전
8.2.x	8.2.0 ~ 8.2.2	8.2.3
8.0.x	8.0.0 ~ 8.0.16	8.0.17
7.0.x	7.0.0 ~ 7.0.27	7.0.28
6.0.x	6.0.0 ~ 6.0.26	6.0.27
5.0.x	5.0.0 ~ 5.0.31	5.0.32
4.4.x	4.4.0 ~ 4.4.29	4.4.30
4.2, 4.0, 3.6	전 버전	패치 없음 (EOL)

즉시 패치할 수 없다면 mongod 또는 mongos 시작 시 --setParameter networkMessageCompressors=snappy,zstd를 지정해 zlib만 비활성화하는 단기 완화책을 적용할 수 있다.

인증 이전 경로부터 BSON과 프로토콜까지 보는 취약점 분류

MongoDB 보안 공시에서 다뤄지는 취약점은 발생 레이어에 따라 구분해 보는 편이 대응 우선순위를 잡기 쉽다.

인증 우회(Authentication Bypass)는 인증 체계가 시작되기 전의 연결 협상이나 압축 처리에서 발생한다. MongoBleed처럼 메모리가 노출되는 경우와 SCRAM 핸드셰이크의 타이밍 오라클을 이용한 사용자 열거가 여기에 속한다. 자격 증명 없이 서버 내부 상태에 닿을 수 있어 영향이 크다.

BSON 파싱 오류(BSON Parsing Error)는 MongoDB의 내부 직렬화 포맷인 BSON을 역직렬화하는 과정에서 발생한다. 타입 태그 혼동(type confusion), 중첩 도큐먼트 처리 시 재귀 깊이 제한 미흡, 배열 길이 필드의 정수 오버플로 등이 해당한다. 특수하게 만든 BSON 페이로드는 서버 크래시(DoS) 또는 임의 코드 실행으로 이어질 수 있다.

와이어 프로토콜 처리 결함(Wire Protocol Flaw)은 MongoBleed가 포함되는 범주다. OP_COMPRESSED, OP_MSG, OP_QUERY의 처리 경로에서 길이 필드 검증 누락, 버퍼 경계 초과 읽기, 정수 언더플로 또는 오버플로가 발생할 수 있다. 이 레이어는 인증 전에 처리되므로 노출 범위가 넓다.

NoSQL 쿼리 구조를 공격 면으로 취급하기

NoSQL 데이터베이스는 관계형 데이터베이스와 다른 방식으로 공격 면을 만든다. 특히 스키마리스 설계와 동적 쿼리 구성은 입력 구조 자체가 변조되는 문제로 이어질 수 있다.

MongoDB 쿼리는 JSON 오브젝트로 작성되므로 $ne, $gt, $regex, $where 같은 쿼리 연산자를 이용한 인젝션이 가능하다. $where는 서버사이드 JavaScript 실행을 허용하므로 특히 위험하다. SQL 인젝션과 달리 원시 쿼리 문자열이 아니라 오브젝트 구조를 조작하는 방식이어서 단순 이스케이핑만으로는 방어하기 어렵다.

방어는 입력 허용 목록(allowlist)에서 시작한다. 사용자 입력의 $로 시작하는 키와 MongoDB 연산자 키워드를 제거하거나 거부한다. 파라미터화된 쿼리 또는 Mongoose 등의 ODM 라이브러리로 동적 쿼리 직접 구성을 피하고, 프로덕션 환경에서는 --noscripting으로 $where를 비활성화한다. MongoDB 포트 27017은 공인망에 직접 노출하지 않고 VPC 또는 방화벽 뒤에 두며, TLS 암호화와 X.509 클라이언트 인증서로 미들맨 공격을 차단한다.

버전별 영향도를 배포 순서로 연결하는 긴급 패치

MongoDB가 여섯 개 메이저 라인에 동시에 패치를 제공한 이유는 운영 환경이 하나의 버전으로 정렬돼 있지 않기 때문이다. 프로덕션, 스테이징, 레거시 서비스는 서로 다른 메이저 버전을 유지하는 경우가 많다. 따라서 CVE 공시를 받은 뒤에는 인벤토리와 영향 버전을 먼저 연결하고, 환경별 검증과 롤링 배포를 이어야 한다.

⤢✕

레플리카 셋에서는 SECONDARY 상태의 세컨더리 노드 하나를 확인한 뒤 mongod 서비스를 중지한다. 바이너리를 업데이트하고 재시작한 다음 rs.status()로 SECONDARY 복귀를 확인한다. 나머지 세컨더리에도 같은 작업을 적용하고, rs.stepDown()으로 프라이머리 양보를 유도한다. 구 프라이머리가 현재 세컨더리가 되면 업그레이드 후 재시작하고, rs.status()로 전체 멤버의 정상 상태를 검증한다.

이 순서는 다운타임 없이 패치를 적용하기 위한 방식이다. 샤드 클러스터에서는 mongos → config 서버 → 각 샤드 레플리카 셋 순서로 진행하며, 단계마다 sh.status()로 밸런서 상태를 확인한다.

패치를 재현 가능하게 만드는 자동화 파이프라인

수동 패치 프로세스는 인적 오류와 대응 지연을 만든다. 자동화 파이프라인은 CI/CD 오케스트레이터, 실행 레이어, 관측 레이어를 분리해 운영할 수 있다.

GitHub Actions, GitLab CI, Jenkins 같은 Pipeline Integrator는 빌드·승인·배포 사이클을 관리한다. dev는 자동, staging은 리뷰 필요, production은 수동 승인이라는 환경별 승인 게이트도 이 계층에 둔다.

Migration Runner는 Flyway, Liquibase 또는 자체 멱등성 스크립트로 패치를 실행한다. 적용 이력을 테이블에 남겨 중복 실행을 막고 롤백 트리거를 지원한다. 같은 스크립트를 두 번 실행해도 부작용이 없는 멱등성(idempotency)이 보장돼야 안전하게 재시도할 수 있다.

Observability Layer는 패치 실행 로그, 복제 지연 메트릭, 쿼리 성능 기준선(baseline) 비교를 통해 이상 징후를 찾는다. Prometheus + Grafana 또는 Datadog MongoDB Integration을 활용할 수 있다.

PostgreSQL 13 지원 종료 이후의 이전 경로

PostgreSQL 13의 공식 EOL은 2025년 11월 13일이었다. AWS RDS/Aurora에서는 2026년 2월 28일까지 표준 지원이 연장되지만, 그 이후에는 보안 패치 미지원, PostGIS 등의 익스텐션 지원 중단, 드라이버 호환성 문제가 가시화된다. 목표 버전으로는 PostgreSQL 16 또는 17이 권장된다.

항목	pg_upgrade	논리 복제(Logical Replication)
다운타임	수 시간(테이블 수에 비례)	수 분(컷오버 타이밍만)
복잡도	낮음	높음
롤백 난이도	낮음(`--link` 미사용 시)	낮음(구 서버 유지 가능)
적용 상황	유지보수 창이 허용될 때	무중단 필수 환경
PG17 슬롯 보존	지원(PG17 신기능)	기본 지원

논리 복제는 소스와 타깃을 병행 운영하며 컷오버 시점의 중단을 최소화하는 경로다.

⤢✕

소스 PG13의 postgresql.conf에서 wal_level = 'logical'을 설정하고 재시작한다. 이어 소스에서 CREATE PUBLICATION all_tables FOR ALL TABLES;를 실행하고, 타깃 PG16/17에서 CREATE SUBSCRIPTION src_sub CONNECTION '...' PUBLICATION all_tables;를 실행한다.

초기 스냅샷 동기화가 끝나면 CDC로 변경 사항을 지속 복제한다. 복제 지연이 1초 미만으로 안정되면 pg_reload_conf() 또는 ALTER DATABASE ... CONNECTION LIMIT 0으로 소스의 신규 연결을 차단한다. 마지막으로 타깃에서 ALTER SUBSCRIPTION ... DISABLE로 슬롯을 해제하고 애플리케이션 DSN을 타깃으로 전환한다.

PostgreSQL 17은 pg_upgrade 실행 시 논리 복제 슬롯을 유지하는 기능을 추가했다. 물리 복제로 스탠바이를 구성한 뒤 pg_upgrade를 수행하고 논리 복제로 컷오버하는 하이브리드 전략도 더 간결해졌다.

EOL 전에 움직이게 하는 데이터베이스 수명 주기 체계

MongoDB와 PostgreSQL은 수명 주기 정책을 공시하지만, 조직 안에서 이를 추적하고 대응하는 체계가 없으면 EOL 이후에 긴급 마이그레이션이 반복된다.

버전 인벤토리는 CMDB(Configuration Management Database), Terraform state, Kubernetes CRD 레이블을 통해 모든 데이터베이스 인스턴스의 버전을 자동 수집하는 방식으로 구성할 수 있다. endoflife.date API에서 EOL 날짜를 조회하고 대시보드에 표시한다.

EOL 경보는 EOL 12개월 전 계획 착수, 6개월 전 마이그레이션 착수, 3개월 전 긴급 에스컬레이션으로 나눠 Slack 또는 PagerDuty와 연동한다. 패치 SLA는 Critical(CVSS ≥ 9.0)을 48시간, High(7.0~8.9)를 7일, Medium 이하는 다음 정기 유지보수 창으로 표준화한다.

티어	설명	정책
Current	최신 메이저 버전	신규 기능 배포 가능
LTS	지정 LTS 버전	보안·버그픽스만 적용
Legacy	EOL 12개월 이내	마이그레이션 계획 의무화
EOL	지원 종료	신규 배포 금지

허용 버전 목록은 GitOps 방식으로 코드화하고, CI/CD 파이프라인에서 자동 검증해 비허용 버전의 배포를 차단한다. MongoBleed 같은 사전 인증 메모리 노출 취약점은 방화벽 뒤에서도 내부 공격자나 내부 네트워크 침투 이후 빠르게 악용될 수 있다. 멀티버전 패치와 롤링 업그레이드, PostgreSQL 13 EOL 대응, 수명 주기 거버넌스를 분리된 업무가 아니라 하나의 운영 체계로 다뤄야 한다.