Thông báo bảo mật MongoDB

 (mongodb.com)
2 điểm bởi GN⁺ 2023-12-18 | 1 bình luận | Chia sẻ qua WhatsApp
  • MongoDB Alerts là một trung tâm thông báo tập hợp các vấn đề về toàn vẹn dữ liệu, vận hành và bảo mật CVE ở một nơi, giúp kiểm tra phạm vi ảnh hưởng theo từng phiên bản và các bản triển khai MongoDB cần xử lý
  • Các mục về toàn vẹn dữ liệu năm 2026 bao gồm lỗi truy vấn phạm vi sắp xếp giảm dần theo _id trong clustered collection, việc unique index trong sharded cluster cho phép trùng lặp, thiếu sót trong Relational Migrator, và việc không áp dụng read/write concern khi kết nối trực tiếp tới shard
  • Về vận hành, đến tháng 4/2026, các CA công cộng lớn sẽ ngừng cấp chứng chỉ TLS có clientAuth EKU, nên cấu hình mTLS và xác thực X.509 của MongoDB tự quản lý có thể bị ảnh hưởng
  • Phần bảo mật cung cấp danh sách CVE theo từng sản phẩm cho MongoDB Server, Compass, mongosh, driver, Ops Manager, v.v. từ năm 2019 đến 2026
  • Người vận hành thực tế cần đối chiếu các phiên bản Server, Atlas, Relational Migrator, Compass, mongosh và driver theo ngôn ngữ đang dùng với phạm vi ảnh hưởng, rồi nâng cấp lên phiên bản vá hoặc áp dụng cấu hình workaround đã được công bố

Phạm vi được trang MongoDB Alerts đề cập

  • MongoDB Alerts là trang tập hợp các cảnh báo và khuyến nghị quan trọng của MongoDB
  • Danh sách đầy đủ các bug và yêu cầu tính năng có thể xem tại MongoDB JIRA
  • Thông báo mới cũng được cung cấp qua RSS Feed
  • Trang được chia thành các danh mục sau
    • Data Integrity Related
    • Operations Related
    • Security Related: Common Vulnerabilities and Exposures (CVEs)
    • General

Cảnh báo toàn vẹn dữ liệu năm 2026

  • Truy vấn phạm vi sắp xếp giảm dần theo _id trong clustered collection

    • Công bố ngày 17/6/2026
    • Trong clustered collection, nếu áp dụng sắp xếp giảm dần trên trường _id và dùng điều kiện phạm vi dạng {$lt: A}, {$gt: A}, {$gte: A, $lt: B}, {$gt: A, $lte: B}, tài liệu ở biên có thể bị đưa vào hoặc loại ra sai
    • Không ảnh hưởng đến time series collection, non-clustered collection, clustered collection không áp dụng sắp xếp giảm dần theo _id, và các tổ hợp toán tử so sánh có cùng kiểu bao gồm/loại trừ
    • Phiên bản bị ảnh hưởng:
      • MongoDB 8.0.0–8.0.23
      • 8.2.0–8.2.9
      • 8.3.0–8.3.2
    • SERVER-121822

  • Bảo đảm không trùng lặp của unique index trong sharded cluster

    • Công bố ngày 14/5/2026
    • Trong sharded cluster, nếu shard key giống với index key pattern hoặc là strict prefix, và unique index dùng non-simple collation, tính uniqueness có thể không được cưỡng chế giữa các shard
    • Các giá trị có byte khác nhau nhưng tương đương theo collation, như "YES" và "yes", có thể được nhập độc lập vào các shard khác nhau
    • Điều kiện xảy ra vấn đề là có từ hai shard trở lên, unique index dùng non-simple collation, và shard key giống với index key pattern hoặc là strict prefix
    • Phiên bản bị ảnh hưởng:
      • 5.0.0–5.0.32
      • 6.0.0–6.0.28
      • 7.0.0–7.0.31
      • 8.0.0–8.0.20
      • 8.2.0–8.2.6
    • SERVER-85346

  • Thiếu sót trong migration của Relational Migrator

    • Công bố ngày 14/5/2026
    • Người dùng di chuyển bằng Relational Migrator có thể gặp tình trạng thiếu tài liệu khi migration sharded cluster có embedded document hoặc embedded array
    • Cyclic mapping có foreign key bị loại trừ dưới embedded array, source table column được dùng trong nhiều quan hệ composite foreign key, và lựa chọn field name xung đột có thể tạo ra trường bị thiếu, không nhất quán hoặc đặt sai tên
    • Sản phẩm bị ảnh hưởng là MongoDB Relational Migrator trước 1.16.0
    • SERVER-126522

  • Không áp dụng read/write concern khi kết nối trực tiếp tới shard

    • Công bố ngày 14/5/2026
    • Nếu kết nối trực tiếp tới shard node mà không đi qua mongos, cluster-wide default read/write concern có thể không được áp dụng
    • Trong trường hợp này, write có thể được thực hiện với {w: 1} thay vì concern đã cấu hình, và nếu xảy ra rollback thì acknowledged write có thể bị mất
    • Với sharded cluster, chỉ nên kết nối thông qua mongos
    • Nếu cần kết nối trực tiếp tới shard, phải ngay lập tức nâng cấp lên phiên bản vá hoặc chỉ định read/write concern rõ ràng trong connection string, chẳng hạn {w: "majority"}
    • Phiên bản bị ảnh hưởng:
      • 5.0.0–5.0.32
      • 6.0.0–6.0.28
      • 7.0.0–7.0.31
      • 8.0.0–8.0.19
      • 8.2.0–8.2.3
    • SERVER-111031

Các mẫu lặp lại trong những cảnh báo toàn vẹn dữ liệu gần đây

  • Sharding và migration

    • Mục tháng 3/2026 đề cập nguy cơ mất dữ liệu trong quá trình chunk migration ở sharded collection có compound wildcard index bao gồm shard key prefix
    • Tháng 11/2025 ghi nhận vấn đề cross-shard transaction có thể bị commit một phần trong một số điều kiện failover nhất định
    • Tháng 4/2024 bao gồm vấn đề sharded multi-document transaction có thể trả về dữ liệu sai hoặc bỏ sót write

  • Time series collection

    • Mục tháng 11/2025 thông báo rằng 2dsphere index key cho metric data của time series collection không được tạo/chèn, khiến geospatial query có thể trả về kết quả không đầy đủ
    • Mục tháng 8/2025 đề cập vấn đề một số mẫu nhập metric kiểu double-precision có thể gây hỏng dữ liệu
    • Mục tháng 1/2025 bao gồm khả năng mất dữ liệu trong time series collection khi kết hợp insert đồng thời với ordered: false và retryable writes

  • Độ chính xác của kết quả truy vấn

    • Tháng 3/2026 ghi nhận vấn đề aggregation query trong đó $group ngay sau $sort dùng accumulator $top hoặc $bottom có thể trả về kết quả sai
    • Tháng 2/2026, trong SQL interface, khi một điều kiện OR trong mệnh đề WHERE là UNKNOWN và điều kiện còn lại là TRUE, có thể trả về kết quả sai
    • Tháng 6/2025, truy vấn có $elemMatch và string predicate có thể dùng index không khớp collation, làm bỏ sót các tài liệu lẽ ra phải được bao gồm

Cảnh báo liên quan đến vận hành

  • Thay đổi chính sách clientAuth EKU của CA công cộng

    • Công bố ngày 22/1/2026
    • Các Certificate Authority công cộng lớn áp dụng yêu cầu chính sách ngừng cấp chứng chỉ TLS có Extended Key Usage cho client authentication (clientAuth) trước tháng 4/2026
    • Thay đổi này chỉ ảnh hưởng đến các bản triển khai MongoDB tự quản lý dùng chứng chỉ public CA cho mutual TLS (mTLS) hoặc xác thực X.509
    • Khách hàng tự quản lý phải di chuyển sang private PKI infrastructure hoặc thay đổi cấu hình MongoDB trước hạn tháng 4–5/2026
    • Khách hàng Atlas không bị ảnh hưởng
    • Phạm vi ảnh hưởng:
      • X.509 Cluster Authentication
      • X.509 Client Authentication
      • mTLS dùng chứng chỉ public CA của Google Trust Services, Let’s Encrypt, DigiCert, Sectigo
    • Thông báo liên quan

  • mongosh và autocomplete của Node.js REPL

    • Công bố ngày 30/9/2025
    • Các bản phân phối bên thứ ba như MongoDB Shell được cài qua Homebrew hoặc npm package manager có thể bị ảnh hưởng bởi bug trong Node.js REPL
    • Side effect ngoài ý muốn có thể xảy ra trong quá trình autocomplete
    • Phạm vi ảnh hưởng là mongosh trước 2.5.8 khi dùng với Node.js 20.19.5–24.7.0
    • MONGOSH-2635

  • FIPS mode và OpenSSL 3

    • Công bố ngày 11/9/2025
    • Trên Linux, MongoDB cấu hình FIPS mode dùng OpenSSL 3 cho cryptographic operation có thể sử dụng cryptographic algorithm từ non-FIPS provider
    • Khi đó client có thể kết nối TLS tới MongoDB ở FIPS mode bằng non-FIPS-compliant cryptographic algorithm
    • Phiên bản bị ảnh hưởng:
      • 6.0.0–6.0.25
      • 7.0.0–7.0.22
      • 8.0.0–8.0.12
    • SERVER-109268

Thông báo bảo mật CVE năm 2026

  • Lỗ hổng MongoDB Server

    • CVE-2026-11933 ngày 12/6/2026 là lỗ hổng use-after-free sau xác thực trong chuyển đổi BSON-to-array của server-side JavaScript, điểm số 8.8
    • Phiên bản bị ảnh hưởng là 8.3.3 trở xuống, 8.2.10 trở xuống, 8.0.25 trở xuống, 7.0.36 trở xuống, 6.0.28 trở xuống, 5.0.33 trở xuống, 4.4.30 trở xuống
    • SERVER-128125

  • Denial of service trước xác thực

    • CVE-2026-9740 có thể gây stack overflow trước xác thực do unbounded recursion của BSONColumn interleaved-reference, điểm số 8.7
    • Phiên bản bị ảnh hưởng là trước 8.3.3, trước 8.2.10, trước 8.0.24, trước 7.0.35
    • SERVER-125063
    • CVE-2026-25611 là denial of service do cạn kiệt bộ nhớ trước xác thực, trong đó message chưa xác thực có thể làm cạn kiệt bộ nhớ, điểm số 8.7
    • Phiên bản bị ảnh hưởng là trước 8.2.4, trước 8.0.18, trước 7.0.29
    • SERVER-116210

  • Thông tin nhạy cảm bị ghi vào log

    • CVE-2026-9735 là vấn đề MongoDB Server có thể ghi authentication parameter và credential vào server log; phạm vi ảnh hưởng là MongoDB Server trước 8.3.3
    • SERVER-126506
    • CVE-2026-9751 là vấn đề thông tin nhạy cảm có thể bị ghi vào mongod.log khi parameter ldapQueryPassword được thiết lập bằng runtime setParameter command
    • Phiên bản bị ảnh hưởng là trước 8.3.3, trước 8.2.10, trước 8.0.24, trước 7.0.35
    • SERVER-123370

  • Server crash và vấn đề availability

    • CVE-2026-9754 là vấn đề trong command filemd5, trong đó authenticated user có read role có thể đọc một phần stack memory chưa được khởi tạo, điểm số 7.1
    • CVE-2026-9753 có thể gây server crash khi malformed binary diff được truyền vào $_internalApplyOplogUpdate
    • CVE-2026-9752 có thể khiến GeometryCollection có strict-winding polygon gây server crash trong quá trình sinh 2dsphere index key
    • CVE-2026-9749 có thể gây server crash khi dùng MaxKey()

  • Driver và công cụ

    • CVE-2026-9101 là prototype pollution trong CSV parsing của Compass; phiên bản bị ảnh hưởng là Compass từ 1.36.3 đến 1.49.5
    • CVE-2026-9100 là vấn đề heap memory out-of-bounds read và crash trong legacy GridFS file reader của C Driver
    • CVE-2026-6811 có thể gây application crash do stack exhaustion trong MongoDB PHP driver
    • CVE-2026-2303 cho phép application crash hoặc information leak do heap out-of-bounds read trong GSSAPI C wrapper của MongoDB Go Driver
    • CVE-2026-2302 là vấn đề unsafe reflection trong Mongoid::Criteria.from_hash của MongoDB Ruby Driver

  • RCE trong Ops Manager

    • CVE-2026-8431 là RCE thông qua webhook body của Ops Manager, điểm số 9.4
    • Nếu administrative user có thể thiết lập webhook, một số giá trị trong payload có thể được dùng để thực thi lệnh tùy ý
    • Phạm vi ảnh hưởng là Ops Manager 7.0 đến trước 8.0.23
    • Ops Manager release notes

Nhóm sản phẩm thường xuất hiện trong thông báo bảo mật từ năm 2025 trở đi

  • MongoDB Server

    • Các CVE liên quan đến server crash, denial of service, privilege escalation, certificate validation, malformed BSON, aggregation, query planner, sharding, time series được ghi nhận lặp lại
    • Phiên bản bị ảnh hưởng khác nhau theo từng thông báo, trải rộng trên các dòng MongoDB 5.0, 6.0, 7.0, 8.0, 8.1, 8.2, 8.3

  • Client và driver

    • C Driver, PHP Driver, Go Driver, Ruby Driver, Rust Driver, Node.js Driver, Java driver, .NET/C# Driver, PyMongo, libbson, js-bson, v.v. xuất hiện là sản phẩm bị ảnh hưởng
    • Một số mục đề cập vấn đề authentication-related data bị lộ qua command listener hoặc connection pool event listener

  • Công cụ vận hành

    • Compass, mongosh, MongoDB for VS Code, Atlas Kubernetes Operator, Enterprise Kubernetes Operator, Ops Manager, Cloud Manager, BI Connector, Atlas SQL ODBC driver, Database Tools được đưa vào nhóm sản phẩm bị ảnh hưởng
    • Bao gồm việc thiếu cấu hình ACL trong MSI cài đặt trên Windows, local privilege escalation, control character injection, thiếu kiểm tra đầu vào liên quan đến MITM, v.v.

Thông báo bảo mật chung

  • Phần General bao gồm các cập nhật về security incident được công bố lần đầu ngày 16/12/2023
  • Các mục ngày 28/12 và 29/12/2023 cho biết không tìm thấy bằng chứng về unauthorized access vào MongoDB Atlas cluster hoặc customer data được lưu trong Atlas cluster
  • Mục ngày 26/12/2023 thông báo rằng số lần login attempt tăng mạnh đang gây ra vấn đề đăng nhập cho khách hàng
  • Mục ngày 24/1/2024 thông báo việc MongoDB đăng post event summary
  • MongoDB Security Incident Post Event Summary

Bài viết liên quan

1 bình luận

 
GN⁺ 2023-12-18
Ý kiến trên Hacker News

  • Hiện tại tôi bị khóa hoàn toàn khỏi tài khoản Atlas và cổng hỗ trợ
    Tôi dùng xác thực Mongo và Okta, nhưng mọi lần thử đăng nhập đều thất bại ở màn hình đăng nhập với thông báo "The request contained invalid data."
    Vấn đề là cổng hỗ trợ cũng cần xác thực, nên để được trợ giúp về lỗi xác thực thì lại phải xác thực
    Không biết người khác có gặp vấn đề khi truy cập dashboard không
    Cập nhật: khoảng 5:15 chiều giờ miền Đông Mỹ, xác thực đã hoạt động trở lại và cũng truy cập được dashboard

    • Với tư cách nhân viên MongoDB, vấn đề đăng nhập không liên quan đến sự cố bảo mật
      Việc gửi thông báo đồng thời cho tất cả khách hàng và người dùng đã làm số lần thử đăng nhập tăng vọt
      Nếu vẫn gặp vấn đề đăng nhập, hãy thử lại sau vài phút
      Vui lòng tiếp tục kiểm tra trang thông báo: https://www.mongodb.com/alerts
    • Khi cố đăng nhập thì gặp lỗi upstream request timeout
    • Tôi cũng gặp tình trạng tương tự với Google SSO

  • Tôi thích thông báo này vì ngắn gọn và đi thẳng vào trọng tâm
    Nó nói rõ rằng sự việc vẫn ở giai đoạn đầu, phạm vi hiện được biết đến, và sẽ có các cập nhật tiếp theo khi có thêm thông tin
    Mong là mọi người đừng phản ứng như thể đang phạt MongoDB vì không đưa thêm thông tin trong khi cuộc điều tra rõ ràng vẫn ở giai đoạn rất sớm

    • Họ nói đến ngày 13 mới phát hiện, và cho rằng sự việc có thể đã diễn ra trong một thời gian
      Về cơ bản còn chưa chắc dữ liệu người dùng có bị đụng tới hay không, nhưng cảm giác như họ chưa cung cấp câu trả lời hoặc chỉ nói “không”, nên cần có câu trả lời rõ hơn
    • Đồng ý
      MongoDB nhận nhiều chỉ trích, nhưng trong phản ứng lần này phải lùi lại một bước mà công nhận về mặt trung thực, minh bạch và đáng tin cậy
      Tôi mong các công ty khác cũng làm theo cách này, và vì MongoDB đã trực tiếp thể hiện các nguyên tắc đó nên tôi càng sẵn lòng giao dịch với họ hơn

  • Có câu regularly rotate their MongoDB Atlas passwords; có ngữ cảnh nào tôi bỏ lỡ không?
    Hay các đội bảo mật hiện đại thực sự vẫn khuyến nghị đổi mật khẩu định kỳ?

    • Luân chuyển secret cho ứng dụng theo định kỳ là điều tốt
      Ép người dùng thường xuyên đổi mật khẩu thì không hay lắm

  • Nếu bị ảnh hưởng, tôi không biết nên giám sát hành vi bất thường trong hệ thống như thế nào
    Chỉ xem log thì có vẻ không đủ

  • Việc này cho thấy rủi ro của tập trung hóa cực đoan
    Ngay cả khi khách hàng Atlas không bị ảnh hưởng trực tiếp, việc lo lắng khi website hoặc kênh hỗ trợ bị quá tải sau thông báo là điều tự nhiên
    Trong những trường hợp như vậy, để có tính dự phòng thực sự thì cần nhiều nhà cung cấp MongoDB DBaaS độc lập hơn, nhưng điều đó bị hạn chế đáng kể do thay đổi giấy phép SSPL
    Hy vọng FerretDB sẽ tạo ra được một lựa chọn thay thế khả thi

    • “Tập trung hóa cực đoan” ư, cứ chờ đến khi us-East-1 sập đi

  • Thông báo bảo mật tôi nhận hôm nay nói rằng MongoDB đang điều tra việc truy cập trái phép vào một số hệ thống doanh nghiệp, và metadata tài khoản khách hàng cùng thông tin liên hệ đã bị lộ
    Hiện tại họ nói chưa biết có việc dữ liệu khách hàng lưu trong MongoDB Atlas bị lộ hay không
    Họ phát hiện hoạt động đáng ngờ vào tối thứ Tư, ngày 13/12/2023 theo giờ miền Đông Mỹ, lập tức kích hoạt quy trình ứng phó sự cố, và tin rằng quyền truy cập đã diễn ra trong một khoảng thời gian trước khi bị phát hiện
    Họ khuyến nghị khách hàng cảnh giác với tấn công social engineering và phishing, áp dụng xác thực đa yếu tố chống phishing nếu chưa làm và luân chuyển mật khẩu, đồng thời sẽ cập nhật thêm thông tin tại mongodb.com/alerts

    • Tôi cũng nhận được email tương tự
      May là thực ra tôi không dùng MongoDB Atlas

  • “Dữ liệu của các bạn vẫn an toàn. Vì ngay từ đầu chúng tôi chưa từng ghi nó xuống đĩa.”

  • Tôi chưa từng dùng MongoDB, nên tò mò không biết vì sao mọi người chọn MongoDB thay vì các cơ sở dữ liệu khác

    • Nó rất linh hoạt
      Vì không phát triển theo schema, nên chẳng hạn khi thay đổi tính năng và dữ liệu nhanh, bạn không phải quá lo về migration
      Đây là lợi thế lớn với các startup muốn đi nhanh
      Truy vấn trông giống mã ứng dụng, nên ít phải vắt óc dịch ý tưởng sang truy vấn SQL hơn, và theo kinh nghiệm của tôi dẫn đến các truy vấn ít dễ vỡ hơn
      Injection cũng ít phải bận tâm hơn trừ khi cố tình tạo cấu trúc nguy hiểm, và tôi thấy viết truy vấn phức tạp dễ hơn so với SQL
      Ép kiểu cũng có thể xử lý trong code thay vì dùng các hàm SQL inline phụ thuộc nền tảng như field_name::timestamp
      Có một chuẩn duy nhất cho cách truy vấn và phát triển, gần như không phải phát triển theo từng dialect như SQL
      Nó mở rộng khá tốt và dễ dàng trong đa số trường hợp sử dụng, và vì chỉ có một loại MongoDB nên cũng ít có chỗ cho sự rối rắm giáo điều quanh các biến thể cụ thể
    • Nó là người đi đầu trong thời kỳ ai cũng nghĩ cơ sở dữ liệu tài liệu NoSQL sẽ giải quyết mọi vấn đề
    • MongoDB là lựa chọn NoSQL tiêu biểu
      Nếu bạn nghĩ schema linh hoạt là tốt thì MongoDB rất tuyệt, còn nếu nghĩ schema linh hoạt là xấu thì nó không hay
      Tóm lại chỉ có vậy
    • Tôi dùng on-premises, chính xác hơn là trên VPS
      Dễ lưu trữ và thao tác với tài liệu JSON
      Nếu dữ liệu có dạng cây thì nó khá phù hợp ngay cả với tài liệu lớn
      Nếu phụ thuộc vào quan hệ giữa các tài liệu thì cơ sở dữ liệu SQL tốt hơn, nhưng trong nhiều trường hợp—thực ra là gần như mọi trường hợp bình thường—quan hệ kiểu SQL không thật sự cần thiết
      MongoDB cũng xử lý quan hệ, chỉ là phức tạp hơn một chút
    • Khá dễ bắt đầu
      MQL cũng dễ hiểu, và khiến MongoDB phần nào có cảm giác thú vị
      Nhân tiện, tôi làm việc ở MongoDB

  • Dạo này tôi tò mò vì sao mọi người vẫn tiếp tục chọn MongoDB thay vì Postgres
    Nếu có điều gì tôi bỏ lỡ thì tôi thật sự muốn biết, và tôi cũng không phản đối bản thân dữ liệu JSON; tôi thường dùng bảng jsonb trong Postgres

    • Lý do dùng MongoDB là vì dễ bắt đầu
      Nó lo “việc cơ sở dữ liệu” và “xác thực” cho bạn
      Tôi đã từ bỏ việc chống lại xu hướng này, và giờ khi thấy dùng MongoDB ở giai đoạn đầu, tôi lập tức xem đó là dấu hiệu các developer vẫn đang gắn bánh phụ