14

Port 14/tcp is listed as Unassigned in the IANA Service Name and Transport Protocol Port Number Registry: the service-name column is empty, there is no assignee, no description beyond the "Unassigned" status, and the IANA Reference column is blank. Both 14/tcp and 14/udp carry the same Unassigned status, so the number is held open on both transports rather than being delegated to any protocol. The absence is long-standing, not a recent de-assignment — the early "Assigned Numbers" RFCs, including RFC 1340 (July 1992), already showed port 14 with no well-known service, so it appears never to have held a registered designation. Wikipedia's list of TCP/UDP port numbers likewise skips 14 entirely (it jumps from 13/daytime to 15), which is consistent with the registry. For an analyst the practical consequence is that there is no legitimate, standardized service that should answer on this port: any host responding on 14/tcp is running non-standard or undocumented software, which can itself be a detection signal in network monitoring. No specific malware family, named exploit, or CVE is attributed to port 14 in the public threat-intelligence sources checked, and no documented mass-scanning campaign targets it specifically — though, like all low-numbered ports, it is swept incidentally by broad opportunistic scanners and indexed by internet-wide scanning services. A circulating claim that port 14 was "previously assigned to netstat and de-assigned 2025-02-13" could not be corroborated against any primary IANA source (the .txt and .xml registry endpoints both show a plain "Unassigned" with no de-assignment annotation) and is excluded as unverified.

IANA assignment

none — listed as Unassigned; service-name column empty, no assignee, reference field blank; dual-registered Unassigned on 14/tcp + 14/udp [Confirmed] — IANA Service Name and Transport Protocol Port Number Registry (the IANA Service Name and Transport Protocol Port Number Registry)

Range class

well-known (0–1023)

Prevalence

Unknown — no per-port open-frequency figure recorded for 14/tcp in sources checked [Unknown]

Related ports

the small/legacy low-port cluster (7, 9, 11, 13, 15, 17, 19) that surrounds it in the well-known range

Primary use

none — no IANA-assigned protocol; RFC 1340 (1992) also lists port 14 as unassigned, so it has no historical well-known service either

Other/unofficial uses

Unknown — no standard software is documented as legitimately binding to 14/tcp; it does not appear on common server-software default-port lists [Unknown]

Security implications

no malware family, named exploit, or CVE attributed to port 14 in public threat intel checked; because the port is unassigned, any host answering on it is running non-standard/undocumented software and may warrant investigation as a detection signal

Exposure / scanning

no documented mass-scanning campaign targets 14/tcp specifically; low-numbered unassigned ports are probed incidentally by broad opportunistic sweeps and indexed by internet-wide scanners [Likely]

Typically seen on

no expected legitimate listener; a responsive 14/tcp is an anomaly worth investigating

Analyst note

There is no standardized service for port 14 — treat any open 14/tcp as non-standard software and investigate; do not assume a benign default.

Port 14/udp is listed as "Unassigned" in the IANA Service Name and Transport Protocol Port Number Registry: the 14/udp row carries no service name, no assignee, no contact, no registration or modification date, and a blank reference field — IANA cites no RFC for this entry, and the Reference column is genuinely empty in the source rather than omitted. The status is long-standing, not recent: RFC 1340 (Assigned Numbers, J. Reynolds and J. Postel, July 1992) already recorded both 14/tcp and 14/udp as "Unassigned [JBP]" (Jon Postel), and no later assignment was ever made. The matching 14/tcp row is identically Unassigned, so the port number is unallocated on both transports. Port 14 sits in a stretch of the well-known range (0–1023) where most low ports received early diagnostic services but 14 itself was skipped — port 13 is daytime, port 15 was the short-lived netstat (already "Unassigned [was netstat]" by RFC 1340), and port 17 is qotd, yet port 14 never carried a service name on record. For an analyst the practical reading is that no protocol or application is officially assigned here and nothing standard should ever answer on 14/udp, so any traffic observed is anomalous: it most plausibly reflects a misconfigured custom application that bound to an unused low port, broad reconnaissance, or — less commonly — covert use that exploits the obscurity of an unassigned low port. UDP makes this harder to read than TCP: an unassigned UDP port frequently shows as open|filtered in Nmap UDP scans, because the absence of an ICMP Port Unreachable reply (often rate-limited or dropped by the host) is indistinguishable from a genuine listener. No CVE, malware family, or exploitation framework specific to 14/udp surfaced in current public sources, and the port does not appear in Shodan's indexed-port population, so real-world exposure is negligible. A host found listening on 14/udp should be treated as suspicious unless a documented internal application explains it.

IANA assignment

Unassigned — blank service name, blank assignee, blank contact, blank registration/modification date, blank reference; identical to the 14/tcp row (dual-listed, both Unassigned) [Confirmed] — IANA Service Name and Transport Protocol Port Number Registry (registries/service-names-port-numbers.csv, 14/udp row, lines 32–33)

Range class

well-known (0–1023) [Confirmed]

IANA reference

blank — no RFC cited in the registry (stays blank, not fabricated) [Confirmed] — IANA registry

Prevalence

negligible — port 14 was skipped while neighbours (13 daytime, 15 netstat, 17 qotd) received early services; no significant scan population [Likely] — IANA registry; public scanning data

Related ports

14/tcp (also Unassigned); the low well-known neighbours where early services landed (13 daytime, 15 netstat, 17 qotd)

Primary use

none — no protocol or application is officially assigned to 14/udp

Other/unofficial uses

Unknown — no software is known to legitimately bind to 14/udp by design [Unknown]

Security implications

an unassigned low port — any traffic is anomalous and worth flagging. Plausible causes: a misconfigured/custom app bound to a low port, broad scanning (Nmap/masscan sweep low ranges), or covert use of an obscure port. UDP scans often show unassigned ports as open|filtered because a missing ICMP Port Unreachable (rate-limited) looks like a listener. No port-14-specific CVE, malware family, or campaign found

Exposure

low real-world exposure; 14/udp does not appear in Shodan's indexed-port list and is not a default scanner target

Historical status

RFC 1340 (Assigned Numbers, July 1992) recorded both 14/tcp and 14/udp as "Unassigned [JBP]"; no later assignment was made [Confirmed] — RFC 1340

Analyst note

treat a host listening on 14/udp as suspicious absent a documented internal application reason.