Skip to main content
Default Ports: 111 (RPC/portmapper), 2049 (NFS) NFS lets a Unix/Linux host mount another machine’s directory as if it were local, and it’s one of the few services where misconfiguration alone, with no exploit and no credentials, can hand over full root access to a target. The whole trust model is built around the client’s own UID, which is exactly where it tends to fall apart.

RPC / Portmapper (111)

NFS doesn’t listen on a fixed port for every function. Portmapper tells a client which port a specific NFS service (mounting, locking, etc.) is actually running on.

NFS Service (2049)

Where the actual file-sharing happens once a client knows which share to mount and has permission to do so.
NFS has no concept of usernames or passwords. Access is controlled entirely by UID/GID, and trust in the client’s claimed UID is the root of almost every NFS misconfiguration covered below.

​
How NFS Trust Actually Works

Unlike SMB, NFS doesn’t ask for a login at all. When a client mounts a share, the NFS server trusts whatever UID and GID the client’s own OS reports for the connecting user, and grants file access based on matching that UID against the file’s ownership on the server. In practice, this means if you can set your own user’s UID on your attacking machine to match a UID that has access on the target (often simply 1000, the first regular user on most Linux installs, or 0 for root), the server will treat you as that user without ever checking a credential.
The no_root_squash export option is the single most important misconfiguration to look for. By default NFS maps a connecting root user (UID 0) down to an unprivileged “nobody” account, a protection called root squashing. If no_root_squash is set on an export, that protection is disabled and a root user on the client is treated as root on the share too.

​
Enumeration

Before mounting anything, find out what’s actually being shared and what permissions apply.
showmount -e lists every export the server is offering along with the IP ranges or hosts allowed to mount each one, which tells you immediately whether a share is open to anyone or restricted to specific hosts.
rpcinfo queries the portmapper directly and lists every RPC service registered on the host, not just NFS, which can reveal other RPC-based services (NIS, rpc.lockd, etc.) worth investigating alongside it. Nmap covers the same ground with NFS-specific scripts layered on top:
The nfs* script category includes nfs-showmount and nfs-ls, which between them list exports and actually browse file contents without ever mounting the share, worth running before touching mount at all.

​
Mounting a Share

Once you know an export exists and nothing’s obviously restricting it, mounting works like any other local filesystem.
-o nolock skips NFS file locking, which avoids a dependency on rpc.statd running and often sidesteps a class of mount errors on misconfigured servers entirely.
List the UID/GID of files inside the mount with ls -la before assuming you have no access. A file owned by a UID other than yours may still be readable or writable if you adjust your own user’s UID to match it.

​
Privilege Escalation via no_root_squash

This is a direct path to root on the NFS server itself when the misconfiguration is present, treat a positive finding as critical.
If an export has no_root_squash set, mounting as root on your attacking machine gives you root-level file operations on the share. The classic technique is dropping a SUID binary into the share from your attacking host, where you control root, then executing it from the target host, where it now runs as root.
The -p flag on bash preserves the elevated privileges from the SUID bit rather than dropping them immediately, without it the shell resets its effective UID back to the invoking user’s.

​
UID Spoofing Without Root

Even without no_root_squash, matching a regular user’s UID can expose their files. Linux lets a local user create and switch to arbitrary UIDs with root privileges on your own attack box, which doesn’t require anything on the target at all.
Any files on the mounted share owned by UID 1000 on the target are now readable as this user, no credentials or vulnerabilities required, just a UID collision.

​
Quick Reference Tools

Hackviser: NFS

Quick-reference pentesting guide for the NFS service.

HackTricks: NFS

Deeper breakdown of NFS enumeration and privilege escalation techniques.
Mounting a share and modifying UID mappings can expose or overwrite real user data on the target. Stick to read-only verification until write access is confirmed to be in scope.