Khẩn cấp: Lỗ hổng CVE-2025-14847 MongoDB rò rỉ dữ liệu nhạy cảm

Một lỗ hổng CVE-2025-14847 nghiêm trọng đã được phát hiện trong MongoDB Server, cho phép kẻ tấn công từ xa không cần xác thực thu thập dữ liệu nhạy cảm từ bộ nhớ cơ sở dữ liệu. Lỗ hổng này, được đặt tên là “MongoBleed” do có những điểm tương đồng về cơ chế tự động khai thác với lỗi Heartbleed khét tiếng, mang mã hiệu CVE-2025-14847 với điểm CVSS 7.5.

Phân tích kỹ thuật lỗ hổng CVE-2025-14847 (MongoBleed)

Lỗ hổng này nằm trong quá trình triển khai giải nén thông điệp zlib của MongoDB Server. Theo thông báo công khai vào ngày 19 tháng 12 năm 2025, đây là một vấn đề rò rỉ bộ nhớ chưa được khởi tạo (uninitialized memory disclosure issue).

Cơ chế hoạt động của MongoBleed

Khi một phiên bản MongoDB cố gắng giải nén một gói dữ liệu được chế tạo đặc biệt, một lỗi logic sẽ xảy ra. Lỗi này cho phép kẻ yêu cầu đọc các phần của bộ nhớ heap chưa được khởi tạo.

Nguy hiểm của MongoBleed nằm ở dữ liệu được lưu trữ trong vùng bộ nhớ bị lộ. Do heap là một vùng bộ nhớ động, nó thường chứa các tàn dư từ các hoạt động cơ sở dữ liệu trước đó.

Điều này có thể bao gồm dữ liệu đã được xử lý nhưng chưa được ghi đè hoặc xóa sạch một cách an toàn. Kẻ tấn công có thể lợi dụng điều này để đọc các thông tin lẽ ra phải được bảo mật.

Tác động và dữ liệu nhạy cảm có thể bị rò rỉ

Khai thác thành công lỗ hổng này cho phép kẻ tấn công “rút” (bleed) các dữ liệu từ bộ nhớ này. Điều này tiềm ẩn khả năng trích xuất các thông tin nhạy cảm như:

• Thông tin đăng nhập dạng văn bản gốc (cleartext credentials)
• Token phiên làm việc (session tokens)
• Khóa xác thực (authentication keys)
• Thông tin nhận dạng cá nhân của khách hàng (customer PII) đã được máy chủ xử lý gần đây

Điểm mấu chốt là cuộc khai thác này không yêu cầu kẻ tấn công phải được xác thực. Bất kỳ người dùng từ xa nào có quyền truy cập mạng vào cổng cơ sở dữ liệu đều có thể kích hoạt lỗ hổng CVE-2025-14847 này.

Rủi ro còn tăng lên do tính năng nén zlib được bật theo mặc định trong các cấu hình MongoDB tiêu chuẩn. Điều này tạo ra một bề mặt tấn công rộng lớn ngay lập tức sau khi lỗ hổng được công bố.

Quy mô ảnh hưởng và các phiên bản dễ bị tổn thương

Nền tảng quan sát internet Censys đã chỉ ra rằng mức độ tiếp xúc với lỗ hổng này là rất đáng kể. Tính đến cuối tháng 12, các truy vấn của Censys đã xác định được hơn 87.000 phiên bản MongoDB tiềm ẩn nguy cơ bị khai thác, đang được phơi bày ra internet công cộng.

Lỗ hổng MongoBleed ảnh hưởng đến một loạt các phiên bản MongoDB, từ các triển khai cũ đến các bản phát hành gần đây nhất. Mặc dù thông tin cụ thể về tất cả các phiên bản bị ảnh hưởng có thể thay đổi, quản trị viên nên tham khảo thông báo chính thức từ MongoDB để biết danh sách chi tiết và cập nhật nhất.

Tham khảo thêm về mức độ phơi nhiễm trên Censys tại: Censys Advisory: CVE-2025-14847

Tình trạng khai thác lỗ hổng và PoC công khai

Tại thời điểm viết bài, chưa có bằng chứng xác nhận về việc lỗ hổng CVE-2025-14847 này đang bị khai thác tích cực trên thực tế (in the wild). Tuy nhiên, thời gian để áp dụng các bản vá đang thu hẹp nhanh chóng.

Một mã khai thác Proof-of-Concept (PoC) đã được nhà nghiên cứu Joe Desimone công bố công khai trên GitHub. Sự sẵn có của mã khai thác công khai làm tăng đáng kể khả năng các tác nhân đe dọa sẽ bắt đầu quét và thu thập dữ liệu từ các máy chủ chưa được vá.

Việc có PoC công khai làm cho lỗ hổng trở nên dễ bị khai thác hơn, kể cả bởi những kẻ tấn công có ít kinh nghiệm. Do đó, nguy cơ rò rỉ dữ liệu nhạy cảm tăng lên đáng kể.

Mã PoC có thể tìm thấy tại: GitHub – MongoBleed PoC Exploit

Các biện pháp khắc phục và cập nhật bản vá bảo mật

MongoDB đã phát hành các bản vá bảo mật để giải quyết CVE-2025-14847. Quản trị viên được khuyến nghị nâng cấp ngay lập tức lên các phiên bản sau hoặc cao hơn:

• MongoDB 6.0.x lên 6.0.12 hoặc cao hơn
• MongoDB 5.0.x lên 5.0.23 hoặc cao hơn
• MongoDB 4.4.x lên 4.4.29 hoặc cao hơn
• MongoDB 4.2.x lên 4.2.27 hoặc cao hơn

Việc áp dụng các bản vá này là bước quan trọng nhất để bảo vệ hệ thống khỏi các cuộc tấn công khai thác MongoBleed và ngăn chặn rò rỉ dữ liệu nhạy cảm.

Chiến lược giảm thiểu rủi ro tạm thời

Đối với các tổ chức chưa thể áp dụng các bản vá ngay lập tức, có một số chiến lược giảm thiểu tạm thời có thể được triển khai để giảm thiểu nguy cơ:

Vô hiệu hóa tính năng nén zlib

Quản trị viên có thể tắt tính năng nén zlib bằng cách sửa đổi cài đặt networkMessageCompressors hoặc net.compression.compressors để loại bỏ rõ ràng zlib. Điều này sẽ ngăn chặn lỗ hổng bị kích hoạt qua cơ chế giải nén bị lỗi.

Ví dụ cấu hình trong mongodb.conf:

# Tắt nén zlib bằng cách chỉ định các trình nén khác hoặc để trống# Để tắt hoàn toàn nén, hãy để trống hoặc chỉ định "none"# networkMessageCompressors: none# Hoặc chỉ định các trình nén khác mà không bao gồm zlib (ví dụ: snappy, zstd)networkMessageCompressors: snappy,zstd

Để đảm bảo thay đổi có hiệu lực, cần khởi động lại dịch vụ MongoDB sau khi sửa đổi cấu hình. Lưu ý rằng việc tắt tính năng nén có thể ảnh hưởng đến hiệu suất mạng tùy thuộc vào khối lượng dữ liệu.

Hạn chế quyền truy cập mạng

Hạn chế quyền truy cập mạng vào các địa chỉ IP đáng tin cậy là một biện pháp bảo mật cơ sở dữ liệu tiêu chuẩn và thiết yếu. Biện pháp này giúp ngăn chặn những kẻ tấn công từ xa tiếp cận các dịch vụ dễ bị tổn thương, đặc biệt là với lỗ hổng CVE-2025-14847 không yêu cầu xác thực.

Triển khai các quy tắc tường lửa (firewall rules) để chỉ cho phép các máy chủ và ứng dụng nội bộ được ủy quyền kết nối tới cổng MongoDB (mặc định là 27017).

Ví dụ cấu hình tường lửa (trên Linux với ufw):

# Cho phép truy cập từ một IP cụ thể (ví dụ: 192.168.1.100) đến cổng MongoDBsudo ufw allow from 192.168.1.100 to any port 27017# Từ chối tất cả các kết nối khác đến cổng MongoDBsudo ufw deny any to any port 27017# Kích hoạt ufw (nếu chưa kích hoạt)sudo ufw enable

Hoặc sử dụng iptables (lưu ý thứ tự các quy tắc rất quan trọng):

# Cho phép truy cập từ một IP cụ thểsudo iptables -A INPUT -p tcp --dport 27017 -s 192.168.1.100 -j ACCEPT# Từ chối tất cả các kết nối khác đến cổng MongoDBsudo iptables -A INPUT -p tcp --dport 27017 -j DROP# Lưu các quy tắc để chúng tồn tại sau khi khởi động lạisudo netfilter-persistent save

Việc kết hợp cả hai chiến lược giảm thiểu này sẽ cung cấp một lớp bảo vệ bổ sung trong khi chờ đợi việc triển khai các bản vá bảo mật chính thức và nâng cấp hệ thống.