An internet-wide scan found exposed services on TCP port 0

Security researcher acidvegas scanned IPv4 for TCP port 0 and found exposed industrial controls, alarm systems and phone logs among the responding hosts. The results show how a number reserved by standards can still carry traffic when network equipment forwards it.

Security researcher acidvegas scanned IPv4 for TCP port 0 and found exposed industrial controls, alarm systems and phone logs among the responding hosts. The results show how a number reserved by standards can still carry traffic when network equipment forwards it.

Port 0 has two roles that rarely meet. Operating systems treat it as a request for an available port when a program opens a network socket. On the wire, though, the TCP header can carry zero like any other 16-bit number. In a Nov. 6 report , acidvegas describes how a port-forwarding rule put an IRC network on TCP port 0, then details a scan for other services using it.

The scan turned up exposed servers and devices across the internet, including programmable logic controllers, alarm communicators and business phone systems. The most sensitive finding involved 21 Avaya IP Office systems that sent call records to anyone who connected.

The socket API gives port 0 a different meaning

The TCP specification, RFC 9293 , defines source and destination ports as 16-bit fields and does not prohibit zero. The IANA port registry marks TCP and UDP port 0 as reserved. RFC 6335 explains that reserved values can remain available for future changes to the port ranges.

The familiar “pick a port for me” behavior comes from the sockets API. On Linux, a program that calls bind() with port 0 asks the kernel to choose an ephemeral port. The same allocation can happen when a program starts listening or connects without first binding a local port. Linux documents the configured range in its ip(7) manual ; the default range cited in the report is 32768 through 60999.

That behavior does not prevent a packet from carrying destination port 0. It does mean common clients and servers refuse to use that number. Acidvegas reports that nc , telnet and Chromium rejected connections to the port, while socat and Python's asyncio could connect.

The Linux kernel creates another complication. Its getpeername() path treats a destination port of zero as a marker for an unconnected socket. A TCP connection to port 0 can therefore work while getpeername() reports ENOTCONN . Acidvegas traced a Python SSL failure to this mismatch: the blocking SSL wrapper checks the peer address, gets the error, then attempts a read that returns EAGAIN . Python's asyncio TLS path avoids that check and works.

A SYN scan found edge devices and services

Acidvegas used masscan , which creates its own TCP packets instead of relying on the operating system's socket API. The scan received SYN-ACK responses from 1,173,626 IPv4 addresses. That count did not represent the same number of port 0 services. Many addresses sat behind network equipment that answered for whole address blocks.

One block, 172.65.0.0/16, responded on 65,534 of its 65,536 addresses. Acidvegas interpreted that pattern as a firewall or router replying at the network edge, rather than thousands of independent servers. Across the scan, 1,116,675 addresses completed the handshake without sending data. Of 56,951 that sent a banner, 53,741 returned messages from F5 BIG-IP load balancers. After excluding those responses and 305 hosts with the same fixed token, acidvegas cataloged 2,905 addresses with other services.

The remaining services included SSH, MySQL and MariaDB, Telnet, HTTP, FTP, VNC and OpenVPN. Many banners pointed to embedded equipment: routers, network-attached storage, digital video recorders and power controllers. Repeated device types within single providers suggested that some customers inherited a port-forward rule from a device or ISP configuration. Acidvegas presented that as a likely explanation, not a confirmed cause.

Some web interfaces exposed information without a login. One mobile router returned its WAN and LAN addresses, wireless MAC addresses, network name, firmware version and uptime. A building automation controller and an HVAC control system also presented login pages on the port.

Industrial protocols appeared beside router pages

The scan also reached equipment that spoke industrial and building-control protocols. A Beckhoff CX5120 embedded PC sent a Windows CE remote-display handshake. Acidvegas matched its bytes to Beckhoff's CERDISP protocol and found that the greeting indicated a session without a password. The protocol can carry screen updates and mouse and keyboard input, giving an unauthenticated visitor a view of the controller's display and a path to interact with it.

An Omron endpoint returned a FINS/TCP error that meant all connections were in use. FINS lets clients read and write memory on Omron programmable logic controllers. Another host sent a valid Modbus request for input registers as soon as a connection opened, a pattern consistent with a supervisory control system polling whoever connected.

Other banners pointed to a power-quality meter, factory machine-monitoring software, automation gateways and alarm communicators. Several DSC alarm communicators sent identification data that included device identifiers and, on cellular models, SIM card numbers. Acidvegas identified the protocol by comparing the packets with the open-source DSC-TLink project and verifying its checksum.

These findings do not show that every device allowed control or that an attacker used the exposed services. They show that the scan reached systems whose protocols and banners disclosed operational details. In some cases, the device sent information before the scanner made a request beyond opening a connection.

Phone systems sent call records on connection

The clearest privacy exposure came from 21 Avaya IP Office phone systems. Each started streaming Station Message Detail Recording data as soon as acidvegas connected. The records included call times, durations, phone numbers, staff names, extensions and trunk labels.

The scan captured 7.5 kilobytes from each system, enough for 37 to 62 calls. Some records dated from years before the scan, while others came from days before it. Nineteen systems sat on U.K. networks, with one in the United States and one in South Africa. Acidvegas said the systems sent the logs without a request for them.

That data could expose employee identities and calling patterns to anyone who found the service. The scan's capture limit also meant the visible records represented only part of what each system might send.

Port 0 did not hide the services

The scan undermines the idea that port 0 stays safe because ordinary tools avoid it. Masscan reached services that connect-based scanners might skip, while routers and forwarding rules carried traffic to the destination. Acidvegas's IRC network used a firewall rule to redirect incoming port 0 traffic to the server's usual plaintext IRC port. A second rule forwarded port 1 to its TLS port.

The port number itself offered no protection. A single SYN scan found exposed remote desktops, industrial controls, alarm systems, databases and phone logs. The repeated banners across providers led acidvegas to suspect misconfigured port forwards, though the scan could not establish how each administrator or device ended up with that configuration.

The report's central lesson follows from the gap between software conventions and network behavior: a client may reject port 0, while a packet and a forwarding device can still carry traffic there. Administrators who rely on the port's reputation as unusable can miss services that expose data or control interfaces.

Source : The Port That Does Not Exist , by acidvegas , acidvegas , Nov 6, 2026