2049
Summary
- // if you see it open
- High-value attack surface. Misconfigured/world-readable exports are enumerable with 'showmount -e' (often unauthenticated); 'no_root_squash' grants remote root-equivalent writes; NFSv2/v3 traffic is unencrypted and IP-trust based (spoofable). Internet-facing servers are indexed by Shodan. Typical attacker path: nmap ports 111+2049, then 'showmount -e' to enumerate exports, then mount and read/write. NFSv4 with Kerberos (krb5p) closes most authentication and confidentiality gaps. CVEs referenced in scanning sources: CVE-2023-4911 (glibc Looney Tunables), CVE-2017-15265.
- // analyst note
- an exposed 2049 on an untrusted network is a high-severity finding — enumerate exports and check for
no_root_squashand missing Kerberos before assuming benign.
About port 2049/tcp.
Port 2049/tcp is registered with IANA as nfs with the description "Network File System - Sun Microsystems," assignee and contact Brent Callaghan, and a blank Reference field on the TCP/UDP rows (the SCTP registration cites RFC 5665). It is the fixed, well-known port for the Network File System, a distributed file-sharing protocol originally developed by Sun Microsystems that lets a client mount a remote directory and use it as if it were local storage. The IANA registry carries an explicit conflict marker: the name shilp is also listed on 2049/tcp and 2049/udp with no description, assignee, or reference — a legacy collision with no known production use, while the NFS assignment is the authoritative and universally implemented one. Historically NFSv2 (RFC 1094) and NFSv3 (RFC 1813) reached the server through the RPC portmapper/rpcbind on port 111 and could land on dynamic ports; NFSv4 (RFC 3530, then RFC 7530) fixed the service on port 2049 and mandated TCP, so it can transit firewalls without the separate RPC binding protocol (RFC 1833). For an analyst, port 2049 is a high-value attack surface: misconfigured exports are enumerable with showmount -e (often anonymously), a no_root_squash export grants remote root-equivalent writes, and NFSv2/v3 traffic is unencrypted and IP-trust based, making it spoofable. Internet-facing servers are routinely indexed by Shodan and probed by pentest tooling (nmap of 111+2049, then mount), and exposed shares have leaked sensitive files. NFSv4 with Kerberos (krb5p) closes most of the authentication and confidentiality gaps but needs added infrastructure.
- IANA assignment
nfs— "Network File System - Sun Microsystems"; reference (blank on TCP/UDP rows — no RFC cited; SCTP row cites RFC 5665); assignee/contact Brent Callaghan; registered on 2049/tcp, 2049/udp, and 2049/sctp [Confirmed] — IANA Service Name and Transport Protocol Port Number Registry (the IANA Service Name and Transport Protocol Port Number Registry lines 3857–3860)- Range class
- well-known (0–1023)
- IANA conflict
shilpalso claims 2049/tcp and 2049/udp with no description/assignee/reference; flagged "<== NOTE Conflict on 2049 !" in the registry CSV; NFS is the authoritative use [Confirmed] — IANA registry CSV- Related ports
- 111/tcp+udp (rpcbind/portmapper), and the NFS auxiliary daemons (mountd/statd/lockd) it historically depended on
Primary use
Network File System — distributed file-sharing protocol; NFSv4 fixes the service on port 2049 and mandates TCP (earlier NFSv2/v3 reached it via RPC portmapper on 111)
Common software
Linux kernel NFS server + nfs-utils (RHEL, CentOS, Ubuntu), FreeBSD, Solaris, macOS NFS client; VMware/hypervisor datastores; Kubernetes NFS-backed PersistentVolumes
Security implications
misconfigured/world-readable exports enumerable via showmount -e (often unauthenticated); no_root_squash grants remote root-equivalent write; NFSv2/v3 unencrypted and IP-trust based (spoofable); Internet-facing servers indexed by Shodan; typical attacker path is nmap of 111+2049 → showmount -e → mount/read-write; NFSv4 + Kerberos (krb5p) mitigates [Confirmed/Threat-reported] — https://hacktricks.wiki/en/network-services-pentesting/nfs-service-pentesting.html, https://www.huntress.com/cybersecurity-101/topic/nfs
- Transport
- registered for both TCP and UDP (and SCTP); NFSv4 requires TCP, NFSv2/v3 commonly used UDP [Confirmed] — IANA registry; RFC 7530
- RFC lineage
- RFC 1094 (NFSv2, 1989), RFC 1813 (NFSv3, 1995), RFC 3530 (NFSv4, 2003), RFC 7530 (NFSv4, 2015, obsoletes 3530); RFC 1833 (RPC binding) [Confirmed] — https://datatracker.ietf.org/doc/html/rfc7530, https://www.rfc-editor.org/info/rfc7530/
- CVEs of note
- CVE-2023-4911 (glibc "Looney Tunables" buffer overflow; affects NFS-using systems among others) and CVE-2017-15265 reported in scanning references [Likely] — https://scanitex.com/en/resources/ports/tcp/2049
- DNS-SD
- defined TXT key
path=<path to mount point>[Confirmed] — IANA registry assignment notes - Analyst note
- an exposed 2049 on an untrusted network is a high-severity finding — enumerate exports and check for
no_root_squashand missing Kerberos before assuming benign.
About port 2049/udp.
Port 2049/udp is registered with IANA as nfs, described as "Network File System - Sun Microsystems," with assignee/contact Brent Callaghan and a blank Reference field in the UDP row (the [RFC5665] citation in the registry applies only to the separate 2049/sctp row, not to UDP). The same port/protocol pair also carries a second, conflicting registration named shilp — the registry CSV flags both 2049/tcp and 2049/udp with "== NOTE Conflict on 2049 !" — but shilp has no description, assignee, contact, dates, or reference and is effectively a vestigial collision; nfs is the well-known primary assignment. NFS is the distributed file-sharing protocol Sun originated in 1984 that lets clients mount and read/write remote file systems as if local, driven by RPC operations. UDP on port 2049 is the transport historically associated with the older NFSv2 and NFSv3 generations (which also depend on the RPC portmapper/rpcbind on port 111 for negotiation); NFSv4 dropped the portmapper and consolidated to 2049/TCP only, so UDP is the legacy-protocol surface. For an analyst the security weight is high: NFSv2/v3 over UDP carry no native authentication or encryption — access control rests on client-supplied UID/GID, which is trivially spoofable, and cleartext on the wire. A ZoomEye threat report (August 2025) counted over 1.5 million internet-exposed NFS servers, of which a 3,369-host sample showed 37.34% with mountable exports and roughly 35% running no_root_squash, enabling root-level privilege escalation from a client. Export enumeration via showmount -e needs no authentication. Standing guidance (UK NCSC, vendor advisories) is to block 2049 at the perimeter and restrict it to trusted hosts; only NFSv4 with Kerberos (krb5p) supplies authentication and encryption.
- IANA assignment
nfs— "Network File System - Sun Microsystems"; reference (blank — no RFC cited in the IANA UDP row; [RFC5665] applies to 2049/sctp only); assignee/contact Brent Callaghan; dual-registered 2049/tcp + 2049/udp [Confirmed] — IANA Service Name and Transport Protocol Port Number Registry- Registration/modification date
- Unknown — blank in the IANA registry for both 2049/udp rows; not recorded [Confirmed] — IANA registry CSV
- Range class
- registered (1024–49151)
- Related ports
- 111 (RPC portmapper/rpcbind), 2049/tcp (same nfs+shilp registration), 2049/sctp ([RFC5665])
Primary use
Network File System (NFS) distributed file sharing over RPC; UDP transport associated with NFSv2/NFSv3 (NFSv4 is TCP-only on 2049, no portmapper)
Common software
Linux kernel NFS server (nfsd), NFSv3/v4 clients on Linux/macOS/Windows (Services for NFS), Red Hat Enterprise Linux NFS, NetApp ONTAP NFS, IBM Spectrum Scale (GPFS), FreeBSD NFS
Security implications
NFSv2/v3 over UDP have no native auth/encryption; access rests on spoofable client UID/GID and cleartext on the wire; ~1.5M internet-exposed NFS servers, 37.34% with mountable exports and ~35% no_root_squash in a 3,369-host sample; unauthenticated showmount -e export enumeration
Notable CVEs
implementation-level (e.g. CVE-2018-1002101 Kubernetes NFS privilege escalation; CVE-2017-17741, CVE-2017-15265 Linux kernel NFS issues); most exposure stems from configuration weaknesses (wildcard exports, no_root_squash) rather than numbered CVEs
- Registry conflict
- a second registration
shilpshares 2049/udp (and 2049/tcp); registry flags "== NOTE Conflict on 2049 !";shilphas no description/assignee/dates/reference [Confirmed] — the IANA Service Name and Transport Protocol Port Number Registry - Dependent service
- NFSv2/v3 negotiation requires the RPC portmapper/rpcbind on port 111 [Likely] — Red Hat NFS reference guide; IBM Storage Scale firewall docs
- Security posture
- block 2049 at the perimeter; restrict to trusted IPs; prefer NFSv4 + Kerberos (krb5p) for auth/encryption; never reachable from the public internet [Likely] — UK NCSC/security.gov.uk open-port-2049 guidance; Huntress
- Analyst note
- A reachable 2049/udp from untrusted space is a high-risk finding — enumerate exports, check for no_root_squash and wildcard rules, and confirm whether the host is on legacy NFSv2/v3.
Service assignments.
| Name | Protocol | Description | Open frequency |
|---|---|---|---|
| nfs | UDP | networked file system | 4.45% |
| nfs | TCP | networked file system | 0.61% |
| nfs | SCTP | shilp | 0.00% |
Service assignments from the IANA Service Name and Transport Protocol Port Number Registry, with open-frequency data from nmap-services.