5 ms·

MongoDB Server Security Update, December 2025

109 points by plorkyeran 10mo ago

gberger 10mo ago
Why did it take them 4 days between publishing a CVE for the vulnerability (Dec 19th) and posting a public patch (Dec 23rd)?
- computerfan494 10mo ago
  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?
  - philipwhiuk 10mo ago
    Posting the CVE and then the patch is the reverse of this.
    - computerfan494 10mo ago
      By "patch" I am talking about the public commit. Updated binaries were made available when the CVE was published.
      - philipwhiuk 10mo ago
        That's not what the blog post implies given they only told people how to update aftwards.
- cebert 10mo ago
  In the US, the last two weeks of December can be slow due to the holiday season. I wouldn’t be surprised if Mongo wasn’t as staffed as usual.
  - tanduv 10mo ago
    should've spun up a few more AI agents
- joecool1029 10mo ago
  Had their hands full getting sued the same day: https://news.ycombinator.com/item?id=46403128 https://news.ycombinator.com/item?id=46403128
- theteapot 10mo ago
  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" }
bethekidyouwant 10mo ago
Who has mongo open to the internet?
- matt3210 10mo ago
  Ubisoft does
  - deleted 10mo ago
    [deleted]
- ctxc 10mo ago
  Acc to a comment I read elsewhere, it's in the thousands (shodan result)
- Culonavirus 10mo ago
  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
- reassess_blind 10mo ago
  Many people who use MongoDB Atlas (or other hosted MongoDB services) alongside a PaaS like Heroku that doesn’t offer static IPs or ranges.
macintux 10mo ago
1 day ago, 116 comments: https://news.ycombinator.com/item?id=46414475 https://news.ycombinator.com/item?id=46414475
freakynit 10mo ago
Gemini generated explanation and simulation of MongoBleed: https://gemini.google.com/share/3529c5bb7d38 https://gemini.google.com/share/3529c5bb7d38 Reference: https://bigdata.2minutestreaming.com/p/mongobleed-explained-simply https://bigdata.2minutestreaming.com/p/mongobleed-explained-...
vivzkestrel 10mo ago
if you are using mongodb in 2026 you deserve everything headed in your direction
- cyberpunk 10mo ago
  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.
  - wood_spirit 10mo ago
    Genuinely interested: what problems does mongo fit better than mainstream competitors these days? Why would you use it on a new project?
    - cyberpunk 10mo ago
      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.
kryogen1c 10mo ago
>proactive [...] security program 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.
- notepad0x90 10mo ago
  > 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.
empressplay 10mo ago
[flagged]
cpursley 10mo ago
Obligatory ("Postgres is Enough"): https://gist.github.com/cpursley/c8fb81fe8a7e5df038158bdfe0f06dbb https://gist.github.com/cpursley/c8fb81fe8a7e5df038158bdfe0f...
wackget 10mo ago
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.

109 points by plorkyeran 10mo ago

Why did it take them 4 days between publishing a CVE for the vulnerability (Dec 19th) and posting a public patch (Dec 23rd)?

computerfan494 10mo ago
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?
- philipwhiuk 10mo ago
  Posting the CVE and then the patch is the reverse of this.
  - computerfan494 10mo ago
    By "patch" I am talking about the public commit. Updated binaries were made available when the CVE was published.
    - philipwhiuk 10mo ago
      That's not what the blog post implies given they only told people how to update aftwards.
cebert 10mo ago
In the US, the last two weeks of December can be slow due to the holiday season. I wouldn’t be surprised if Mongo wasn’t as staffed as usual.
- tanduv 10mo ago
  should've spun up a few more AI agents
joecool1029 10mo ago
Had their hands full getting sued the same day: https://news.ycombinator.com/item?id=46403128 https://news.ycombinator.com/item?id=46403128
theteapot 10mo ago
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" }

bethekidyouwant 10mo ago

Who has mongo open to the internet?

matt3210 10mo ago
Ubisoft does
- deleted 10mo ago
  [deleted]
ctxc 10mo ago
Acc to a comment I read elsewhere, it's in the thousands (shodan result)
Culonavirus 10mo ago
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
reassess_blind 10mo ago
Many people who use MongoDB Atlas (or other hosted MongoDB services) alongside a PaaS like Heroku that doesn’t offer static IPs or ranges.

macintux 10mo ago

1 day ago, 116 comments: https://news.ycombinator.com/item?id=46414475 https://news.ycombinator.com/item?id=46414475

freakynit 10mo ago

Gemini generated explanation and simulation of MongoBleed: https://gemini.google.com/share/3529c5bb7d38 https://gemini.google.com/share/3529c5bb7d38 Reference: https://bigdata.2minutestreaming.com/p/mongobleed-explained-simply https://bigdata.2minutestreaming.com/p/mongobleed-explained-...

vivzkestrel 10mo ago

if you are using mongodb in 2026 you deserve everything headed in your direction

cyberpunk 10mo ago
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.
- wood_spirit 10mo ago
  Genuinely interested: what problems does mongo fit better than mainstream competitors these days? Why would you use it on a new project?
  - cyberpunk 10mo ago
    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.

kryogen1c 10mo ago

>proactive [...] security program 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.

notepad0x90 10mo ago
> 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.

empressplay 10mo ago

[flagged]

cpursley 10mo ago

Obligatory ("Postgres is Enough"): https://gist.github.com/cpursley/c8fb81fe8a7e5df038158bdfe0f06dbb https://gist.github.com/cpursley/c8fb81fe8a7e5df038158bdfe0f...

wackget 10mo ago

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.