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:
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
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:
| Thành phần | Khuyến nghị |
| OS | Windows 10 x64 |
| RAM | ≥ 4 GB |
| Disk | ≥ 5 GB trống |
| Quyền | Administrator |
| Tool | PowerShell / CMD |
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
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:
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:
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ị
Vá lỗi và nâng cấp phiên bản (Ưu tiên cao nhất)
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.
Giám sát tài nguyên bộ nhớ và hành vi bất thường
Giới hạn tài nguyên để giảm tác động tấn công
Mapping MongoBleed sang MITRE ATT&CK & D3FEND
Giai đoạn 1 – Reconnaissance (Target Discovery)
Giai đoạn 2 – Initial Access (Service Interaction)
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)
Tham khảo
MongoBleed CVE-2025-14847 exploited in the wild | Tenable®
GitHub - joe-desimone/mongobleed
MongoBleed (CVE-2025-14847): Risk, Detection & How Varonis Protects You
