32

Port 32/tcp is listed in the IANA Service Name and Transport Protocol Port Number Registry as Unassigned: the service-name column is blank, and the assignee, contact, registration-date, modification-date, and reference fields are all empty. It has never received a formal IANA service assignment, and port 32/udp is identically Unassigned with all fields blank. The port sits inside the well-known range (0–1023), wedged between two early-era allocations — 31/tcp msg-auth (MSG Authentication, assignee Robert Thomas) below it and 33/tcp dsp (Display Support Protocol, assignee Ed Cain) above it. Those neighbors trace to the ARPANET/NCP period when small blocks of low ports were handed out individually, but port 32 was simply skipped and stayed unallocated through to the current registry. Because there is no canonical service name, no standardized protocol, and no daemon that uses port 32 by convention, there is nothing an analyst should expect to find here on a normal host. No CVEs, no documented trojan or backdoor families, and no port-32-specific mass-scan findings turned up in current (2024–2026) sources — the classic trojan-port tables do not list it. That absence is itself the analyst takeaway: an open listener on port 32/tcp is anomalous and warrants investigation, since it implies custom software, a misconfigured application that grabbed an arbitrary low port, or possibly unauthorized access tooling. Low-numbered unassigned ports like this are still swept periodically by opportunistic internet scanners working through the sub-1024 range, so seeing a probe to port 32 in logs is unremarkable, but seeing a host *answer* on it is not.

IANA assignment

Unassigned — service-name column blank; no assignee, contact, registration date, modification date, or reference [Confirmed] — IANA Service Name and Transport Protocol Port Number Registry (the IANA Service Name and Transport Protocol Port Number Registry line 71)

Range class

well-known (0–1023) [Confirmed] — port number 32 falls in 0–1023

Dual registration

32/udp is also Unassigned with all fields blank [Confirmed] — the IANA Service Name and Transport Protocol Port Number Registry line 72

IANA Reference

blank (no RFC cited) [Confirmed] — IANA registry CSV

Primary use

none — no IANA service name and no standardized protocol assigned to port 32/tcp

Common software

Unknown — no canonical software or daemon is known to use port 32/tcp by convention or specification

Security implications

no CVEs, no known trojan/backdoor families, and no port-32-specific Shodan/Censys mass-scan findings in current sources; an open listener on an unassigned low port is anomalous and worth investigating (custom software, a misconfigured app on an arbitrary port, or unauthorized access tooling); sub-1024 unassigned ports are periodically probed by opportunistic scanners

Historical context

surrounding ports (31 MSG Authentication, 33 Display Support Protocol) were assigned in the early ARPANET/NCP era, but port 32 was never allocated and remains unassigned [Confirmed] — IANA registry CSV

Analyst note

nothing legitimate is expected on port 32/tcp — treat a responsive listener as an anomaly and investigate; a probe alone is routine background scanning.

Port 32/udp is unassigned in the IANA Service Name and Transport Protocol Port Number Registry: it carries no service name, no description beyond "Unassigned," no assignee, and a blank reference field, and its TCP counterpart (32/tcp) is identically unassigned. The port sits in the System Ports range (0–1023), the band that under RFC 6335 requires IETF Review or IESG Approval before any assignment can be made — none ever has been for port 32, so unlike its low-numbered neighbours it has no ARPA-era or RFC-era allocation in the historical record. Its immediate neighbours did get early names (31 = MSG Authentication, 33 = Display Support Protocol), which makes the gap at 32 a genuine hole rather than an oversight in the sourcing. Because nothing is registered here, there is no protocol to summarise and no standard client or server software that legitimately uses the port. The Nmap services database lists 32/udp as "unknown" with an open-frequency of roughly 0.000330 — three orders of magnitude below well-known ports, which score near 1.0 — so it is observed open only very rarely on internet hosts. For an analyst the practical consequence is that any traffic on 32/udp is anomalous by definition: there is no legitimate inbound service to expect, firewalls drop it by default, and a host answering on this port warrants investigation as a misconfiguration, a covert channel, or a honeypot trip-wire rather than a recognised service. No CVEs, malware families, or threat-actor campaigns specifically targeting port 32/udp were found in available sources as of June 2026; absence of a registered service means there is also no documented vulnerability tied to the port itself.

IANA assignment

Unassigned — no service name, description "Unassigned," no assignee, reference field blank; UDP and TCP both unassigned (32/udp + 32/tcp) [Confirmed] — IANA Service Name and Transport Protocol Port Number Registry (the IANA Service Name and Transport Protocol Port Number Registry line 72; TCP line 71)

Range class

system / well-known (0–1023); RFC 6335 requires IETF Review or IESG Approval for assignment, never granted for port 32 [Confirmed] — IANA registry

Prevalence

nmap-services open-frequency 32/udp ≈ 0.000330 (very rarely observed open) [Confirmed] — nmap-services file

Related ports

neighbouring low-numbered ports 31 (MSG Authentication) and 33 (Display Support Protocol); the broader unassigned gaps in the system range

Primary use

none — unassigned, no official protocol

Other/unofficial uses

none known; no software or protocol is formally registered to use 32/udp

Security implications

no service-specific CVEs, malware, or threat-actor targeting found (June 2026); because the port is unassigned, any traffic on it is anomalous by definition and firewalls typically drop it by default — making it occasionally useful as a honeypot trip-wire or covert channel, though no documented instances were located

Typically seen on

nothing legitimate — an open 32/udp is an anomaly, misconfiguration, decoy, or covert-channel candidate

Analyst note

port 32 has been unassigned throughout the available IANA record; treat a responsive 32/udp as anomalous and investigate rather than assuming a service. IANA Reference field is blank — no RFC exists, so the blank stays blank.