Exposed Database Ports: How Attackers Find Your Data

The Scale of the Problem

Exposed databases are not an edge case. Security researchers routinely find hundreds of thousands of database instances directly reachable from the internet, with no authentication barrier between the open internet and sensitive data. The Shadowserver Foundation alone tracks over 400,000 exposed database services on any given day.

The consequences are real and immediate. In January 2026, the DeepSeek AI breach exposed over a million log entries — including API keys, chat histories, and backend metadata — through an exposed ClickHouse instance that required no authentication. The database was discoverable through a routine port scan. There was no exploit, no sophisticated attack chain, and no zero-day. Just an open port with no password.

The pattern repeats across industries. Healthcare organizations expose patient records through unprotected Elasticsearch clusters. SaaS companies leak customer data through misconfigured MongoDB instances. Retailers lose payment card data through Redis caches that accept connections from anywhere. The root cause is almost always the same: a database that was never meant to be internet-facing quietly became reachable due to a configuration gap.

How Databases Get Exposed

Database exposure rarely happens because someone intentionally publishes a database to the internet. It happens through a series of small, reasonable-seeming decisions that compound into a critical gap.

Default Bind to 0.0.0.0

Many database systems ship with a default configuration that listens on all network interfaces. When bind_address or its equivalent is set to 0.0.0.0, the database accepts connections from any IP address that can reach the host — including the public internet if no firewall intervenes. MongoDB versions before 6.0, Redis, and Elasticsearch all defaulted to this behavior. Developers install the database, it works, and nobody checks what interfaces it is bound to.

Cloud Security Group Misconfiguration

In cloud environments, the network perimeter is defined by security groups and network ACLs rather than physical firewalls. A single rule change — allowing inbound traffic on port 27017 from0.0.0.0/0 instead of a specific CIDR block — exposes the database globally. This happens during debugging ("let me just open it temporarily"), during migration, or because a Terraform template uses overly permissive defaults. The "temporary" rule stays forever.

Docker and Container Networking Gaps

Docker publishes ports to 0.0.0.0 by default when you use the -p flag. Running docker run -p 27017:27017 mongo binds the container's MongoDB port to every interface on the host, including any public-facing interfaces. If the host has a public IP — common on cloud VMs — the database is now internet-accessible. Docker's port publishing also bypasses iptables rules on Linux, meaning host-level firewall rules may not protect you.

"Temporary" Dev/Test Instances That Persist

A developer spins up a database for testing. They skip authentication because it is just for development. They assign a public IP because it is easier than setting up VPN access. The test finishes, but nobody decommissions the instance. Weeks later, the database still sits on the internet — now containing production data that was copied for a debugging session. These forgotten instances are among the most commonly exploited because they have the weakest controls and the least monitoring.

Database-Specific Exposure Patterns

Each database system has its own default security posture, authentication model, and risk profile when exposed. The following table summarizes the key differences.

MongoDB (Port 27017)

MongoDB versions prior to 6.0 shipped with authentication disabled by default. Any client that could reach port 27017 could list databases, read collections, and modify or delete data without credentials. Even after MongoDB 6.0 introduced default authentication, many existing deployments were never upgraded. Attackers use the mongo shell or simple scripts to connect, run show dbs, and enumerate every collection. Ransomware groups specifically target exposed MongoDB instances — they copy the data, drop all collections, and leave a ransom note in a new collection.

Redis (Port 6379)

Redis has no authentication enabled by default. It is designed as an in-memory data store for trusted networks, not for internet exposure. The risk goes beyond data theft: Redis accepts arbitrary commands, and attackers use the CONFIG SET and SAVEcommands to write arbitrary files to the server's filesystem. This technique — known as Redis unauthorized access — lets attackers write SSH keys to /root/.ssh/authorized_keys or write cron jobs to gain full shell access. An exposed Redis port is not just a data leak — it is often a direct path to full server compromise.

Elasticsearch (Port 9200)

Elasticsearch versions prior to 8.0 had no built-in security features enabled by default. The REST API on port 9200 allows anyone to list all indices with GET /_cat/indices, read every document with GET /index_name/_search, and even delete data. Because Elasticsearch is commonly used for logging, analytics, and user data, exposed clusters often contain highly sensitive information — application logs with PII, authentication tokens, and full-text search indices over customer data.

PostgreSQL (Port 5432)

PostgreSQL requires authentication by default, but the pg_hba.conf file controls who is required to authenticate and how. A common misconfiguration is setting the authentication method to trust for all connections, which allows any user to connect without a password. This often happens when developers configure trust for local connections but accidentally apply it to remote connections as well. Combined with a defaultpostgres superuser account, this grants full database access.

MySQL/MariaDB (Port 3306)

MySQL and MariaDB require passwords by default, but older installations, automated deployment scripts, and container images frequently configure the root account with an empty password. When combined with a bind-address of 0.0.0.0 and a permissive firewall, attackers can connect as root with no credentials. Even when root has a password, weak or default credentials are commonly found through brute force.

How Attackers Find Exposed Databases

Search Engine Indexing (Shodan, Censys)

Shodan and Censys continuously index the entire internet, cataloging every open port and the service banners behind them. A search for product:MongoDB on Shodan returns tens of thousands of results, complete with version numbers and authentication status. Censys provides similar data with more detailed TLS and protocol analysis. Attackers — and security researchers — can find every exposed MongoDB, Redis, or Elasticsearch instance in seconds with a single query. These platforms update their indices daily, so new exposures appear quickly.

Mass Port Scanning (masscan, zmap)

Tools like masscan and zmap can scan the entire IPv4 address space for a specific port in under 10 minutes. An attacker targeting exposed Redis instances runs a single command scanning port 6379 across all 4.3 billion addresses, then follows up with banner grabs on every host that responds. This is trivially cheap to do from a cloud VM and requires no special access or expertise. Botnets distribute this scanning across thousands of nodes for even faster coverage.

Banner Grabbing and Service Fingerprinting

Once a port is found open, attackers send protocol-specific probes to identify the exact service and version. MongoDB responds to a connection with a server status document. Redis responds to a PING with PONG and provides version information via the INFOcommand. Elasticsearch returns a JSON document with cluster name, version, and build details. This fingerprinting takes milliseconds per target and confirms whether the database requires authentication.

Automated Exploitation

After discovery, exploitation is automated. Scripts connect to each exposed instance, attempt authentication (or skip it when none is required), enumerate the data, and either exfiltrate it or deploy ransomware. The entire chain from discovery to data theft can be completed without human intervention. Criminal groups operate these pipelines continuously, processing newly discovered databases within hours.

Immediate Response: Exposed Database Found

If you discover a database exposed to the internet, follow these four containment steps immediately. Speed matters — every hour the database remains exposed increases the likelihood that an attacker has already accessed it.

Prevention Controls

Containment addresses the immediate exposure. Prevention stops it from happening again. Effective prevention requires controls at multiple layers — network, authentication, and monitoring.

Network Segmentation

• Private subnets only: Deploy databases in private subnets with no public IP addresses. Application servers access them via private networking.
• Explicit allow-lists: Security groups should allow database port access only from specific application server IPs or security groups, never from 0.0.0.0/0.
• No public IPs on database hosts: If a server does not need to be reached from the internet, it should not have a public IP address assigned.
• Docker bind to localhost: When running databases in Docker, always bind to 127.0.0.1 explicitly: -p 127.0.0.1:27017:27017 instead of -p 27017:27017.

Authentication Enforcement

• Enable auth on every instance: MongoDB: --auth flag or security.authorization: enabled. Redis: requirepass directive. Elasticsearch: enable the security module.
• No default credentials: Change or disable default accounts. Never deploy with empty passwords or well-known defaults.
• Use TLS: Encrypt database connections in transit. This prevents credential interception and confirms server identity.
• Least privilege: Application accounts should have only the permissions they need — read-only access to specific databases, not superuser.

Monitoring and Detection

• External port scanning: Regularly scan your public IP ranges for database ports (27017, 6379, 9200, 5432, 3306). Automate this as part of attack surface monitoring.
• Configuration drift detection: Alert when security group rules change to allow database ports from the internet. Infrastructure-as-code scanning (e.g., Checkov, tfsec) can catch this before deployment.
• Database audit logging: Enable and centralize database authentication logs. Alert on failed authentication spikes and connections from unexpected source IPs.
• Cloud security posture: Use cloud provider tools (AWS Config Rules, Azure Policy, GCP Organization Policies) to enforce that database services cannot have public endpoints.

Database Exposure Checklist

Use this checklist to audit your environment for exposed database ports. Run through it quarterly or after any infrastructure change.

How DriftAlarm Detects Exposed Database Ports

DriftAlarm's attack surface monitoring platform continuously scans your external perimeter for exposed database ports and other dangerous services. Here is how detection works:

• Port discovery: Automated scans of your registered IP ranges and domains detect open database ports (27017, 6379, 9200, 5432, 3306, and others) from an external perspective — the same view an attacker has.
• Service fingerprinting: When a database port is found open, DriftAlarm identifies the specific database service and version through banner analysis, so you know exactly what is exposed.
• Drift alerts: If a database port was closed yesterday and is open today, DriftAlarm triggers a drift alert immediately. This catches configuration changes, new deployments, and accidental exposures within hours instead of weeks.
• Severity classification: Exposed database ports are automatically classified as high or critical severity findings based on the database type, authentication status, and version information.

Manual port scans catch exposures at a point in time. Continuous monitoring catches them as they happen — before attackers complete their own scans.

Related Security Guides

Exposed database ports are often found alongside other attack surface issues. Review these related guides:

• Configuration Drift Guide — How infrastructure changes silently expand your attack surface, including security group modifications that expose database ports.
• Exposed RDP Guide — RDP (port 3389) exposure follows the same discovery and exploitation patterns as exposed databases and requires the same urgency.
• Exposed SSH Guide — SSH (port 22) with password authentication is a P1 finding that often coexists with exposed database ports on the same hosts.
• Exposed Admin Panels Guide — Database management interfaces like phpMyAdmin, Mongo Express, and Kibana are admin panels that grant database access through the browser.
• Cloud Storage Exposure Guide — Misconfigured cloud storage follows the same pattern of default-open configurations leading to data exposure.
• IP Range Monitoring — Continuous monitoring of your IP ranges for exposed services, including database ports.

Continuous Port Monitoring

Stop finding exposed databases after attackers do. DriftAlarm monitors your external attack surface continuously and alerts you within hours when a database port becomes reachable from the internet.