CVE-2025-14847: Lỗ hổng memory leak nghiêm trọng nhất của MongoDB trong nhiều năm

Tổng quan

Trong nhiều năm trờ lại đây, MongoDB thường được xem là một hệ quản trị cơ sở dữ liệu “an toàn theo mặc định” nếu chúng được cấu hình đúng. Tuy nhiên vào cuối năm 2025 vừa rồi một lỗ hổng nghiêm trọng đã được phát hiện và phá bỏ đi giả định bên trên. MongoBleed (CVE-2025-14847) đã được phát hiện một cách tình cờ và cho phép kẻ tấn công từ xa đọc trực tiếp dữ liệu trong bộ nhớ (heap) của MongoDB mà không cần bất kỳ hình thức xác thực nào, chỉ thông qua các gói tin mạng được chế tạo đặc biệt.

Điểm đáng lo ngại của MongoBleed không nằm ở sự phức tạp của khai thác, mà ở bản chất của dữ liệu bị rò rỉ. Không phải log, không phải metadata, mà là những gì MongoDB đang “nghĩ” tại thời điểm đó: thông tin xác thực, dữ liệu BSON chưa ghi ra đĩa, token phiên làm việc và các cấu trúc nội bộ khác. Điều này khiến MongoBleed thường được so sánh với Heartbleed, một trong những lỗ hổng gây chấn động nhất lịch sử bảo mật.

Ngay sau khi proof-of-concept được công bố, các chiến dịch quét và khai thác đã nhanh chóng xuất hiện trên Internet, nhắm vào hàng chục nghìn MongoDB instance đang mở cổng công khai. Vậy hãy cùng nhau tìm hiểu xem cơ chế hoạt động của lỗ hổng này, mức độ rủi ro nếu như bị khai thác và cách phòng trống sap cho hiệu quả đối với người dùng.

Theo như báo cáo của Censys, đã có hơn 87.000 trường hợp MongoDB bị ảnh hưởng bởi lỗ hổng lần này và phần lớn đều tập trung ở Mỹ.

Giới thiệu về MongoDB

MongoDB là một hệ quản trị cơ sở dữ liệu NoSQL hướng tài liệu (document-oriented database), được thiết kế để xử lý khối lượng dữ liệu lớn với hiệu năng cao và khả năng mở rộng linh hoạt. Thay vì sử dụng mô hình bảng – hàng truyền thống như các cơ sở dữ liệu quan hệ, MongoDB lưu trữ dữ liệu dưới dạng document BSON (Binary JSON), cho phép biểu diễn dữ liệu phức tạp, lồng nhau và thay đổi cấu trúc một cách linh hoạt.

Về mặt kiến trúc thì MongDB được thiết kế theo mô hình client–server, trong đó các ứng dụng (client) giao tiếp trực tiếp với mongod thông qua giao thức nhị phân riêng của MongoDB (MongoDB Wire Protocol), mặc định trên cổng 27017.

Từ góc độ bảo mật, MongoDB hỗ trợ nhiều cơ chế phòng vệ như xác thực người dùng, phân quyền theo vai trò (RBAC), mã hóa kết nối TLS, mã hóa dữ liệu lưu trữ và audit log. Tuy nhiên, trong thực tế, nhiều hệ thống MongoDB vẫn bị mở trực tiếp ra Internet, cấu hình sai hoặc chậm vá lỗi, khiến chúng trở thành mục tiêu hấp dẫn cho kẻ tấn công.

MongoDB sử dụng Wire Protocol để trao đổi message giữa client và server. Một message thường bao gồm:

• Header (opcode, requestId, responseTo).

• Payload (BSON documents, metadata).

• Các tùy chọn nén (compression).

Để tối ưu hiệu năng và giảm băng thông, MongoDB hỗ trợ Message Compression, trong đó phổ biến nhất là zlib. Khi compression được bật, dữ liệu nhận từ client sẽ được:

• Đọc vào buffer mạng.

• Giải nén trong bộ nhớ.

• Chuyển tiếp sang tầng xử lý truy vấn.

Nguyên nhân lỗ hổng

Như đã nói bên trên ở phần kiến trúc của MongoDB có một phần trong việc hỗ trợ Message Compression nhưng đây cũng chính là điểm yếu bảo mật dẫn đến lỗ hổng CVE-2025-14847. Tính năng này cho phép mọi client kể cả chưa được xác thực, đều có khả năng kích hoạt logic giải nén và cấp phát bộ nhớ. Từ đó dẫn đến một hệ quả:

• Một phần buffer chưa được khởi tạo (uninitialized heap memory) bị gửi ngược về client.

• Dữ liệu rò rỉ không phải do “đọc nhầm file”, mà do trả nhầm bộ nhớ RAM.

CVE-2025-14847 tồn tại không phải vì MongoDB thiếu bảo mật, mà vì một giả định sai ở tầng rất thấp:

• “Dữ liệu sau giải nén luôn an toàn để sử dụng.”

Mô tả lỗ hổng

• Mã định danh: CVE-2025-14847

• Điểm CVSS: 8.7

• Mức độ nguy hiểm: High

• Mô tả: Cho phép kẻ tấn công không cần xác thực có thể trích xuất dữ liệu nhạy cảm trực tiếp từ bộ nhớ máy chủ MongoDB từ xa.

Phiên bản ảnh hưởng

• 8.2.x < 8.2.3

• 8.0.x < 8.0.17

• 7.0.x < 7.0.28

• 6.0.x < 6.0.27

• 5.0.x < 5.0.32

• 4.4.x < 4.4.30

Dựng môi trường

Để cài đặt môi trường phục vụ chúng ta có thể cài trên cả Windows lẫn Ubuntu. Trong ví dụ này chúng ta sẽ dựng trên Windows 10 với một số yêu cầu tối thiểu như sau:

Truy cập MongDB Community để tải bản cài đặt: https://www.mongodb.com/try/download/community

Cấu hình MongDB as a Service

• C:\Program Files\MongoDB\Server\8.2\data\: Đường dẫn Data mặc định

• C:\Program Files\MongoDB\Server\8.2\log\: Log Directory

Thực hiện kết nối với MongDB

Phân tích lỗ hổng và Demo

Như đã đề cập trước đó ở phần nguyên nhân lỗ hổng và cơ chế hoạt động của MongoDB thì kẻ cấn tông sẽ lợi dụng tầng xử lý giao thức của MongoDB, cho phép client chưa xác thực gửi các request hợp lệ về mặt cú pháp nhưng được thiết kế đặc biệt để:

• Kích hoạt cấp phát bộ nhớ không được giải phóng.

• Làm tăng dần mức sử dụng RAM của tiến trình mongod.

• Dẫn tới cạn kiệt bộ nhớ (memory exhaustion) và từ chối dịch vụ.

Với giai đoạn đầu tiên kẻ tấn công sẽ thực hiện dò quét mạng nội bộ để tìm xem host nào đang mở port 27017 - đây cũng có thể coi là một trong điều kiện cần để thực hiện tiếp các giai đoạn phía sau.

Sau khi đã xác định được Port mở, kẻ tấn công tiếp tục thiết lập các kết nối ban đầu với viêc để MongoDB chấp nhận kết nối ở network layer và gửi một số request hợp lệ về mặt giao thức:

• Đúng cấu trúc MongoDB Wire Protocol.

• Không vi phạm schema ở mức parser.

Với việc các Request hợp lệ như trên mà MongoDB tiếp nhận và xử lý như request “bình thường”. Trong quá trình xử lý request thì MongoDB sẽ thực hiện:

• Cấp phát buffer / object trong bộ nhớ heap.

• Dùng để xử lý dữ liệu trung gian.

Sau khi xử lý các request MongoDB sẽ đến một giai đoạn có tên là (Memory Accumulation Phase). Tại đây MongoDB không còn xử lý truy vấn ở mức logic ứng dụng, mà đã bước sang vùng xử lý bộ nhớ nội bộ (heap management). Nó sẽ cấp phát bộ nhớ tạm để xử lý các thông điệp mạng hợp lệ. Do lỗi logic trong quá trình xử lý, một phần bộ nhớ không được thu hồi điều này dẫn đến việc mỗi vòng xử lý đều để lại “dư lượng” bộ nhớ - đây chính là memory leak.

Không chỉ dừng lại ở đây lỗ hổng này nếu được khai thác nó còn tác động một phần lên hệ thống.

Tác động ngắn hạn

• RAM tăng liên tục

• Latency tăng

• MongoDB phản hồi chậm

Tác động dài hạn

• OOM Killer (Linux)

• Service crash (Windows)

• Replica set:

  • Primary bị down

  • Trigger election

  • Gây mất ổn định cluster

Với môi trường production, đây là DoS cấp hạ tầng, không chỉ đơn thuần là lỗi ứng dụng.

Kết luận

Chiến dịch khai thác MongoBleed (CVE-2025-14847) cho thấy một thực tế đáng lo ngại: ngay cả những hệ quản trị cơ sở dữ liệu phổ biến, trưởng thành và được triển khai rộng rãi như MongoDB vẫn có thể trở thành điểm yếu nghiêm trọng khi tồn tại lỗi ở tầng xử lý bộ nhớ cốt lõi. Khác với các lỗ hổng truyền thống dựa vào xác thực hay phân quyền, MongoBleed cho phép kẻ tấn công không cần xác thực nhưng vẫn có khả năng làm cạn kiệt bộ nhớ máy chủ, dẫn tới từ chối dịch vụ, gián đoạn hệ thống và tiềm ẩn nguy cơ rò rỉ dữ liệu nhạy cảm.

Điểm nguy hiểm của lỗ hổng này nằm ở chỗ nó khai thác trực tiếp giao thức và cơ chế quản lý bộ nhớ nội bộ, bỏ qua hoàn toàn các lớp bảo vệ thông thường như tài khoản người dùng, mật khẩu hay role-based access control. Trong môi trường thực tế, nơi nhiều MongoDB instance vẫn bị phơi bày ra Internet hoặc vận hành với cấu hình mặc định, MongoBleed có thể trở thành một công cụ tấn công hiệu quả cho cả kịch bản phá hoại (DoS) lẫn hoạt động trinh sát và chuẩn bị xâm nhập sâu hơn.

Cuối cùng, MongoBleed không chỉ là một lỗ hổng đơn lẻ, mà còn phản ánh xu hướng tấn công ngày càng tập trung vào các thành phần hạ tầng nền tảng. Đối với các đội ngũ an ninh, việc hiểu rõ cơ chế hoạt động nội tại của hệ thống — từ giao thức, bộ nhớ cho tới cách triển khai thực tế - chính là chìa khóa để phát hiện sớm, ứng phó hiệu quả và ngăn chặn các chiến dịch tấn công tương tự trong tương lai.

Khuyến nghị

1. Vá lỗi và nâng cấp phiên bản (Ưu tiên cao nhất)

   • Nâng cấp MongoDB lên phiên bản đã được khắc phục CVE-2025-14847 theo khuyến nghị chính thức của MongoDB.

   • Release Notes - Database Manual - MongoDB Docs

2. Không phơi bày MongoDB trực tiếp ra Internet

   • Tuyệt đối không expose port 27017 ra Internet công cộng.

   • Chỉ cho phép truy cập MongoDB thông qua:

     • Mạng nội bộ (LAN/VPC)

     • VPN

     • Bastion host

   • Sử dụng firewall hoặc security group để giới hạn IP nguồn được phép kết nối.

3. Giám sát tài nguyên bộ nhớ và hành vi bất thường

   • Thiết lập cảnh báo khi:

     • Memory usage tăng bất thường

     • MongoDB process sử dụng RAM liên tục nhưng không giảm

   • Theo dõi các chỉ số:

     • Resident Memory

     • WiredTiger cache usage

     • Số lượng connection và request bất thường

   • Trong môi trường SOC, cần xây dựng baseline hành vi bình thường để phát hiện sớm các dấu hiệu tương tự MongoBleed.

4. Giới hạn tài nguyên để giảm tác động tấn công

   • Áp dụng resource limits:

     • Giới hạn RAM cho MongoDB (đặc biệt trong container hoặc VM)

     • Giới hạn số lượng connection đồng thời

   • Với môi trường cloud hoặc container:

     • Sử dụng cgroups / container memory limit

     • Tránh để MongoDB chiếm toàn bộ RAM hệ thống khi bị tấn công

Mapping MongoBleed sang MITRE ATT&CK & D3FEND

Giai đoạn 1 – Reconnaissance (Target Discovery)

• T1046 – Network Service Discovery

  • Kẻ tấn công quét mạng để tìm MongoDB mở port 27017

Giai đoạn 2 – Initial Access (Service Interaction)

• T1190 – Exploit Public-Facing Application

  • MongoDB được xem là public-facing service

  • Giao thức MongoDB bị lợi dụng trước auth

Giai đoạn 3 – Execution (Abuse of Server-Side Processing)

• T1059 (Conceptual) – Command Execution (logic-level, không OS command)

• T1106 – Native API Abuse (áp dụng khái niệm)

Giai đoạn 4 – Impact (Primary Objective)

• T1499.003 – Endpoint Denial of Service: Resource Exhaustion

  • Exhaust RAM thông qua memory leak

Tham khảo

1. MongoBleed CVE-2025-14847 exploited in the wild | Tenable®

2. GitHub - joe-desimone/mongobleed

3. MongoBleed (CVE-2025-14847): Risk, Detection & How Varonis Protects You