TL;DR: This advisory covers the two most important high-severity memory-safety vulnerabilities affecting MongoDB Community and our downstream Percona Server for MongoDB – CVE-2026-11933 and CVE-2026-9740. Both will be addressed in a single coordinated patch release, bundled with other recently revealed lower-scored CVE fixes: CVE-2026-9753, CVE-2026-9752, CVE-2026-9751, CVE-2026-9750, CVE-2026-9749, CVE-2026-9748, CVE-2026-9747, CVE-2026-9746, CVE-2026-9743, and CVE-2026-9741.
Fixes land in Percona Server for MongoDB patch window starting next week. The first high-vulnerability issue has nothing between it and your mongod process except your firewall. The second has a configuration off-switch you can flip during a maintenance window. Read on to understand why, how, and what.
A stack overflow in the BSON validator, specifically in the BSONColumn interleaved-reference handling. The validator’s depth tracking resets on mutual recursion between validation functions, so a sufficiently nested input exhausts the thread’s stack before any explicit limit fires. The result: mongod crashes.
CVSS 8.7. High severity. The reason it lands in High instead of merely Medium is the prerequisite for exploitation – there is none.
The attacker needs network reachability to a mongod listener. No credentials, no prior session, and no application interaction. One crafted message over the wire and the process is down. Repeated crashes are trivially repeatable, so an attacker who can reach the port can keep the instance offline for as long as they keep that reachability. The urgency of this issue comes from the audience – everyone with a TCP route to your database.
Upstream tracking: SERVER-125063. Affected versions are Percona Server for MongoDB 8.0 ≤ 8.0.23-10 and PSMDB 7.0 ≤ 7.0.34-19. The vulnerable BSONColumn code path was introduced in 7.0, so 6.0 and earlier are not in scope for this one.
The vulnerable code path is inside MongoDB Server’s server-side JavaScript engine, specifically in the BSON-to-array conversion routine. When a BSON document is materialized as a JavaScript array for use inside a server-side script, the engine can reach a state where it accesses memory that has already been freed. An attacker who can submit input that flows into that conversion path can shape what happens at the point of access.
Server-side JavaScript is reachable from the following surfaces:
MongoDB logs a warning when you run deprecated functions.
Prerequisites for exploitation:
CVSS 8.8. High severity. Two demonstrated outcomes:
mongod process memory) andUpstream tracking: SERVER-128125. Affected versions: every supported and End of Life Percona Server for MongoDB major from 4.4 through 8.0.
CVE-2026-11933 has a configuration off-switch. If your application does not use server-side JavaScript — $where, $function, $accumulator, mapReduce, or stored system.js functions — you can disable server-side JavaScript on the server, removing the attack surface entirely until you patch.
Add to your configuration file for mongodand mongos:
|
1 2 |
security: javascriptEnabled: false |
Or pass --noscripting on the command line. See the reference documentation for details about MongoDB Setting: security.javascriptEnabled.
After a restart, any operation that reaches for server-side JavaScript will return an error. That is the catch: if your application does use one of those operators, this is not a viable mitigation for you, and you have to wait for the patch. If you are not sure whether your application uses them, turn on the database profiler at level 2 on a representative replica for a window long enough to be representative, then grep the profile collection for the operator names. Several teams have done this exercise in the last forty-eight hours and learned the answer is “no, we don’t actually use any of that.” The cost of disabling is then the cost of a mongod or mongos restart.
That was good news. Now the bad news: CVE-2026-9740 has no equivalent off-switch. The BSON validator is core to every client message; it cannot be disabled. Patch and network controls are the only options.
The fixes for both CVEs will land in a single coordinated patch release for each supported major:
All dates are targets, not commitments. Plan one upgrade window covering all CVEs.
Percona is not building binary packages for the 5.x line. We’re being upfront about that — the calculus on extended support has a limit, and 5.x is past it for us. If you have a hard requirement on 5.x and the time pressure to meet it, the source is available for building. Percona customers on 5.x can open a ticket, and we’ll work on the case individually.
As usual, you can download patches from your package manager or Percona Software Downloads page.
On Kubernetes via the Percona Operator for MongoDB: same drill as usual. When the patched image is published, edit the image tag in your PerconaServerMongoDB custom resource and let the operator roll the cluster. Don’t wait for the June operator release to do it for you. See details in our documentation on how to Upgrade Percona Server for MongoDB. You do not need to wait for an operator release to apply a security fix.
In order of urgency, for most deployments:
mongod or mongos listeners are not reachable from any source you would not trust with a shell on the host. If you find an exposure, fix that first. CVE-2026-9740 turns any such exposure into a DoS primitive.mongod restart.One closing point, because it has come up several times in customer conversations this week. For a deployment behind tight network controls, the post-authenticated bug is the more urgent one. For a deployment reachable from broader networks — public cloud, shared internal LANs, multi-tenant infrastructure — the pre-authenticated bug is. Triage by your exposure, not by their CVSS.
Questions, or a deployment you’re not sure how to triage? Find us on the Percona Forum, or, for customers, in the support portal.
Reviewed by Ivan Groenewold. Vetted for technical accuracy as of June 17, 2026.
Resources
RELATED POSTS
