CVE-2024-8013 - Inside the MongoDB Encrypted Fields Disclosure Bug

If you’re using MongoDB’s Client-Side Field Level Encryption (CSFLE), you count on it to keep sensitive information hidden—even from your database server. But a recently discovered bug, CVE-2024-8013, shows how certain queries could accidentally send plaintext data to MongoDB servers, exposing information that should have remained encrypted.
This long-form post explains what went wrong, how the issue can be triggered, and how to keep your data safe moving forward.

What is CVE-2024-8013 About?

A bug in the query analysis part of MongocryptD and associated libraries means that, for certain self-referential $lookup subpipelines, literal values inside expressions for encrypted fields might be sent as plaintext, not ciphertext.
This is a disclosure: the sensitive values are accidentally exposed to the server unencrypted in some query situations.

If this occurs

- No data is returned or modified: The query fails to match or write anything because the format is wrong (plaintext, not ciphertext).
- But the literal plaintext is still exposed: The server (or anyone monitoring the query traffic) can see the plaintext value.

Who is Affected?

This bug *only* impacts those using client-side field-level encryption with the following MongoDB binaries or libraries:

v7.3 before 7.3.4

All released alongside MongoDB *Enterprise Server* versions.

The Problem in Detail

*Self-referential* $lookup subpipelines are when a collection joins with itself during a query, with pipeline stages that reference that same collection.
If your CSFLE-encrypted collection is queried this way, and you embed a literal value in an expression targeting an encrypted field, the client library’s query analyzer might skip encryption for that literal.
This means the server receives your sensitive value raw, rather than wrapped in encryption.

Suppose you have a users collection like this

{
  "email": "<ENCRYPTED>",
  "notes": "Plaintext notes",
  "_id": 123
}

Assume "email" is encrypted with CSFLE.

A potentially problematic query might be

db.users.aggregate([
  {
    $lookup: {
      from: "users",
      let: { e: "$email" },
      pipeline: [
        { 
          $match: { 
            $expr: { 
              $eq: [ "$email", "alice@example.com" ] // <-- "alice@example.com" should be encrypted! 
            } 
          }
        }
      ],
      as: "self_matches"
    }
  }
])

In affected versions, "alice@example.com" is sent as plaintext, not ciphertext, in the pipeline.

What Actually Happens?

- The query will NOT match any documents, because the comparison fails ("alice@example.com" != <ENCRYPTED>).

Even if your query fails, your secrecy is broken.

No documents are leaked, but sensitive data could *leak in queries*.


## How To Fix/Protect Yourself

7.3.4

> Official MongoDB release notes
> MongoDB Security Updates

2. Audit Your Queries

- Search for $lookup patterns where a literal value is compared to an encrypted field in a subpipeline.

Unexpected literal values for encrypted fields in queries.

Check query logs if available, or set up future audits with MongoDB auditing features.

Conclusion

CVE-2024-8013 highlights the subtlety of encryption features:
Your tooling can fail in unexpected ways, even when you think you’re doing everything right.
If you use CSFLE and complex $lookup queries, upgrade now and review your query code.
Stay safe—and always check those release notes!


References
- MongoDB Security Advisory (CVE-2024-8013)
- MongoDB 7.3.4 Release Notes (fix included)
- Understanding $lookup


If you have any questions or want to check a specific query, feel free to ask in the comments below!

Timeline

Published on: 10/28/2024 13:15:10 UTC
Last modified on: 10/28/2024 13:58:09 UTC