An open Atlas access list turns one leaked key into a full dump

MongoDB Atlas guards a cluster with two controls: who the credential is and where it can connect from. When both fail at once, one leaked key reads the whole cluster.

How the attack works

During a migration the Atlas IP access list was widened to allow connections from anywhere and never tightened. An application’s database user credential then leaks from a config file. The attacker connects from outside the app’s egress range, enumerates databases and collections beyond the app’s own, and runs large sequential find queries across collections holding customer data and stored credentials, staging the documents out to an external host. A broad project API key in the same blast radius could also alter access controls. In ATT&CK terms this is T1078, Valid Accounts, paired with T1530, Data from Cloud Storage.

Why it works

Two settings combined: an access list open to the world and a database user whose role granted read across all databases, not just the app’s own. Either alone is bad. Together they turn a single leaked credential into an unrestricted export path.

How to fix it

The scenario teaches that you must close two layers, not one. Tighten the IP access list back to the app’s egress range, or move to private networking such as peering or private endpoints, and rotate or disable the leaked database user, and rotate the project API key in case it was used to widen access. Pausing the whole cluster is an avoidable outage. For the durable fix, scope the database user’s role to its own database and store credentials in a secret manager. The Atlas database audit log and access history, filtered to the user and window, show exactly which collections were read. Any credentials that were read are a second incident: rotate every downstream secret they unlock.

Practice it

We built this as a GraphLattice Range scenario so security teams can rehearse closing both the network and the credential before a leaked database user empties a cluster.