MongoDB Server Security Update, December 2025(mongodb.com)
mongodb.com
MongoDB Server Security Update, December 2025
https://www.mongodb.com/company/blog/news/mongodb-server-security-update-december-2025
51 comments
"
>proactive [...] security program
Idk how proactive patching an exploited-in-the-wild unauth RCE is, but pr statements gonna pr i guess.
"
If you follow their history, especially the jepsen analysis and the whole back and forth, you will find a pattern.
If you follow their history, especially the jepsen analysis and the whole back and forth, you will find a pattern.
> IANAL, but this seems like a pretty strong stance to take? Who exactly are you blaming here?
It's a factually statement, unless you know of some information that indicates MongoDB was breached. I think you mistook "MongoDB" there to be the software instead of the company. They meant the company, their systems and infrastructure was not compromised.
> Interesting choice of words. I wonder if their SIEM/SOC discovered a compromise, or if someone detected a tweet.
I highly doubt that. it could be a crash someone noticed, a code audit, internal bug-bounty,etc.. either way I wouldn't ascribe to them deceit without proof, if it was an external source, give them the benefit of doubt that they'd have said so.
> It took 72 clock hours, assumably hundreds of man hours, to fix a malloc use after free and cstring null term bug? Maybe the user input field length part was a major design point??
You are familiar with things like SOC and SIEM, and you're confused by this? Are you familiar with Incident Response? The act of editing the code in a text editor and committing it to a branch isn't what took 72 hours.
> Boy this sure seems like a long time for a first communication for a guaranteed compromise if internet facing bug.
It does not, far from it.
> Not sure there's a security tool in the world that would stop data exfiltration via protocol error logs.
Maybe not prevent, but certainly detect and attempt to interdict/stop is certainly possible. That's what SIEMs do if they're adequately configured. But the drawback might be considerable volume of false hits. It might be better to simply reduce exposure to the internet, or remove it entirely. Just pointing out that, at least detection is possible, even with 0 days like this.
It's a factually statement, unless you know of some information that indicates MongoDB was breached. I think you mistook "MongoDB" there to be the software instead of the company. They meant the company, their systems and infrastructure was not compromised.
> Interesting choice of words. I wonder if their SIEM/SOC discovered a compromise, or if someone detected a tweet.
I highly doubt that. it could be a crash someone noticed, a code audit, internal bug-bounty,etc.. either way I wouldn't ascribe to them deceit without proof, if it was an external source, give them the benefit of doubt that they'd have said so.
> It took 72 clock hours, assumably hundreds of man hours, to fix a malloc use after free and cstring null term bug? Maybe the user input field length part was a major design point??
You are familiar with things like SOC and SIEM, and you're confused by this? Are you familiar with Incident Response? The act of editing the code in a text editor and committing it to a branch isn't what took 72 hours.
> Boy this sure seems like a long time for a first communication for a guaranteed compromise if internet facing bug.
It does not, far from it.
> Not sure there's a security tool in the world that would stop data exfiltration via protocol error logs.
Maybe not prevent, but certainly detect and attempt to interdict/stop is certainly possible. That's what SIEMs do if they're adequately configured. But the drawback might be considerable volume of false hits. It might be better to simply reduce exposure to the internet, or remove it entirely. Just pointing out that, at least detection is possible, even with 0 days like this.
>I think you mistook "MongoDB"
I must have, the sentence does not make sense to me. Here it is, shortened: "this vuln in mongodb server does not impact mongodb, managed mongodb server, or our systems". If the first clause is referring to their systems, why do they say the same thing in the third clause?
Also i just noticed, how come they say atlas wasn't affected but say they patched it in their timeline?
>give them the benefit of doubt that they'd have said so
Statements like this are basically legal admissions of guilt, i expect there to be as little truth as possible.
>You are familiar with things like SOC and SIEM, and you're confused by this?
I work in IT, I'm not a coder... so yes :) hundreds of hours seems excessive. Remember, this isn't a safe deployment or rollout plan, that's the next block of time. Hundreds of man hours is more than one person's full month of work. Do you expect it to take you a whole, dedicated month to fix 1 bug at a time?
>That's what SIEMs do if they're adequately configured.
This is a bit of a no true Scotsman. The intended error log is "error: {cstring payload nullterm} broke" and the mongobleed log is "error: {cstring payload MISSINGNULLTERM cstring payload nullterm} broke". Those two things look identical, how is any amount of configuration supposed to catch that?
I must have, the sentence does not make sense to me. Here it is, shortened: "this vuln in mongodb server does not impact mongodb, managed mongodb server, or our systems". If the first clause is referring to their systems, why do they say the same thing in the third clause?
Also i just noticed, how come they say atlas wasn't affected but say they patched it in their timeline?
>give them the benefit of doubt that they'd have said so
Statements like this are basically legal admissions of guilt, i expect there to be as little truth as possible.
>You are familiar with things like SOC and SIEM, and you're confused by this?
I work in IT, I'm not a coder... so yes :) hundreds of hours seems excessive. Remember, this isn't a safe deployment or rollout plan, that's the next block of time. Hundreds of man hours is more than one person's full month of work. Do you expect it to take you a whole, dedicated month to fix 1 bug at a time?
>That's what SIEMs do if they're adequately configured.
This is a bit of a no true Scotsman. The intended error log is "error: {cstring payload nullterm} broke" and the mongobleed log is "error: {cstring payload MISSINGNULLTERM cstring payload nullterm} broke". Those two things look identical, how is any amount of configuration supposed to catch that?
> Do you expect it to take you a whole, dedicated month to fix 1 bug at a time?
Like I said, the bugfix is not what takes long. They have to figure out the extent of the vulnerability, do regression testing, make sure they don't introduce more issues. And _then_ they can begin sending embargo notifications, let their customers prep, patch,etc... while in parallel they do analysis of in-the-wild exploitation. They have to support all the paying customers that are panicking and want answers. You're not the only one scrutinizing every word they say and demanding answers. They talked to lawyers plenty during that time. If you know legal admission of guilt is one of the things included, then you should know they're publicly traded and SOX plus section 8 filings are a huge deal. Their CISO could literally end up in prison if he screws this up. So yeah, it takes a couple of days. They have to have outside parties (likely) support their response, even without that, "who did what", "what was affected", "how was it abused", "how can it be prevented" , all of that needs to be answered, and then there is lots of back on forth on the specifics of the wording to the public/PR, what to tell investors, customers, etc...
> This is a bit of a no true Scotsman.
There are different detection strategies possible. Your approach could be done, when an error message that hasn't been seen previously suddently shows up, it could be flagged for follow-up investigations, contact mongo support,etc.. that's not what I meant though, you mentioned exfil, abnormal data transfers from 'mongod' could be caught is what I meant. Most moderns SIEMS do this out of the box if you feed them right and well.
Like I said, the bugfix is not what takes long. They have to figure out the extent of the vulnerability, do regression testing, make sure they don't introduce more issues. And _then_ they can begin sending embargo notifications, let their customers prep, patch,etc... while in parallel they do analysis of in-the-wild exploitation. They have to support all the paying customers that are panicking and want answers. You're not the only one scrutinizing every word they say and demanding answers. They talked to lawyers plenty during that time. If you know legal admission of guilt is one of the things included, then you should know they're publicly traded and SOX plus section 8 filings are a huge deal. Their CISO could literally end up in prison if he screws this up. So yeah, it takes a couple of days. They have to have outside parties (likely) support their response, even without that, "who did what", "what was affected", "how was it abused", "how can it be prevented" , all of that needs to be answered, and then there is lots of back on forth on the specifics of the wording to the public/PR, what to tell investors, customers, etc...
> This is a bit of a no true Scotsman.
There are different detection strategies possible. Your approach could be done, when an error message that hasn't been seen previously suddently shows up, it could be flagged for follow-up investigations, contact mongo support,etc.. that's not what I meant though, you mentioned exfil, abnormal data transfers from 'mongod' could be caught is what I meant. Most moderns SIEMS do this out of the box if you feed them right and well.
> Boy this sure seems like a long time for a first communication for a guaranteed compromise if internet facing bug.
If you still run MongoDB facing the internet you have bigger problems.
If you still run MongoDB facing the internet you have bigger problems.
>>This [...] vuln is not a breach or compromise of MongoDB
>IANAL, but this seems like a pretty strong stance to take? Who exactly are you blaming here?
You elide the context that explains it. It's a vulnerability in their MongoDB Server product, not a result of MongoDB the company/services being compromised and secrets leaked.
>IANAL, but this seems like a pretty strong stance to take? Who exactly are you blaming here?
You elide the context that explains it. It's a vulnerability in their MongoDB Server product, not a result of MongoDB the company/services being compromised and secrets leaked.
> Idk how proactive patching an exploited-in-the-wild unauth RCE is, but pr statements gonna pr i guess.
Describing their response as "proactive" is about what you'd expect from a company that famously used unacknowledged writes to game benchmarks during their peak hype phase. Ironically, Mongo has been slower than PostgreSQL for years at JSON queries, the very thing at which it's supposed to excel, and especially relative to a "boring," "antiquated" relic like Postgres, which was started all the way back in 1985.
The real head-scratcher here is who is still using MongoDB, and why? It got to a point years ago where even "I told you so" types (like me) found it no longer necessary to pile on, given the wave of buyer's remorse postmortems from devs who bought into MongoDB's hype.
Describing their response as "proactive" is about what you'd expect from a company that famously used unacknowledged writes to game benchmarks during their peak hype phase. Ironically, Mongo has been slower than PostgreSQL for years at JSON queries, the very thing at which it's supposed to excel, and especially relative to a "boring," "antiquated" relic like Postgres, which was started all the way back in 1985.
The real head-scratcher here is who is still using MongoDB, and why? It got to a point years ago where even "I told you so" types (like me) found it no longer necessary to pile on, given the wave of buyer's remorse postmortems from devs who bought into MongoDB's hype.
It wasn't an RCE.
Oh goodness, wheres my head at, thank you. Too late to edit, but you are correct. Memory exfiltration, potentially containing passwords and secrets, leading to privilege escalation. Not an RCE.
>Memory exfiltration, potentially containing passwords and secrets
and potentially not, too. totally overhyped
and potentially not, too. totally overhyped
Why did it take them 4 days between publishing a CVE for the vulnerability (Dec 19th) and posting a public patch (Dec 23rd)?
Had their hands full getting sued the same day: https://news.ycombinator.com/item?id=46403128
Might not be how it appears. The CVE number can be reserved by the org and then "published" with only minimal info, then later update with full details. Looking at the meta data that's probably what happened here (not entirely sure what the update was though):
{
"cveId": "CVE-2025-14847",
"assignerOrgId": "a39b4221-9bd0-4244-95fc-f3e2e07f1deb",
"state": "PUBLISHED",
"assignerShortName": "mongodb",
"dateReserved": "2025-12-17T18:56:21.301Z",
"datePublished": "2025-12-19T11:00:22.465Z",
"dateUpdated": "2025-12-29T23:20:23.813Z"
}That's a good question. I suppose that posting the commit makes it incredibly obvious how to exploit the issue, so maybe they wanted to wait a little bit longer for their on-prem users who were slow to patch?
Posting the CVE and then the patch is the reverse of this.
By "patch" I am talking about the public commit. Updated binaries were made available when the CVE was published.
That's not what the blog post implies given they only told people how to update aftwards.
1 day ago, 116 comments: https://news.ycombinator.com/item?id=46414475
if you are using mongodb in 2026 you deserve everything headed in your direction
And can you explain why? I think not. What's the superior alternative, for every use case?
PG JSON write operations are document level whereas with Mongodb it's field level.
Would you use a DB that only let you write an entire row instead of setting a single field? Race conditions galore. Be very careful choosing PG for JSON in production systems...
Would you use a DB that only let you write an entire row instead of setting a single field? Race conditions galore. Be very careful choosing PG for JSON in production systems...
on postgres I can update a field easily and atomically with transactions (or there is something I don't know about?), like (postgresql 14)[0]:
UPDATE users SET profile = profile || '{"lastname":"Washington"}' WHERE profile->>'name' = 'George Washington';
Nope. If two writes happen concurrently on different fields you'll lose one write, unless you lock. The storage layer just stores the data as a blob that gets overwritten every time, it doesn't support partial updates.
Of course it supports partial updates. It just requires you to know the difference between a document and a field, and model your data appropriately.
Why? I felt the same for a while but it’s really massively improved over the years. Yes, this is a bad vuln but anyone with even. tiny bit of brain is not running mongo on the internet.. I’m using mongo very successfully at the moment in ways i could not use postgres.
Genuinely interested: what problems does mongo fit better than mainstream competitors these days? Why would you use it on a new project?
My application's primary task is to move JSON objects between storage and front-end. It does a lot more, but that's it's primary task. So document storage is a logical choice. There are no real reasons to join records, although it sometimes is more efficient to do so. MongoDB's join operation has one advantage (for 1:N relations): it groups the joined records as an array in the document, instead of multiplying the answers, so whatever function operates on the original data, also works on the joined data. The data itself is hierarchical in nature, so back-end operations also preferably work on structured data instead of rows.
You can argue that you can imitate that in Postgres or even SQLite by storing in JSON fields, but there are things they can't do quite as efficiently (e.g. indexing array contents); storage itself isn't very efficient either. But ignoring that, there's no functional difference: it's document in, document out. So then the choice boils down to speed, memory usage, etc. One day I'm going to check if Postgresql offers a real performance advantage, but given the backlog, that may take a while. Until then, MongoDB just works.
You can argue that you can imitate that in Postgres or even SQLite by storing in JSON fields, but there are things they can't do quite as efficiently (e.g. indexing array contents); storage itself isn't very efficient either. But ignoring that, there's no functional difference: it's document in, document out. So then the choice boils down to speed, memory usage, etc. One day I'm going to check if Postgresql offers a real performance advantage, but given the backlog, that may take a while. Until then, MongoDB just works.
How is that problem not solved by json aggregation? You don't have to store the data as json then?
I consult for a small company which feeds some of the largest market research companies. This company finds data providers for each country, collect the data monthly and need to massage it into a uniform structure before handing it over. I help them scripting this. I found importing the monthly spreadsheets into mongodb and querying the set can replace an awful lot of manual scripting work. That aggregator queries are a good fit for an aggregator company shouldn't be that big of a surprise, I guess.
The mongodb instance is ephemeral, the database itself is ephemeral, both only exist while the script is running which can be measured in seconds. The structure is changing from month to month. All this plays to the strengths of mongodb while avoiding the usual problems. For eg one stage of the aggregate pipeline can only be 100MB? A source csv is a few megabytes at most.
Ps.: no, Excel can't do it, I got involved with this when the complexity to do it in Excel has become unbearable.
The mongodb instance is ephemeral, the database itself is ephemeral, both only exist while the script is running which can be measured in seconds. The structure is changing from month to month. All this plays to the strengths of mongodb while avoiding the usual problems. For eg one stage of the aggregate pipeline can only be 100MB? A source csv is a few megabytes at most.
Ps.: no, Excel can't do it, I got involved with this when the complexity to do it in Excel has become unbearable.
To be honest, I don't think it was a stand-out 'it's better for X than Y because of Z' kind of choice for us. We are a bank, and so database options are quite limited (it's Oracle or Mongo, essentially for certain applications).
I have one application at the moment which needs to handle about 175k writes/second across AZ's. We are not sharding at the moment, but probably will once scale requires (we are getting close) -- so just one big replica-set and it's behaving .. really nicely. I tried to emulate this workload on Postgres (which is my favourite database over my entire career so far (many scars)) and we couldn't get it to where mongo was for this workload, multi-az is painful, automatic failover is still an unanswered question really, I've tried all the 'right around the corner' multi-master Postgres options and none of them did anything other than make us sad.
From the developer standpoint, it's very nice to use, I just throw documents at it and it saves them. If I want an extra field, I just add it. If I want an index on something, also just add it. No big complicated schema migrations.
Especially what helps is we have absolutely incredibly great support from MongoDB. We have a _weekly_ call with them with a bunch of their senior engineers who answer all our stupid questions and proactively look for things to improve.
Ops story is also good, we aren't using Atlas, but the on-prem kube setup while a bit clunky has enough CRDs and whatever to keep devops happy for weeks at a time.
tl;dr -- it's boring and predictable, and I rarely have to think about it which is all I ever want from a database. I'm sure we could achieve the same results with other database technologies, but the ROI on even investigating them would not be worth it, as at best I think we would end up at the same place we are at now. People seem to have deeply religious feelings on databases, but I've never really been one of them.
I would not hesitate to use it on a new project.
I have one application at the moment which needs to handle about 175k writes/second across AZ's. We are not sharding at the moment, but probably will once scale requires (we are getting close) -- so just one big replica-set and it's behaving .. really nicely. I tried to emulate this workload on Postgres (which is my favourite database over my entire career so far (many scars)) and we couldn't get it to where mongo was for this workload, multi-az is painful, automatic failover is still an unanswered question really, I've tried all the 'right around the corner' multi-master Postgres options and none of them did anything other than make us sad.
From the developer standpoint, it's very nice to use, I just throw documents at it and it saves them. If I want an extra field, I just add it. If I want an index on something, also just add it. No big complicated schema migrations.
Especially what helps is we have absolutely incredibly great support from MongoDB. We have a _weekly_ call with them with a bunch of their senior engineers who answer all our stupid questions and proactively look for things to improve.
Ops story is also good, we aren't using Atlas, but the on-prem kube setup while a bit clunky has enough CRDs and whatever to keep devops happy for weeks at a time.
tl;dr -- it's boring and predictable, and I rarely have to think about it which is all I ever want from a database. I'm sure we could achieve the same results with other database technologies, but the ROI on even investigating them would not be worth it, as at best I think we would end up at the same place we are at now. People seem to have deeply religious feelings on databases, but I've never really been one of them.
I would not hesitate to use it on a new project.
> From the developer standpoint, it's very nice to use, I just throw documents at it and it saves them. If I want an extra field, I just add it. If I want an index on something, also just add it. No big complicated schema migrations.
This sentence summarize all the issues developers working with Mongo will have: multiple version of documents living in the same DB and unpredictable structure
Best thing MongoDB have it's definitely their marketing (making everyone think it's amazing to invest hundreds of millions to deliver an "OK" tier database) and their customer support
This sentence summarize all the issues developers working with Mongo will have: multiple version of documents living in the same DB and unpredictable structure
Best thing MongoDB have it's definitely their marketing (making everyone think it's amazing to invest hundreds of millions to deliver an "OK" tier database) and their customer support
Eh, not really. I've done both at considerable scale, and I don't hit these problems. Perhaps you need better developers? For sure, having your database enforce guardrails on what $thing should look like means your code can be lower quality, but you should pick the right tool for the job. For scenarios where I have one 'thing' that's not very relational, it works well. If your application dies because your $thing expects some field which isn't there, that's a you problem not a storage problem.
Requiring weekly handholding sessions for 175k RPS really takes the wind out of this tack doesn't it?
Tell me you’ve never built anything other than toys without saying you’ve never built anything but toys.
Who has mongo open to the internet?
listen, I'm not saying the venn diagram between people who use mongo and people who would open it to the internet is a circle, but there is... ahem... a big overlap
Many people who use MongoDB Atlas (or other hosted MongoDB services) alongside a PaaS like Heroku that doesn’t offer static IPs or ranges.
Acc to a comment I read elsewhere, it's in the thousands (shodan result)
We used MongoDB's cloud offering (Atlas) and have had nothing but problems with it. Like, serious problems - "production down for multiple days" problems caused entirely by MongoDB messing up SSL certificates on their end. We were utterly powerless to do anything and their support was dreadful. I cannot take their products seriously now.
Obligatory ("Postgres is Enough"): https://gist.github.com/cpursley/c8fb81fe8a7e5df038158bdfe0f...
Gemini generated explanation and simulation of MongoBleed: https://gemini.google.com/share/3529c5bb7d38
Reference: https://bigdata.2minutestreaming.com/p/mongobleed-explained-...
Reference: https://bigdata.2minutestreaming.com/p/mongobleed-explained-...
Idk how proactive patching an exploited-in-the-wild unauth RCE is, but pr statements gonna pr i guess.
>This [...] vuln is not a breach or compromise of MongoDB
IANAL, but this seems like a pretty strong stance to take? Who exactly are you blaming here?
>vulnerability was discovered internally >detected the issue
Interesting choice of words. I wonder if their SIEM/SOC discovered a compromise, or if someone detected a tweet.
>December 12–14 – We worked continuously
It took 72 clock hours, assumably hundreds of man hours, to fix a malloc use after free and cstring null term bug? Maybe the user input field length part was a major design point??
>dec 12 "detect" the issue, dec 19 cve, dec 23 first post
Boy this sure seems like a long time for a first communication for a guaranteed compromise if internet facing bug.
Not sure there's a security tool in the world that would stop data exfiltration via protocol error logs.