> 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.

>>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.

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"
    }

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.

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?

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

Ubisoft does

Acc to a comment I read elsewhere, it's in the thousands (shodan result)