‹ Back to Blog

MongoDB's Node Driver 7.8.0 Patches Two Real Security Issues

Engineering Node.js Observability

If your Node app talks to MongoDB through the official mongodb driver, 7.8.0 is worth upgrading to before your next routine dependency pass. It’s a minor version by the number, but it carries two security fixes, and one of them changes how a feature you may already be using behaves.

What Was Actually Broken

Two separate issues, both worth taking seriously.

The first is a connection-pool bug tied to the experimental timeoutMS feature (CVE-2026-119179). On driver versions from v6.11.0 and from v7.0.0 up to this release, a connection pool could desynchronize after an operation timed out, and one request could end up reading another user’s data. That’s the kind of cross-request data exposure you never want in a data layer. The driver’s response is blunt: timeoutMS and timeoutMode are now deprecated and a no-op in 7.8.0. They’re still accepted so nothing throws, but they no longer time anything out.

The second affects anyone connecting with a mongodb+srv:// connection string. On versions from v3.3.3 up to 7.8.0, the driver didn’t properly verify the hostnames returned by the SRV DNS lookup, so an attacker in control of the DNS response could redirect the driver to a host outside your domain. 7.8.0 normalizes and validates SRV hostnames, and adds two controls to tighten it further: srvAllowedHostsSuffix (every returned host must end with a given suffix) and srvHostValidator (a function you supply that approves or rejects each host).

The timeoutMS Change Will Touch Real Code

Because the fix for the first issue is to neuter timeoutMS entirely rather than repair it, this isn’t a silent patch. If your code sets timeoutMS expecting operations to time out, they won’t anymore, and they won’t error either. That’s the quiet kind of regression that’s easy to miss, because nothing breaks loudly; operations just stop giving up when you thought they would.

Before you ship the upgrade, grep for timeoutMS and timeoutMode and move to the per-stage timeouts the driver points you at instead: serverSelectionTimeoutMS, waitQueueTimeoutMS, socketTimeoutMS, and maxTimeMS for server-side execution.

A Few Non-Security Changes Rode Along

7.8.0 isn’t only security work. A handful of ergonomics and correctness fixes shipped too:

  • zstd compression now uses Node.js’ built-in implementation on Node 22.15.0+, so @mongodb-js/zstd is no longer required there. Older Node versions keep using the package, so existing setups need no change.
  • createIndex() now separates index options from command options into distinct arguments. The old two-argument form still works for now but is slated to go in a future major.
  • Index options are passed to the server as written, so you can use a new server-supported option without waiting for the driver to allow-list it, with the tradeoff that a bad option now throws instead of being silently dropped.
  • Sorting by $meta in the [field, direction] form works now instead of throwing, and bulk-write insertedIds is keyed by operation index for mixed unordered writes, matching ordered writes and the docs.

None of these carry the urgency of the two security fixes. Prioritize the upgrade for those.

Why This One Hits Wide

The official mongodb package is the foundation under most Node data layers, Mongoose included, since it wraps this driver. If your Node service stores anything in MongoDB, this is very likely the client doing the talking. npm install mongodb@7.8.0 (or a lockfile bump) gets most projects already on 7.x to the fix. The SRV issue reaches all the way back to 3.3.3, so if you’re pinned to an older major and use SRV connection strings, this is a good moment to evaluate the upgrade path.

How Scout Sees What Changes After You Upgrade

Scout Monitoring traces your MongoDB operations alongside your database queries, external HTTP calls, and background jobs, in the same trace view you already use. That matters most right after a change like this one. When you drop timeoutMS for the per-stage options, the timing and failure behavior of your queries can shift, and Scout surfaces those operations so you can confirm the per-stage timeouts behave the way you expect and the patch didn’t bring a regression with it.

For application monitoring with errors, logs, and traces, Scout Monitoring provides the fastest insights without the bloat.