Exposed Databases: Redis and MongoDB Open to the Internet

An exposed database is a Redis, MongoDB, Elasticsearch, or PostgreSQL instance reachable from the public internet with weak or no authentication — usually because it was bound to 0.0.0.0 instead of a private interface during a quick deployment. Internet-wide scanning tools index every open database port continuously, so an unauthenticated instance is often found within hours of going live, sometimes minutes. Attackers then either exfiltrate the data quietly or delete it and drop a ransom note demanding payment for its return. The fix is almost never a code change — it is binding to localhost or a private subnet, enabling authentication, and closing the port at the firewall.

How Databases End Up Facing the Open Internet

Nobody sets out to expose a production database. It happens through small, individually reasonable decisions that stack up badly: a developer spins up MongoDB in Docker for local testing and the container's default network mode maps the port straight through to the host; a DevOps engineer opens a Redis security group to 0.0.0.0/0 during a demo, intending to lock it down "after"; an Elasticsearch cluster for log aggregation never gets an authentication layer because the open-source distribution historically shipped without one; a PostgreSQL instance migrated from on-prem inherits a pg_hba.conf rule that was fine on a private LAN and is catastrophic on a public IP.

Found in Minutes: How Attackers Discover Exposed Databases

Discovery of exposed databases does not require a targeted attack on your company. Internet-wide scanning platforms continuously probe the entire IPv4 address space across common service ports, building searchable indexes of what is listening where. Security researchers running honeypot databases with no authentication have repeatedly observed the first unsolicited connection arriving within hours of going live — in many documented cases, within minutes — independent of whether anyone is specifically looking for that organization.

Once a scanner finds an open port running Redis, MongoDB, Elasticsearch, or PostgreSQL, automated tooling attempts a connection. If no authentication is required, or a default/weak credential works, the script can enumerate databases, collections, or tables within seconds — the database itself reveals what data is present through its own schema and sample records.

The Ransom Note Playbook

The pattern that gives this attack class its name is well documented across security research: an automated script connects to an unauthenticated database and, instead of quietly copying the data, replaces it. A new collection, table, or key is created — often named readme, warning, or recovery — stating that the original data has been copied or deleted and demanding payment, typically in cryptocurrency, for its return.

The uncomfortable detail security researchers have repeatedly documented is that payment does not reliably restore anything. In several widely reported waves of database-wiping activity, attackers destroyed the original data outright and left only the ransom message — there was never a backup on the attacker's side, because the tooling is built to delete and overwrite as fast as possible across as many targets as possible, not to preserve a copy for later extortion. The note is frequently the only thing left; the leverage it implies may not exist.

This makes the ransom note pattern a business continuity failure, not just a security incident. An organization that finds its database replaced has to answer two questions at once: is there a clean backup, and was data read or copied before it was overwritten — because if personal data was present, that triggers separate regulatory obligations regardless of whether the ransom is paid.

Which Datastores Get Hit Most

Exposure research and honeypot studies consistently find certain datastores over-represented among internet-facing, unauthenticated instances — largely a function of how each project's defaults shaped early deployment habits rather than any inherent weakness in the software. The distribution below is a qualitative pattern rather than a single cited measurement, since exact counts shift constantly as instances are found, fixed, and re-exposed.

MongoDB and Elasticsearch appear disproportionately partly because both were, for years, straightforward to run without any authentication configuration — a working cluster in minutes, without ever being prompted for a password. Redis follows the same logic: designed as a fast, trusted-network cache rather than an internet-facing service, which is why it turns up unauthenticated so often. PostgreSQL requires a password by default, part of why it appears less here, but a pg_hba.conf set to trust for a wide address range removes that protection entirely.

The Business Impact for Indian Companies

For an Indian company, an exposed database carrying personal data is not only an operational incident — it is a direct regulatory exposure event under the Digital Personal Data Protection Act, 2023. The Act places accountability on the data fiduciary for reasonable security safeguards, and a database reachable with no authentication is difficult to characterize as reasonable under that standard.

Beyond the regulatory angle, an exposed and wiped production database is a continuity event: services relying on it go down the moment the data disappears, and recovery time depends entirely on whether a clean, tested backup exists outside the compromised environment. Discovering the exposure only when the service breaks means discovering it after the data was already accessed by whoever found the open port first.

Locking It Down: The Fix

None of the controls that prevent this attack class require rewriting application code — they are configuration and network changes, typically verifiable within a single working session.

OWASP's Top 10 lists security misconfiguration as its own risk category precisely because it recurs across every stack for the same reason: a secure default gets overridden for convenience, and nobody revisits it. See OWASP's guidance for a broader checklist beyond databases, and the NIST Cybersecurity Framework for the segmentation principles that make "private subnet by default" the right starting posture.

Why Continuous Checking Catches This Before Attackers Do

A one-time review of database bindings and firewall rules tells you the state of things on the day of the review. New databases get spun up for new features, staging environments get promoted without their network settings revisited, and cloud provider defaults change over time in ways that can silently reopen a closed port. The gap between "we checked this six months ago" and "this is still true today" is where exposed-database incidents live.

Bachao.AI runs automated vulnerability assessment and penetration testing for Indian companies, including checks for internet-reachable databases and the authentication and network configuration around them, so an exposed Redis or MongoDB instance is found by a scheduled scan rather than by whoever runs the next internet-wide sweep. Where a compliance need requires CERT-In empanelled reporting, that is delivered with a CERT-In empanelled partner. Dhisattva AI Pvt Ltd built the platform around continuous checking because point-in-time audits leave this exact gap open between reviews.

If you are not certain whether any database in your environment is reachable from outside your own network, that is worth confirming directly rather than assuming your cloud provider's defaults have you covered. A free VAPT scan checks for exposed database ports and weak or missing authentication, and for DPDP-specific obligations around personal data safeguards, see the DPDP compliance overview. For more, browse our blog.