What a database port is
Every service running on a server listens on a specific port — a numbered channel for incoming connections. Web servers listen on port 80 (HTTP) and 443 (HTTPS). Email servers listen on port 25. Database servers listen on their own ports:
- MySQL: port 3306
- PostgreSQL: port 5432
- MongoDB: port 27017
- Redis: port 6379
- Microsoft SQL Server: port 1433
- Oracle: port 1521
These ports are how applications communicate with their databases. A web application running on a server sends queries to a database listening on the same server — or on a separate database server on the same internal network — through these ports.
What "exposed" means
A database port is exposed when it is accessible from the public internet. Instead of only being reachable from the application server or from inside the network, anyone on the internet can attempt to connect to it directly.
This is almost never intentional. It happens because:
- A database was set up with a public IP without restricting access at the firewall
- A firewall rule was misconfigured or accidentally removed
- A cloud database instance was provisioned with default settings that allow public access
- A developer opened the port temporarily for debugging and forgot to close it
When a database port is publicly exposed, it is visible to automated scanners within minutes. Shodan, one of the most commonly used internet scanning tools, continuously indexes exposed ports and makes them searchable. An attacker can find every publicly accessible MySQL instance in a specific city in seconds.
Why this is a critical finding
A database contains your data. Customer records, employee information, financial transactions, health records, legal documents — all of it, in a directly queryable form.
When a database port is exposed to the internet, an attacker can attempt to authenticate to it directly. The attack approaches include:
Brute force and credential stuffing
Database software often has default credentials that many administrators never change. root with no password or a simple default password is not unusual. Automated tools try thousands of credential combinations per minute. A weak or default password on a publicly exposed database is typically compromised within hours of exposure.
Unauthenticated access
Some database configurations, particularly older versions of MongoDB and Redis, were designed to operate without authentication in trusted network environments. When exposed to the internet, they require no password at all. In 2017, tens of thousands of MongoDB databases were wiped and held for ransom — the attacker just connected and deleted the data.
Exploitation of CVEs
Database software has vulnerabilities like any other software. An exposed database running an outdated version may be exploitable without any credentials at all. Some CVEs allow unauthenticated remote code execution on the database server.
The blast radius of a database breach
If an attacker gains access to your database, the consequences extend beyond the data itself:
- All records in the database are accessible and can be exfiltrated
- If the database stores password hashes, those can be cracked offline to compromise user accounts
- The database server itself may be used as a pivot point to reach other internal systems
- Regulators require notification when personal data is exposed — triggering GDPR, CCPA, HIPAA, or state breach notification requirements depending on the data involved
How to check if your databases are exposed
From outside your network (or using a service like Shodan), check whether your public IP addresses have database ports open:
nmap -p 3306,5432,27017,6379,1433,1521 your.public.ip.address
If any of these ports show as open, they are accessible from the internet.
How to fix it
Firewall rules
Database ports should be blocked at the firewall for all external traffic. The database should only be reachable from the specific application servers that need to query it, on specific internal IP addresses.
In a cloud environment (AWS, Azure, GCP), this means security groups or network security groups that restrict database port access to specific internal resources only.
Bind to localhost
For databases running on the same server as the application, the database can be configured to only accept connections from localhost — the server itself — rather than any network interface. In MySQL, this is configured with bind-address = 127.0.0.1 in the configuration file.
Private networking
In multi-server setups, databases should be on a private subnet with no public IP and no route from the internet. Only the application tier can reach the database tier, and only through specific ports.
Authentication
Regardless of network controls, database authentication should be enabled with strong, unique passwords. Never use default credentials. Disable anonymous access if it exists.
Run a free external vulnerability scan at kasperashield.com to check whether any database ports are visible from the internet on your infrastructure.
