Port 33060 – mysqlx (MySQL X Protocol / X DevAPI)

Port 33060 is the default TCP port for the MySQL X Protocol (mysqlx) — the newer, Protocol-Buffers-based wire protocol that MySQL introduced in 5.7.12 and made standard in 8.0. It’s served by the server-side X Plugin and spoken by the X DevAPI, MySQL Shell (mysqlsh), and the newer language connectors, giving both SQL and NoSQL-style “document store” access to the same database. The key thing to understand is that 33060 runs alongside the classic MySQL protocol on port 3306: same server, same accounts, same data — just a second network door. That distinction matters, because an exposed 33060 is another route into the MySQL instance that firewall rules routinely miss. Admins lock down 3306 and forget 33060 exists.

Why It’s Open

The X Plugin ships enabled in a default MySQL 8.0 install, so mysqld listens on 33060 out of the box the moment you start the server — you don’t have to opt in. It’s there to serve MySQL Shell’s modern JavaScript/Python modes, the X DevAPI document store (collections of JSON documents accessed CRUD-style, MongoDB-fashion), and connectors like Connector/J, Connector/Node.js, and Connector/Python when they use X Protocol connections. In a healthy design the database — both protocols — sits on a private network or localhost and never faces untrusted networks. Port 33060 becomes a finding when it’s bound to 0.0.0.0/* and reachable from outside, which happens more often than it should because the X Protocol’s bind address is configured separately from the classic one (mysqlx-bind-address vs bind-address), so hardening only the classic port leaves 33060 wide open. Where you see 33060, MySQL on 3306 is almost always the same host — and its database peers are worth a look too: MongoDB on 27017 and PostgreSQL on 5432, plus the other big relational engines Microsoft SQL Server on 1433 and Oracle on 1521.

Common Risks

• A second, forgotten door to the same database. This is the headline risk. Port 33060 reaches the exact same MySQL server, accounts, schemas, and data as 3306. Firewall rules, security groups, and “bind to localhost” changes that only cover 3306 leave 33060 exposed — an attacker who can’t reach the classic port simply connects to the X Protocol port instead and authenticates with the same credentials.
• Inherited MySQL auth weaknesses. X Protocol authentication uses the same MySQL account store, so a blank, default, or weak root password, anonymous accounts, and over-broad user@'%' grants are just as exploitable here as on 3306. Get in on 33060 and you have the same query surface — including file read/write and UDF escalation paths — as any classic connection.
• Exposed to the internet. A database was never meant to face the public network on either port. Once 33060 is reachable it’s subject to the same automated credential-stuffing and mass-ransomware sweeps that hit 3306.
• Version fingerprinting. An open 33060 confirms MySQL 5.7.12+/8.0 and, once you connect, discloses the exact server version — narrowing which classic-MySQL and X-Plugin bugs to try.
• X Plugin denial of service. The X Plugin has its own history of DoS bugs (see CVEs below) that hang or crash mysqld — taking the whole database offline, not just the X interface.
• Weak transport if TLS isn’t enforced. As the Ubuntu maintainers put it, the X Protocol offers “effectively the same capabilities as the classic MySQL protocol” but with a weak authentication method that leans on the encrypted channel — if TLS isn’t required, credentials and query data are exposed on the wire.

Want to save time on reporting?

Let PentestPad generate, track, and export your reports - automatically.

Book a Demo

Enumeration & Testing

The X Protocol is not the classic MySQL handshake. It’s a length-prefixed, Protocol-Buffers (protobuf) message protocol, and — unlike classic MySQL, which pushes a version-carrying greeting the instant you connect — the X Plugin waits for the client to speak first. A raw nc connect won’t hand you a banner, so use a version scan and a real X Protocol client.

Detect the service and version

nmap -sV -p 33060 <target>

Nmap’s service probe fingerprints this port as mysqlx (MySQL X protocol) and reports the server version when it can — the reliable way to confirm what’s listening, since a plain banner grab comes back empty.

Confirm both database doors on one host

nmap -sV -p 3306,33060 <target>

Scanning the classic and X ports together shows whether an admin closed 3306 but left 33060 open — the exact gap this port is known for.

Connect with MySQL Shell (the native X Protocol client)

# X Protocol session via URI scheme
mysqlsh mysqlx://root@<target>:33060

# Equivalent explicit form
mysqlsh --mysqlx --host=<target> --port=33060 --user=root

Once connected, MySQL Shell speaks both SQL and the document-store API against the same instance:

\sql
SELECT version();
SELECT user, host FROM mysql.user;
SHOW DATABASES;
SHOW GRANTS;

Test credentials — brute-force via the classic port

Because both ports share one account store, the practical credential attack runs against the classic protocol on 3306, where the mature tooling lives, and any working login is equally valid on 33060:

hydra -L users.txt -P passwords.txt mysql://<target>

msfconsole -q
use auxiliary/scanner/mysql/mysql_login
set RHOSTS <target>
set USER_FILE users.txt
set PASS_FILE passwords.txt
run

Note these Metasploit and Hydra modules speak the classic MySQL protocol (3306); there is no separate X-Protocol brute-force module, and none is needed — the credentials are the same. Log every open 33060, the confirmed server version, and any credential that works so the evidence lands in the pentest report instead of a scratch terminal you’ll lose.

What to Look For

Known CVEs and Exploits

There is no dramatic pre-authentication “port 33060” remote-code-execution bug — and the honest headline here is a design risk, not a CVE: 33060 is a second network path to the same database people forget to firewall. That said, the server-side X Plugin has had a handful of real, correctly-scoped vulnerabilities, and they are almost all Oracle Critical Patch Update denial-of-service entries that hang or crash mysqld:

• CVE-2020-14870 — MySQL Server, component Server: X Plugin. A high-privileged, authenticated attacker with network access can trigger a hang or repeatable crash (complete DoS) of the server. Affects MySQL 8.0.21 and prior. CVSS 3.1 4.9 (availability only).
• CVE-2017-3637 — MySQL Server, subcomponent X Plugin. A low-privileged attacker can cause a complete DoS of MySQL Server (difficult to exploit). Affects MySQL 5.7.18 and earlier. CVSS 3.0 5.3 (availability only).
• CVE-2017-3646 — MySQL Server, subcomponent X Plugin. A high-privileged attacker can cause a complete DoS of MySQL Server. Affects MySQL 5.7.16 and earlier. CVSS 3.0 4.9 (availability only).

Every one of these requires an authenticated session, so they matter most once weak credentials or exposure have already let an attacker in — which loops back to the real point: keep the port off untrusted networks and the accounts strong. The genuine query-level and privilege-escalation power of a MySQL session (file read/write via LOAD_FILE/INTO OUTFILE, UDF command execution, the CVE-2016-6662 malloc_lib RCE) applies identically whether you connected on 3306 or 33060 — see the MySQL port 3306 page for that toolkit.

The previous version of this page listed CVE-2021-2356, CVE-2020-2922, CVE-2019-2910, and CVE-2022-21412 as X Protocol/X Plugin flaws. Every one was mislabeled: verified against NVD, CVE-2021-2356 is a Server: Replication bug, CVE-2020-2922 affects the MySQL Client C API, CVE-2019-2910 is a Server: Security: Encryption info-leak, and CVE-2022-21412 is a Server: Optimizer DoS — none touch the X Plugin, and none was the “authentication bypass” or “RCE” the old page claimed. They have been removed and replaced with the three CVEs whose NVD records actually name the X Plugin subcomponent.

Mitigation

• Firewall 33060 exactly like you firewall 3306 — and check both. The single most important step. Whatever restricts the classic port (security groups, iptables, cloud firewall rules) must cover the X Protocol port too. Audit for an accidental 0.0.0.0:33060 / *:33060.
• Bind the X Protocol to localhost/internal explicitly. bind-address does not govern the X Plugin — set mysqlx-bind-address = 127.0.0.1 (or your internal address) in my.cnf separately, or disable the plugin entirely with mysqlx=0 / --skip-mysqlx if nothing uses the X DevAPI.
• Harden the accounts once — it protects both ports. Set a strong root password, remove anonymous accounts, tighten user@'%' grants, and give each app a least-privilege user. Because 33060 and 3306 share the account store, this closes the door on both.
• Require TLS. Enforce encrypted connections so the X Protocol’s credentials and query data aren’t sniffable.
• Patch. Keep MySQL current so the X Plugin DoS bugs (2017-3637, 2017-3646, 2020-14870) and the classic-protocol RCE/escalation bugs are all closed.
• Rescan to confirm. After changes, run nmap -p 3306,33060 <target> and verify both ports are closed to untrusted networks — not just the one you remembered.

Real-World Example

The clearest illustration of the “forgotten second door” is a real packaging bug in Ubuntu’s MySQL 8.0 (Launchpad bug #1857584). Ubuntu’s config shipped bind-address = 127.0.0.1 so the classic protocol on 3306 was safely restricted to localhost — the secure-by-default behaviour administrators expected. But mysqlx-bind-address was left at its upstream default of *, so the X Protocol listened on *:33060 across every network interface, including the internet-facing one. Anyone who reviewed the config, saw 3306 bound to localhost, and assumed the database was locked down was wrong: the exact same server, accounts, and data were reachable on 33060 from the outside. The maintainers classified it as contradicting the “secure by default” policy and fixed it in 8.0.22-0ubuntu0.20.04.3 by explicitly binding the X port to 127.0.0.1. No exploit and no CVE — just a second protocol on a second port that the obvious hardening step didn’t cover. That is the entire risk of port 33060 in one bug report.

FAQ

What is port 33060 used for?

Port 33060 is the default TCP port for the MySQL X Protocol (mysqlx) — the newer, Protocol-Buffers-based protocol introduced in MySQL 5.7.12 and standard in 8.0. It’s used by MySQL Shell (mysqlsh), the X DevAPI, and the document-store (NoSQL-style) interface, and it runs alongside the classic MySQL protocol on 3306, reaching the same database.

What’s the difference between port 3306 and port 33060?

Port 3306 is the classic MySQL protocol used by almost every traditional client and application. Port 33060 is the X Protocol — a different, protobuf-based wire format used by MySQL Shell and X DevAPI/document-store clients. They front the same server, accounts, and data; 33060 is simply a second, more modern way in. Securing one does not secure the other.

Is it dangerous to leave port 33060 open?

Yes, when it faces an untrusted network. It’s a full network path into your MySQL server with the same credentials and query power as 3306 — subject to the same brute-forcing and ransomware sweeps. Its biggest danger is being overlooked: teams firewall 3306 and forget 33060 exists. Keep it off the public internet and firewall it to trusted clients only.

Why is port 33060 open when I only configured MySQL on 3306?

Because the X Plugin is enabled by default in MySQL 8.0, so mysqld starts listening on 33060 automatically. Its listen address is controlled by mysqlx-bind-address, which is separate from bind-address — so restricting the classic port doesn’t move the X port. Set mysqlx-bind-address = 127.0.0.1, or disable the plugin with mysqlx=0 if you don’t use the X DevAPI.

How do I test what’s running on port 33060?

Run nmap -sV -p 33060 <target> — nmap fingerprints it as mysqlx and reports the server version (a raw banner grab returns nothing, because the X Protocol waits for the client to speak first). To connect, use MySQL Shell: mysqlsh mysqlx://root@<target>:33060. Scan 3306,33060 together to see if the classic port was locked down while the X port was left open.

Does port 33060 have its own exploits?

There’s no signature pre-auth RCE for the X Protocol itself. The X Plugin has had authenticated denial-of-service CVEs (CVE-2020-14870, CVE-2017-3637, CVE-2017-3646) that crash mysqld, but the real risk is design-level: it’s a second door to the same database, and any query-level attack that works over 3306 works identically here once you’re authenticated.

TL;DR

• Service: MySQL X Protocol (mysqlx) — the X Plugin, X DevAPI, and MySQL Shell document-store/NoSQL interface
• Default port: 33060/TCP (runs alongside the classic MySQL protocol on 3306)
• Biggest risk: a second, often-forgotten network door to the same MySQL server, accounts, and data — firewall rules that lock down 3306 frequently leave 33060 exposed, with the same weak/default credentials
• Mitigation: firewall 33060 exactly like 3306, set mysqlx-bind-address = 127.0.0.1 (it’s separate from bind-address) or disable the plugin, use strong least-privilege accounts, require TLS, patch, and rescan both ports to confirm