No, exposing Port 3306 (MySQL) to the internet is generally unsafe because databases are heavily probed for weak credentials and misconfiguration. Attackers use exposed services for brute force, data theft, and lateral movement. Restrict access to trusted hosts, use strong authentication and encryption, and alert on connection spikes and repeated failures.
Why exposing MySQL on 3306 changes the attack surface
Port 3306 is not inherently dangerous because it exists, it becomes dangerous when it is reachable from untrusted networks. A database listener exposed to the internet is easy to discover, easy to enumerate, and often targeted long before defenders notice. That shifts the problem from “can someone reach the service?” to “can they authenticate, extract data, or abuse the database as an internal foothold?”
When MySQL is internet-facing, the exposure is rarely limited to the database itself. The real concern is the account material behind it, the trust granted to clients, and the blast radius if credentials are weak, reused, or left broadly permitted. Even a well-configured database still benefits from network restriction because limiting who can connect materially reduces probe volume and attack opportunity.
Exposed database ports also create operational noise. Connection spikes, repeated failures, and aggressive banner-grabbing are often early indicators that a service has become visible to the public Internet. That visibility matters because brute-force attempts, password spraying, and opportunistic exploitation all scale quickly against services that are left open without compensating controls.
For a practical security guide to risky ports and why exposed services are routinely targeted, see Network Ports and Protocols Security Guide. It is especially relevant here because the question is not just about MySQL, but about the security consequences of making a common database port publicly reachable.
What attackers actually do when they find an open database port
Attackers usually start with the cheapest path: probe for an exposed service, test default or weak credentials, and look for an account that can read, write, or administer far more than it should. If the login succeeds, the next step may be data theft, schema tampering, privilege escalation inside the database, or pivoting to hosts the database can reach on the internal network.
The risk increases when the database account is shared, long-lived, or reused across environments. In that case, a single exposed endpoint can become a reusable access path rather than a one-off mistake. If the server also trusts wide network ranges, attackers may use the database as a stepping stone into application servers, backup systems, or adjacent services that were never meant to be directly reachable from outside.
For readers who want a broader view of how exposed services and stolen credentials are used in real breaches, The State of NHI & AI Agent Breach Report 2026 is a useful companion. It reinforces the pattern that exposed secrets and overly permissive service access are often the enabling condition, not the headline incident.
That is why the safest assumption is that any internet-exposed database port will be scanned, challenged, and eventually abused unless there is a strong reason for public access and layered compensating control.
How to reduce exposure without breaking legitimate access
The first control is network scope, not authentication tuning. Allow only the hosts, subnets, VPN ranges, or private connectivity paths that truly need database access, and deny everything else by default. If remote administration or application connectivity must cross network boundaries, prefer a private link, a bastion, or a proxy layer rather than direct public exposure.
The second control is credential and protocol hygiene. Use strong, unique database credentials, remove anonymous or unused accounts, enforce encryption in transit, and review which accounts can connect from which hosts. Where possible, separate administrative access from application access so that a compromised app credential cannot automatically become a full database administration path.
The third control is detection. Alert on repeated login failures, unusual source geographies, new client fingerprints, and sudden connection volume changes. Those signals are valuable because internet-facing database attacks often begin quietly, and early authentication failure patterns can be the first evidence that someone is probing for a weak entry point.
For the protocol and exposure side of the decision, the IANA registry is the canonical place to verify port assignments, while NCSC UK Advice and Guidance provides practical guidance on reducing exposure from remote access and externally reachable services.
Risk and Threat Considerations
An exposed MySQL service is attractive because it concentrates high-value data behind a simple network entry point. The main risk is not merely brute force, but the combination of discoverability, weak credential reuse, and the possibility that one successful login exposes sensitive data or a path deeper into the environment.
Failure mechanism: Public reachability lets attackers enumerate the service, automate password attacks, and test for weak authorization or overbroad host permissions until they find a usable account or misconfiguration.
Impact: A successful compromise can lead to data theft, tampering, unauthorized administrative actions, or lateral movement into systems that trust the database host or its credentials.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
OWASP Non-Human Identity Top 10 and MITRE ATT&CK address the attack surface, CIS Controls v8 and NIST SP 800-53 Rev 5 set the technical controls, and ISO/IEC 27001:2022 defines the regulatory obligations.
| Framework | Control / Reference | Relevance |
|---|---|---|
| CIS Controls v8 | CIS-5 — Account Management | Restricts exposed database access to authorized accounts and sources. |
| Recommendation — Review and remove unnecessary database accounts and access paths. | ||
| NIST SP 800-53 Rev 5 | IA-5 — Authenticator Management | MySQL exposure elevates the importance of strong credential lifecycle controls. |
| AC-4 — Information Flow Enforcement | Internet-facing 3306 needs network allowlisting and controlled connection paths. | |
| Recommendation — Enforce strong database credential lifecycle and rotate exposed secrets promptly. Constrain database traffic to approved network flows and source hosts. | ||
| ISO/IEC 27001:2022 | A.8.20 — Network security | Publicly reachable database ports require controlled network exposure and segmentation. |
| Recommendation — Segment database access and block unnecessary public exposure. | ||
| OWASP Non-Human Identity Top 10 | NHI-05 — Overprivileged NHI | Database accounts often become overbroad when exposed services are left public. |
| Recommendation — Reduce database account privilege to the minimum needed for each use case. | ||
| MITRE ATT&CK | T1110 — Brute Force | Exposed MySQL is commonly targeted with automated login attacks. |
| Recommendation — Detect and rate-limit repeated authentication failures against database services. | ||
Practitioner Guidance
What to verify: Confirm whether MySQL truly needs internet reachability at all. If the answer is no, close the port and move access behind private networking, VPN, or a controlled jump path. If the answer is yes, verify that only explicit source addresses can connect and that the exposed service is monitored as an externally facing asset.
Common mistake: Treating “we use strong passwords” as sufficient. Strong credentials help, but they do not remove scan volume, reduce exploit attempts, or eliminate the risk created by a public database listener. Network restriction and account hardening need to work together.
What practitioners underestimate: The blast radius is often larger than the database itself. A compromised database account may reveal data, credentials, application secrets, or trusted internal connections that turn a simple exposed port into a broader incident.
Practitioner takeaway: If MySQL does not have a hard business requirement for public exposure, do not expose it. If it must be reachable, treat port 3306 as an externally attackable service and require tight network allowlisting, strong authentication, encryption, and active alerting before you call it acceptable.