Port 10001 – scp-config (Ubiquiti Device Discovery & Serial-Gateway Port)

Port 10001 is registered with IANA as scp-config, but almost nothing you meet on it in the wild is that placeholder service. In practice, an open port 10001 is most often one of two things: the Ubiquiti device-discovery service on UDP 10001 — a UniFi/airOS protocol that answers a tiny 4-byte probe with a fat block of device details, and which became one of the internet’s largest DDoS-amplification and information-disclosure exposures — or a serial-to-Ethernet gateway (Lantronix, Moxa, and similar device servers) that puts a raw serial line straight onto the network as a TCP data-and-config port. Custom and automation/SCADA apps also squat 10001. So the first job on an open 10001 isn’t to attack “scp-config”; it’s to identify whether you’re looking at a Ubiquiti discovery responder, an industrial serial gateway, or a custom app — and then assess that.

Why It’s Open

The single most common real-world listener on port 10001 is the Ubiquiti Device Discovery Service on UDP 10001. It ships enabled by default across airMAX, airOS, EdgeMAX, and UniFi gear and exists so a controller (UniFi Network, CloudKey) can find devices on the network. Send it a 4-byte discovery message and it replies with the device’s hostname, model, firmware version, IP and MAC addresses, adoption/management state, and — on wireless units — the ESSID. Because it’s UDP, unauthenticated, and answers a tiny request with a large response, an internet-exposed instance is both a DDoS reflection/amplification source and an information-disclosure leak. Rapid7’s 2019 internet-wide scan found roughly half a million exposed devices answering on UDP 10001.

Port 10001 is also a serial-gateway and automation default. Lantronix device servers (UDS-10/UDS100, XPort family) use TCP 10001 as the data port for the first serial port (10002 for the second), tunnelling RS-232/RS-422/RS-485 traffic over TCP in raw, Telnet, or virtual-COM modes; Moxa NPort and other serial-to-Ethernet converters use the same 100xx range, and industrial protocols such as EtherNet/IP appear here too. In a factory, utility, or building-automation network, an open 10001 is frequently a piece of equipment bridged straight onto Ethernet with a raw TCP socket and a lightweight config interface. Beyond those, custom and internally developed apps reach for 10001 because it’s a high, memorable, unassigned-feeling number — so an unexplained 10001 — like the grab-bag of listeners you find on port 9999 — always deserves fingerprinting rather than a guess.

Common Risks

• DDoS reflection/amplification (Ubiquiti UDP 10001). A spoofed 4-byte discovery packet returns a much larger response — a measured bandwidth amplification factor of 30–35x (minimum ~3.67x) — so an exposed responder can be used to flood a third-party victim — the same reflection pattern seen with SSDP on port 1900. With hundreds of thousands of devices historically exposed, this was a large, real reflection pool.
• Device information disclosure. The discovery reply hands an attacker hostname, model, firmware version, internal IP, MAC address, management state, and ESSID for free — ideal fingerprinting for choosing the next exploit, and a privacy leak in its own right.
• Raw, unauthenticated serial gateways. A Lantronix/Moxa data port on TCP 10001 often exposes the attached serial device (a PLC, meter, sensor, console, or building controller) with no authentication on the data channel — connect and you’re on the wire.
• Weak or default gateway configuration. Serial device servers commonly ship with default passwords and web/Telnet config interfaces; a reachable config plane means an attacker can re-point the tunnel, read/alter serial traffic, or brick the link.
• Legacy/unpatched firmware. Both the Ubiquiti gear and the industrial gateways that default to 10001 tend to run old firmware that rarely gets patched, keeping known bugs (see CVEs below) live for years.
• Custom apps with no hardening. Anything home-grown bound to 10001 may lack authentication, input validation, or TLS entirely.

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 10001 is identifying which service is answering before you test it. Probe both protocols — Ubiquiti discovery is UDP, serial gateways are TCP — then branch on the reply.

Detect the service and version (both protocols)

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

A UDP hit with a Ubiquiti/ubnt-style fingerprint points to the discovery service; a TCP hit that looks like a raw socket, Telnet, or a Lantronix/Moxa banner points to a serial gateway.

Send a manual Ubiquiti discovery probe

The discovery service answers a 4-byte request (\x01\x00\x00\x00). Fire it and read the raw reply to confirm the service and see exactly what it leaks:

echo -ne '\x01\x00\x00\x00' | nc -u -w2 <target> 10001 | xxd

A large hex response containing model strings, a firmware version, and MAC/IP bytes confirms an exposed Ubiquiti discovery responder — and shows precisely which fields are disclosed.

Enumerate Ubiquiti discovery with Metasploit

msfconsole -q
use auxiliary/scanner/ubiquiti/ubiquiti_discover
set RHOSTS <target>
run

This parses the discovery response into structured fields (name, model, firmware, IPs, MACs) across a range, which is the fastest way to inventory exposed Ubiquiti devices.

Banner-grab a serial gateway (TCP)

nc -nv <target> 10001

If it’s a Lantronix/Moxa data port you may see raw serial output or a login/config prompt; note the device server model, then check its dedicated setup/config port and web interface for default credentials.

Log every open port 10001, the service you positively identified, the discovery fields it disclosed, and any default-credential or raw-serial access 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

The service that carries the clearest, real network CVE on this port is the Ubiquiti device-discovery protocol:

• CVE-2017-0938 — Ubiquiti airMAX (< 8.3.2 and < 6.0.7) and EdgeMAX (< 1.9.7): the Discovery Protocol on UDP 10001 can be abused in amplification attacks (denial of service). CVSS 3.1 7.5 HIGH (AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H). Ubiquiti addressed it by making patched firmware respond only to internal/private source addresses. The exposure was documented by Rapid7 (Jon Hart, 2019) and reported to CERT/CC as VU#993645; Metasploit ships auxiliary/scanner/ubiquiti/ubiquiti_discover to enumerate affected devices.

Beyond that CVE, the discovery-service exposure is partly design-level: even fully patched devices still disclose device metadata to anyone allowed to reach UDP 10001, so the honest fix is network access control, not just a firmware bump. For a serial-to-Ethernet gateway on TCP 10001, there is no generic “port 10001” CVE — the bugs belong to the specific device server (Lantronix, Moxa, etc.) and firmware, so identify the exact model and version and check that vendor’s advisories.

The previous version of this page listed three CVEs that have nothing to do with port 10001, and all three have been removed. CVE-2021-36260 is a Hikvision IP-camera web-server command injection (it was mislabelled here as “HPE iLO 4”); CVE-2019-12780 is command injection in a Belkin Wemo Crock-Pot’s UPnP API (mislabelled as “Zyxel NAS”); and CVE-2017-1000486 is a weak-encryption RCE in PrimeTek PrimeFaces (mislabelled as a “Primergy RX2540” config interface). None run on port 10001. Always verify a CVE against its NVD record and confirm the product and port before trusting it.

Mitigation

• Identify the real service first. You can’t secure port 10001 generically — it may be a Ubiquiti discovery responder, an industrial serial gateway, or a custom app. Fingerprint it, then harden the specific thing behind it.
• If it’s Ubiquiti discovery: update airMAX/airOS/EdgeMAX firmware so the service only answers private/internal source addresses, and firewall UDP 10001 so it is never reachable from the internet — no external party should ever be able to query or reflect off it.
• If it’s a serial gateway (Lantronix/Moxa): keep the data port off untrusted networks, require authentication on the config/setup interface, change all default passwords, and put the device behind a VPN or a segmented SNMP-managed OT network rather than exposing raw serial to the world.
• Block spoofed traffic upstream. Because the amplification abuse relies on spoofed source addresses, network operators should implement BCP 38 / ingress filtering to cut off reflection at the edge.
• Firewall TCP and UDP 10001 to only the controllers, clients, or management hosts that genuinely need it, and audit cloud security groups and container port maps for an accidental 0.0.0.0:10001.
• Patch and inventory legacy firmware. Both Ubiquiti gear and industrial device servers tend to run old builds — track models and versions and update them, or replace end-of-life units.
• Close it if nothing needs it, and rescan to confirm with nmap -sU -sV -p 10001 <target>.

Real-World Example

In February 2019, Rapid7 Labs researcher Jon Hart published an internet-wide study of the Ubiquiti device-discovery service on UDP 10001. Using Rapid7’s Project Sonar, the team sent the tiny 4-byte discovery probe across the IPv4 space and found roughly half a million exposed devices — about 498,000 IPs with 10001/UDP open, 487,000 confirmed speaking the discovery protocol, and 486,388 unique physical devices by MAC address, dominated by NanoStation, AirGrid, LiteBeam, PowerBeam, and NanoBeam units, with over half located in Brazil. Every one of them answered with hostname, model, firmware, IP, MAC, and (for wireless gear) ESSID, and could be used as a 30–35x amplification reflector in DDoS attacks. Worse, the responses showed attackers had already been there: more than 17,000 devices had hostnames rewritten to messages like HACKED-ROUTER-HELP-SOS. Follow-up research years later still found tens of thousands of these discovery services exposed — a textbook example of a default-on convenience protocol becoming a long-lived amplification and privacy problem simply because it was left facing the internet.

FAQ

What is port 10001 used for?

Port 10001 is registered with IANA as “scp-config,” but that label is rarely what you meet. In the real world it’s most often the Ubiquiti device-discovery service on UDP 10001 (used by UniFi/airOS/EdgeMAX gear so a controller can find devices), or a serial-to-Ethernet gateway such as a Lantronix or Moxa device server using TCP 10001 as the raw data/config port for a serial line. Automation/SCADA equipment and custom apps also use it, so the first step on an open 10001 is to identify which of these is answering.

Why is port 10001 open on my device or network?

Most commonly because a Ubiquiti device (access point, radio, router, camera) has its discovery service enabled by default and is reachable on UDP 10001, or because a serial device server is bridging an RS-232/485 device onto the network on TCP 10001. If it’s a Ubiquiti unit, the discovery service is on by default and should be firewalled off the internet; if it’s a serial gateway, it’s exposing the attached equipment and its config interface.

Is the Ubiquiti discovery service on port 10001 dangerous?

When it’s reachable from the internet, yes. It answers a 4-byte probe with a large response, which makes it a DDoS amplification reflector (30–35x), and that response leaks device details — model, firmware, IP, MAC, and ESSID. Patched firmware limits replies to internal addresses, but the real fix is to firewall UDP 10001 so no untrusted host can reach it at all.

Is port 10001 TCP or UDP?

Both, depending on the service. The Ubiquiti discovery protocol runs over UDP 10001, while serial gateways (Lantronix, Moxa) and most custom apps use TCP 10001. Because the two look completely different, scan both — nmap -sU -sV -p 10001 <target> for the discovery service and nmap -sV -p 10001 <target> for a TCP gateway.

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

Fingerprint it. Run nmap -sU -sV -p 10001 <host> and nmap -sV -p 10001 <host>, send the Ubiquiti discovery probe with echo -ne '\x01\x00\x00\x00' | nc -u -w2 <host> 10001 | xxd, and banner-grab any TCP listener with nc -nv <host> 10001. A large UDP reply full of model/firmware/MAC strings is a Ubiquiti discovery responder; a raw serial stream or a Lantronix/Moxa prompt is a serial gateway; anything else is a custom app to test on its own.

How do I secure or close port 10001?

Identify the service first, then harden it. For Ubiquiti discovery, update firmware and firewall UDP 10001 so it never faces the internet. For a serial gateway, keep it off untrusted networks, require authentication, change default passwords, and put it behind a VPN or segmented OT network. Firewall both TCP and UDP 10001 to only the hosts that need it, and if nothing legitimately uses it, stop the service and confirm with a rescan.

TL;DR

• Service: IANA “scp-config,” but in practice the Ubiquiti device-discovery service (UDP 10001) or a Lantronix/Moxa serial-to-Ethernet gateway (TCP 10001), plus automation/SCADA and custom apps
• Default port: 10001/UDP (Ubiquiti discovery) and 10001/TCP (serial gateways, custom apps)
• Biggest risk: an internet-exposed Ubiquiti discovery service used as a 30–35x DDoS amplification reflector that also leaks device model/firmware/IP/MAC/ESSID (CVE-2017-0938), or a raw, unauthenticated serial gateway exposing the attached device
• Mitigation: fingerprint what’s answering, patch firmware, firewall UDP/TCP 10001 off untrusted networks, apply ingress/BCP 38 filtering against spoofing, and lock down serial-gateway config planes; record findings in the pentest report