Port 9999 – Distinct (Abyss Admin Console, IoT Debug Shells, JMX & Custom Apps)

Port 9999 is a generic, round-number high port with no single dominant service — IANA registers it only as “distinct”, and in practice it’s a grab-bag. The most security-relevant occupants are the Abyss Web Server admin console (which defaults to http://host:9999), embedded and IoT debug/diagnostic shells (routers, DVRs and IP cameras that expose an unauthenticated telnet-style root shell here), the TP-Link Smart Home Protocol used by legacy Kasa plugs and bulbs, and Java JMX/RMI management endpoints. Custom and internal apps reach for 9999 too, because it’s memorable and unassigned. So the first job on an open port 9999 isn’t to attack a known protocol — it’s to work out whether you’re looking at an Abyss admin console, an embedded debug shell, a JMX/RMI endpoint, or a bespoke app, and then test that. Lead with the assumption that a debug shell or admin console here may have no authentication at all, because on this port that is common rather than rare.

Why It’s Open

There is no one reason 9999 is open — it depends entirely on what put it there:

• Abyss Web Server admin console. Aprelium’s Abyss Web Server exposes its remote web-management console on port 9999 by default. Anyone who can reach it gets a login page that controls the whole web server’s configuration.
• Embedded / IoT debug and diagnostic shells. A long line of routers, DVRs/NVRs and IP cameras open a telnet-style debug or diagnostic shell on 9999 — sometimes deliberately as a “diagnostic” feature, sometimes as an undocumented backdoor. Several ship an unauthenticated (or hardcoded-credential) root shell on this port.
• TP-Link Smart Home Protocol (TSHP). Legacy TP-Link Kasa smart plugs, switches and bulbs speak their proprietary control protocol on 9999 over both TCP and UDP, with discovery done by UDP broadcast to 9999.
• Java JMX / RMI. JMX remote management is frequently configured on 9999 (-Dcom.sun.management.jmxremote.port=9999); Apache James, for example, defaults its JMX/RMI listener to port 9999.
• Custom apps and dev tooling. Internally built services, Java debug servers, WebSocket endpoints, proxies and test harnesses routinely pick 9999 because the usual ports are taken — often without authentication or TLS.

Because several of these use UDP as well as TCP (TP-Link discovery in particular), a thorough check scans both protocols.

Common Risks

• Unauthenticated debug / diagnostic shells. The headline risk on 9999. Embedded devices that open a telnet-style shell here frequently require no login, or accept a hardcoded password baked into the firmware — either way, reaching the port is reaching a root shell.
• Weak or default admin consoles. An Abyss admin console (or any product console) on 9999 is a direct configuration-and-takeover surface, made worse when it lacks account lockout or logging so credentials can be brute-forced quietly.
• Unauthenticated JMX/RMI → remote code execution. An exposed JMX server with authentication disabled lets an attacker load a malicious MBean (the classic MLet attack) and run arbitrary Java, i.e. full host compromise.
• Protocol-level insecurity (TP-Link/IoT). The legacy TP-Link Kasa protocol on 9999 has no authentication and only a trivial XOR “cipher” (fixed key 171), so anyone on the LAN can enumerate and control the device; the UDP discovery service can also be abused for reflection.
• Sensitive information disclosure. Debug and custom services on 9999 love to return verbose logs, version strings, environment variables and config on connect.
• Botnet targeting. Mirai-style scanners sweep high IoT ports including 9999 looking for exactly these exposed shells and default logins.

Want to save time on reporting?

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

Book a Demo

Enumeration & Testing

The whole game on port 9999 is identifying the service before you test it. Version-scan both protocols, then branch on what answers.

Detect the service and version (TCP and UDP)

nmap -sV -p 9999 <target>
nmap -sU -sV -p 9999 <target>

Grab the raw banner

nc -nv <target> 9999

A plaintext help/diagnostic menu, a shell prompt, or a login banner on connect points straight at a debug shell or console — note whether it asks for authentication at all.

Check whether it’s HTTP (Abyss admin console or a web app)

curl -sI http://<target>:9999/

An HTTP response with a Server: Abyss/... header identifies an Abyss admin console — then test its login (default/weak creds, and note it historically had no lockout or logging, see CVEs below). Any other Server: header points to a custom web app you fingerprint and test on its own merits.

Check for JMX / RMI

nmap -sV -p 9999 --script "rmi-dumpregistry,rmi-vuln-classloader" <target>

If an RMI registry or JMX endpoint answers, test the insecure-configuration path with Metasploit:

msfconsole -q
use exploit/multi/misc/java_jmx_server
set RHOSTS <target>
set RPORT 9999
run

exploit/multi/misc/java_rmi_server covers the equivalent insecure-default RMI registry case.

Probe a TP-Link Smart Home device (UDP)

Legacy Kasa devices answer their JSON control protocol on 9999 with only the fixed-key XOR obfuscation; the open-source tplink-smartplug client (softScheck) sends a properly framed {"system":{"get_sysinfo":{}}} query and decodes the reply. An unauthenticated get_sysinfo response confirms a controllable IoT device.

Log every open port 9999, the service you positively identified, and any credential, shell or JMX result you confirm, 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 generic “port 9999” CVE — and the biggest risks here are design and misconfiguration (an exposed unauthenticated debug shell, a default-credential admin console, an unauthenticated JMX server), not a single patchable bug. The one well-known CVE that is genuinely tied to a service defaulting to 9999 is in the Abyss admin console:

• CVE-2003-1363 — Aprelium Abyss Web Server 1.1.2 and earlier does not log connection attempts to its web-management port (9999), letting a remote attacker brute-force the administration console with no delay and no audit trail. CVSS v2 6.4. It’s the canonical example of why a console on 9999 without lockout/logging is a real finding.

For the JMX/RMI case, the exposure is an insecure configuration rather than a product CVE: an authentication-disabled JMX server is exploited via the MLet class-loading technique using Metasploit’s exploit/multi/misc/java_jmx_server (and exploit/multi/misc/java_rmi_server for the insecure RMI default). For an embedded debug shell or a custom app on 9999, the CVEs that matter belong to that specific device/firmware or application and version — not to “port 9999.”

Removed from the previous version of this page (wrong service / mislabeled): CVE-2022-30075 was cited as “TP-Link Tapo P100 command injection over port 9999” — it is actually a TP-Link Archer AX50 router backup-file import RCE via the web management UI, with no relation to port 9999. CVE-2019-17099 was cited as a “TP-Link smart plug buffer overflow via UDP 9999” — it is actually a DLL untrusted-search-path flaw in Bitdefender Endpoint Security Tools, nothing to do with TP-Link or 9999. Exploit-DB 48225 was cited as “TP-Link Kasa control via UDP 9999” — it is actually a Netlink GPON Router command-injection RCE (/boaform/admin/formPing), unrelated to 9999. All three were removed; verify every CVE against its NVD record and scope it to the actual product before trusting it.

Mitigation

• Identify the real service first. You can’t secure port 9999 generically — fingerprint whether it’s an Abyss console, a debug shell, a JMX endpoint, an IoT device or a custom app, then harden that specific thing.
• Kill unauthenticated debug/diagnostic shells. On embedded gear, disable any telnet-style debug port, change or remove hardcoded credentials where the vendor allows it, and update firmware — an unauthenticated root shell on 9999 is not something to “firewall and forget.”
• Lock down admin consoles. Put the Abyss (or any product) console behind strong, unique credentials and an IP allowlist, keep it off the public internet, and patch to a version that logs and rate-limits login attempts.
• Secure JMX/RMI. Enable JMX authentication and TLS, or bind the endpoint to localhost only; never expose an authentication-disabled JMX server to untrusted networks.
• Segment IoT. Keep TP-Link/Kasa and similar devices on an isolated VLAN, block their 9999 from routed/internet access, and treat their traffic as untrusted.
• Firewall port 9999 (TCP and UDP) to only the hosts that need it, audit cloud security groups and container mappings for an accidental 0.0.0.0:9999, and close it and rescan if nothing legitimately needs it.

Real-World Example

The cleanest illustration of the port-9999 debug-shell risk is the wave of Chinese-manufactured IP cameras and DVRs (HiSilicon-based, Xiongmai/OEM firmware) found to start a telnet server on port 9999 that drops straight to an unauthenticated root shell — protected, if at all, only by a password hardcoded into the firmware (in one widely reported case, cat1029) that owners could not change through any normal interface. Thousands of devices from dozens of rebranded vendors shipped the same backdoor, so an attacker could mass-scan for open 9999, connect, and own the device as root without a single credential of their own. It’s the port-9999 lesson in miniature: the port number is mundane and shared by unrelated software, but a “diagnostic” shell listening on it — with no real authentication — is the entire attack surface, and finding out what’s actually answering on 9999 is the whole job.

FAQ

What is port 9999 used for?

Port 9999 has no single standard service — IANA only registers it as “distinct”. In practice it’s used by the Abyss Web Server admin console (http://host:9999), embedded and IoT debug/diagnostic shells on routers, DVRs and IP cameras, the TP-Link Smart Home (Kasa) protocol on legacy plugs and bulbs, Java JMX/RMI management endpoints, and a long tail of custom and internal apps. On an open 9999 the first step is identifying which of these is answering.

Why is port 9999 open on my device or router?

Most often because something specific put it there: an IoT device’s control or debug service (TP-Link Kasa uses 9999; some cameras and DVRs open a debug/telnet shell on it), a Java app with JMX enabled, an Abyss web server, or a custom/dev tool. If you don’t recognise the service, fingerprint it before trusting it — an unexplained 9999 can be an unauthenticated shell.

Is port 9999 dangerous to leave open?

The port itself is harmless; the risk depends on what’s behind it. An unauthenticated debug shell, a default-credential admin console, or an authentication-disabled JMX server on 9999 is high-severity and should not face untrusted networks. A properly authenticated, patched, and firewalled service is manageable. Never publish 9999 to the internet without knowing exactly what answers on it.

Is port 9999 TCP or UDP?

Both can be in use. The Abyss console and JMX/RMI are TCP; the TP-Link Smart Home Protocol uses both TCP and UDP (discovery is a UDP broadcast to 9999); debug shells are usually TCP. Scan both protocols — nmap -sV -p 9999 <host> and nmap -sU -sV -p 9999 <host> — to be sure.

How do I find out what’s running on my port 9999?

Fingerprint it: nmap -sV -p 9999 <host> for service/version, nc -nv <host> 9999 for a raw banner, and curl -sI http://<host>:9999/ to see if it’s HTTP. A Server: Abyss header is the admin console; a shell prompt or plaintext menu is a debug shell; an RMI/JMX reply is a Java management endpoint; a UDP get_sysinfo response is a TP-Link device. Anything unrecognised deserves a closer look before you assume it’s benign — compare with the analogous Telnet debug shell on port 23.

How do I secure or close port 9999?

Identify the service first, then harden it: disable unauthenticated debug/telnet shells and update firmware on IoT gear, put admin consoles behind strong credentials and an IP allowlist, enable authentication/TLS on JMX or bind it to localhost, segment IoT devices onto an isolated VLAN, and firewall 9999 (TCP and UDP) to only the hosts that need it. If nothing needs it, stop the service and confirm the port is closed with a rescan.

TL;DR

• Service: no single standard (IANA “distinct”) — most notably the Abyss Web Server admin console, embedded/IoT debug shells, the TP-Link Smart Home protocol, Java JMX/RMI, and custom apps
• Default port: 9999/TCP and 9999/UDP
• Biggest risk: an unauthenticated debug shell or default-credential admin console (or an authentication-disabled JMX server) exposed on 9999 — a direct path to a shell or full host takeover; identify what’s answering before you trust it
• Mitigation: fingerprint the real service, kill unauthenticated debug shells and hardcoded creds, lock down admin consoles and JMX, segment IoT, and firewall port 9999 if nothing needs it

Related ports: Port 9998 (distinct32), Port 9510 (NCSA Telnet), Port 9512 (alternate service), and Port 23 (Telnet). Capture 9999 findings in the PentestPad reporting tool.