r/mongodb

Disclosure up front: I work at Percona. Posting this because the framing in some of the chatter I'm seeing about CVE-2026-8053 is going to leave many teams exposed.

The bug in one line: out-of-bounds memory write in MongoDB's time-series bucket catalog. An authenticated user with the readWrite role on any database can trigger it via a crafted sequence of operations against a time-series collection. CVSS v3.1 8.8, v4.0 8.7. Upstream tracking: SERVER-126021.

Why is the prerequisite weaker than it looks?

The advisory says the attacker needs database write privileges. That's accurate, but in practice, it means the built-in readWrite role, which is what most application accounts already hold.

So an attacker who lifts an application credential — from a CI log, a .env file, a compromised pod, an ex-employee's laptop — does not need your deployment to already host a time-series collection. They can create one on the spot and reach the vulnerable code path.

If your team is currently in the "we don't use time-series, we're fine" conversation, that's not the mitigation it sounds like. The only meaningful options are patching or restricting readWrite role to your application accounts (which most apps will break if you do it at runtime).

Fixed versions

• MongoDB Server (upstream): see SERVER-126021 for the fixed versions for each major release; fixes are available from 5.0 to 8.3.
• Percona Server for MongoDB:
  • 7.0.34-19 — May 20, 2026
  • 8.0.23-10 — May 21, 2026
  • 6.0.x patch — targeted for May 25, 2026
• 5.x: no binary packages, but the fix is on the public release branch release-5.0.33-26 if you need to build it.

If you're running PSMDB on Kubernetes via the Percona Operator, you don't need to wait for an operator release — trigger the upgrade in the nearest possible maintenance window.

What I'd actually do today

1. Patch on whichever schedule matches your major version.
2. Audit custom roles. Anything granting readWrite to application accounts is, until you patch, an RCE primitive in waiting. Decide whether those accounts really need to write at runtime or whether they can be scoped to a known set.
3. If you haven't already, enable MongoDB auditing for createCollection events. Useful for spotting unexpected time-series collection creation in the window before everyone is patched.

I am happy to answer any questions in the thread.

If you want the longer write-up — including the operational case that "authenticated RCE" deserves more urgency than it usually gets — I wrote it up on the Percona blog: https://www.percona.com/blog/cve-2026-8053-we-dont-use-time-series-is-not-a-mitigation/

Hey everyone,

We're running integration tests against mongodb/mongodb-atlas-local:8.0.4 in GitHub Actions and hitting a painful flakiness/performance problem caused by Atlas Search indexing latency. Looking for anyone who's solved this.

Setup

- Rails + Mongoid test suite, ~500+ specs that use $search

- 9 parallel job matrix on ubuntu-latest, each spins up its own mongodb-atlas-local service container

- Ruby polling helper that queries the Atlas Search index every 0.2s until the record appears (up to 15s timeout)

Problem

After inserting a document, it takes anywhere from 2 to 12+ seconds before it's visible via $search, even on an empty test database with a handful of documents. On local dev (Mac M1/M2) it's consistently under 1 second.

We understand why this happens:

- mongot (the Atlas Search indexer inside the image) is a JVM/Lucene process that starts cold on every CI job

- JVM startup + JIT warmup takes a few seconds before mongot can even process the first oplog entry

- Then the Lucene flush cycle writes segments to virtualized disk, which is 3-5x slower than NVMe

- With 9 parallel jobs on potentially the same physical host, disk I/O contention makes it worse

The result: many of our Atlas Search specs sit waiting for up to 15 seconds. It's making CI significantly slower and more expensive.

What we've already tried / ruled out

- ✅ Polling instead of fixed sleep — fixed flakiness but not the latency itself

- ✅ Waiting for the correct "last inserted" record (not an arbitrary count)

- ❌ Tuning mongot sync/flush interval — couldn't find any exposed config for this in mongodb-atlas-local

- ❌ Sharing one MongoDB container across partitions — breaks test isolation

Happy to share our polling helper implementation if useful for anyone hitting the same issue.

Any advice from teams running Atlas Search in CI at scale would be really appreciated.

GitHub Repo: https://github.com/vivekpandey76/mongodb-notes

Recently completed my full MongoDB course with videos + detailed notes covering aggregation, indexing, schema design, transactions, optimization, and more.

Now planning to start a new series:
“100 MongoDB Complex Problems”

The goal is to solve real-world backend/database challenges in the most optimized and production-ready way instead of only basic CRUD tutorials.

Would love to know:

• what MongoDB topics developers struggle with most
• interesting real-world problems to include
• things rarely explained properly in tutorials

Feedback and suggestions are welcome 🚀

I'm having trouble with setting up data base user in Mongo

Hi r/postgresql!

We just open sourced ParadeDB Benchmarker, a multi-backend benchmarking framework built on top of the excellent Grafana k6 (blog post).

One of the goals was avoiding a shared query abstraction layer. PostgreSQL queries stay PostgreSQL queries, with their own driver and native SQL.

Supports PostgreSQL, Elasticsearch, OpenSearch, ClickHouse, MongoDB, and ParadeDB with:

• mixed read/write workloads
• support for docker-compose profiles per backend
• dataset loader
• config and setup capture
• live metrics + exported reports

One of the ah-ha moments I had building this was using the pgx Go driver in anger for the first time, I'm a Rust guy, but I'm seriously impressed with pgx and what it can do.

Any comments welcome, we will be using this to benchmark ParadeDB, but you can write your own datasets and workloads which have nothing to do with full-text search.

Hello,

I have some users that are not so technical, but connect to the database regularly to extract some data.

However, sometimes they write really bad queries, or search for keys that don't exist in any document, leading to a client timeout -- however, the query continues running in the database backend for minutes. Sometimes for more than 10 minutes.

And almost everytime the users tend to insist on resubmitting the same query because the client timed out, leading to a few executions of the same query for the same amount of time..

I was thinking of a configuring some kind of kill switch for queries that run longer than X minutes, and are originated from specific appNames, for example mongoDB Compass

I am trying to avoid using maxTimeMS() as it's a global trigger, and I don't want to affect backend processes that are OK to have longer execution times, like heavy reporting and scheduled cronjobs.

I need to prepare a technical presentation about MongoDB. My goal is to show why and how to choose MongoDB over a relational DB by using a practical, real-world example.

I need an example that allows me to showcase:

1. Collection Structure: How to group data effectively
2. Schema Design Choices
3. Write Operations: Examples of interesting Inserts and Updates
4. Flexibility: How the schema handles varying data fields between documents.

Thanks in advance for your help!

Hi everyone! I’m a Product Manager on the Developer Experience team at MongoDB, and I’d love to learn more from this community about how you’re using MongoDB in AI applications.

A few things I’m especially curious about:

• What are you currently building with AI and MongoDB?
• What frameworks, libraries, or tools are you using? LangChain, LangGraph, LlamaIndex, Spring AI, Mastra, CrewAI, Vercel AI SDK, something else?
• Are you building agents, RAG apps, memory systems, workflow automation, eval pipelines, internal copilots, or something totally different?
• Where has MongoDB worked well for your use case?
• Where has it been harder than expected?
• What docs, integrations, examples, or product improvements would make your life easier?

I’m especially interested in hearing about real-world workflows: what you tried, what worked, what didn’t, and where you had to build around gaps.

Also, if you’ve built an open source project or example using MongoDB in an AI workflow, please share it! We’d love to see what the community is creating.

Thanks in advance. I’m here to listen and learn.

I am facing a MongoDB Atlas connection timeout issue in my Node.js + Express application.

Environment

- Node.js v24 (also tested with v22)

- Mongoose v9+ (also tested with v8.6)

- MongoDB Atlas

- VPS server (IPv4)

- Express.js backend

Problem

My application is unable to connect to MongoDB Atlas and always throws a timeout/server selection error.

Example error:

MongooseServerSelectionError: Could not connect to any servers in your MongoDB Atlas cluster

What I already tried

1. IP Whitelisting

- Added my VPS public IP in MongoDB Atlas Network Access

- Also tried:

0.0.0.0/0

(still same issue)

2. Different Connection Strings

Tried both:

- "mongodb+srv://"

- Standard connection string from Atlas

Still getting timeout issue.

3. DNS Changes

Added public DNS servers:

- "8.8.8.8"

- "1.1.1.1"

Also tried:

require('dns').setDefaultResultOrder('ipv4first');

No change.

4. Version Downgrade

Downgraded:

- Node.js 24 → 22

- Mongoose 9 → 8.6

Issue still persists.

5. Network Testing

When testing connectivity from the VPS, the MongoDB domain connection also times out.

Question

What else should I check?

Could this be:

- VPS firewall issue?

- ISP/VPS provider blocking MongoDB Atlas ports?

- DNS/SRV resolution problem?

- MongoDB Atlas networking issue?

Has anyone faced a similar issue with MongoDB Atlas on a VPS?

Any debugging steps or fixes would help.