Its default is to only take connections that are local, usually I have my mongo clients SSH into a mongo server as opposed to opening up the port to the internet. Some Mongo users / collections are very open by default.

It has been a minute since I used Mongo for production grade projects, so some things could have changed since then.

No, but it's pretty common IME to create an Atlas cluster that has internet-wide access (0.0.0.0/0) when testing and forgetting to turn this off. According to https://jira.mongodb.org/browse/SERVER-115508, this affects unauthenticated ops. Based on the repro code itself, it looks like this happens way before authentication is checked for the corresponding OP at the OP_MSG decoding level.

So if you're using Atlas, check that your Cluster has auto upgraded already. If you're using 0.0.0.0/0, stop doing that and prefer a limited IP address range and even better, use VPC Peering or other security/network boundary features.

When vulnerability description says “unauthenticated exploit” that means that you can exploit without being required to authenticate first. It means it just works even with authentication being required on the server.

When it says “authenticated exploit” it means you need to pass authentication first in order to trigger exploit whatever it may be.

> authenticated access to the cluster

No it doesn’t.

> they'd use snappy or zstd

What is being used more doesn’t matter, what’s compiled in and enabled matters.

Incorrect, the company patched 4.4 on 12/19/25 with a special 4.4.30 release:

https://www.mongodb.com/docs/v4.4/release-notes/4.4/#4.4.30-...