← Back to Feed CACHED · 2026-09-22 02:21:03 · CACHE_KEY tenable:42256
tenable:42256 · CWE-732 · Disclosed 2009-10-26

NFS Shares World Readable

ASSESSED — NOISGATE
Vendor
Reassessed
Verdict:
Do you agree?
01 · The Real Story

This is like leaving every filing cabinet in the building unlocked and the lobby door propped open for anyone with a badge to the floor

Tenable plugin 42256 fires when an NFS server exports one or more shares to * — meaning any host that can reach port 2049 can mount the share without authentication. No exploit is required: a single mount -t nfs target:/share /mnt command gives the attacker full read access to whatever lives on the export. If no_root_squash is also set (a separate but commonly co-occurring misconfiguration), the attacker additionally gets root-equivalent write access and can plant SUID binaries for privilege escalation. This affects all NFS server implementations — Linux nfs-kernel-server, FreeBSD nfsd, Solaris, NetApp ONTAP — wherever /etc/exports or its equivalent contains an entry without host restrictions.

Tenable's own CVSS v3 score is 7.5 HIGH (AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:N/A:N), while the legacy CVSS v2 score is 5.0 MEDIUM — which is likely the source of your '(?)'. The v3 rating is the correct baseline. The vector correctly notes zero-auth, high-confidentiality impact. However, the Network attack vector slightly overstates internet exposure — in practice, port 2049 is almost never internet-facing. The real danger is *internal*: post-initial-access, every compromised workstation or rogue contractor laptop on the same VLAN gets instant access. For enterprises using NFS-backed backup repositories, VMware datastores, or home directories, the data behind those exports is often the crown jewels.

"World-readable NFS is handing every host on the VLAN a master key to your file server."
02 · The Attack Path

5 steps from start to impact.

STEP 01

Discover NFS service on the internal network

The attacker scans the internal subnet for port 111 (rpcbind) and port 2049 (nfsd). Tools like nmap -sV -p 111,2049 <subnet> or Metasploit's auxiliary/scanner/nfs/nfsmount identify live NFS servers in seconds. This is a standard post-compromise reconnaissance step on every internal pentest.
Conditions required:
  • Network access to the target subnet (internal position required — initial access already achieved)
Where this breaks in practice:
  • NFS ports should be firewalled to authorized client IPs only, but flat network architectures make broad reachability common
  • Network micro-segmentation blocks this in mature environments
Detection/coverage: Nmap SYN scans are detectable by IDS/NDR (Zeek, Suricata). Tenable plugin 42256 itself is the primary proactive detection mechanism for the underlying misconfiguration.
STEP 02

Enumerate world-readable exports

The attacker runs showmount -e <target> or queries the mountd RPC program to list all exported shares and their ACLs. Shares exported to * or (everyone) are immediately identified as unrestricted. This reveals both the share paths (e.g., /backup, /home, /vmfs/volumes) and confirms the absence of host-based restrictions. Nmap NSE script nfs-showmount automates this.
Conditions required:
  • Network access to rpcbind (port 111) or NFSv4 port 2049 directly
Where this breaks in practice:
  • NFSv4 can operate without rpcbind, but export enumeration still works against the NFS port
Detection/coverage: showmount queries generate rpcbind/mountd traffic visible to NDR. Auditd can log mountd RPC requests on the server if configured.
STEP 03

Mount the share — no credentials needed

The attacker mounts the world-readable export: mount -t nfs <target>:/export /mnt. Zero credentials required. On NFSv3, the server trusts the client's UID claim entirely — the attacker creates a local user with any UID to impersonate legitimate server users. NFSv4 with sec=krb5 would prevent this, but world-readable exports virtually never use Kerberos authentication.
Conditions required:
  • Root/sudo on the attacker's host to run the mount command
  • NFS client packages installed (standard on any Linux system)
Where this breaks in practice:
  • Windows-based attacker hosts need additional NFS client setup
  • Container-based attack environments may lack mount privileges without --privileged
Detection/coverage: NFS mount events are logged in server-side syslogs via mountd. EDR on the attacker's Linux host would log the mount syscall, but attacker-controlled hosts typically lack EDR.
STEP 04

Read and exfiltrate sensitive data

With the share mounted, the attacker reads files directly. High-value targets include SSH private keys (~/.ssh/id_rsa), application credentials in config files, database dumps on backup shares, VMDK/QCOW2 files on hypervisor datastores, and password files. A single find /mnt -name '*.key' -o -name '*.pem' -o -name 'shadow' -o -name '*.sql' sweeps for credentials. Data exfiltration speed is limited only by network throughput.
Conditions required:
  • The share actually contains sensitive data (extremely common for NFS use cases — backup repos, home dirs, app data)
Where this breaks in practice:
  • File-level POSIX permissions apply based on UID mapping, but UID spoofing on NFSv3 is trivial — create local user with matching UID
Detection/coverage: DLP solutions typically do not monitor NFS wire traffic. Server-side auditd with file-access watch rules is the primary detection path, but rarely configured on NFS exports.
STEP 05

Escalate to root via SUID binary (requires additional misconfig)

If the export is writable AND no_root_squash is enabled in /etc/exports, the attacker copies a SUID root shell: cp /bin/bash /mnt/rootshell && chmod 4755 /mnt/rootshell. Any low-privilege user on the NFS server who executes /export/rootshell -p gets a root shell. This is the textbook Linux privilege escalation documented across OSCP, HackTheBox, and real engagement reports. The chain requires two co-occurring misconfigurations.
Conditions required:
  • Share exported with rw (read-write) permission
  • no_root_squash option explicitly set in /etc/exports
  • No nosuid mount option on the server-side mount of the underlying filesystem
Where this breaks in practice:
  • Root squashing is enabled by default on all major Linux distributions
  • Many production exports are read-only (ro)
  • Server-side nosuid mount option prevents SUID bit from taking effect
Detection/coverage: File integrity monitoring (AIDE, OSSEC, Tripwire) on the NFS export detects new SUID binaries. EDR on the server detects SUID execution from unusual paths.
03 · Intelligence Metadata

The supporting signals.

In-the-Wild StatusNot a CVE — this is a perennial misconfiguration finding. NFS world-readable exports are exploited routinely in internal penetration tests and red team engagements. MITRE ATT&CK maps exploitation to T1039 (Data from Network Shared Drive) and discovery to T1135 (Network Share Discovery).
PoC / ToolingNo exploit code needed — mount -t nfs is the entire proof of concept. Metasploit auxiliary/scanner/nfs/nfsmount automates discovery. Nmap NSE scripts nfs-showmount and nfs-ls enumerate exports and contents without even mounting.
EPSS ScoreN/A — no CVE identifier assigned. This is a configuration audit finding, not a software vulnerability.
KEV StatusN/A — not CVE-tracked, not in CISA KEV catalog. However, NFS misconfiguration is referenced in CISA's network security best practices.
CVSS VectorTenable assigns CVSS:3.0/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:N/A:N → 7.5 HIGH. Legacy CVSS v2: AV:N/AC:L/Au:N/C:P/I:N/A:N → 5.0 MEDIUM. The v3 score is the authoritative baseline. The vector does not account for the write+privesc chain when no_root_squash is present.
Affected VersionsAll NFS server implementations across all versions — Linux nfs-kernel-server, FreeBSD nfsd, Solaris nfsd, AIX nfsd, NetApp ONTAP, EMC Isilon — wherever the export configuration contains entries without host restrictions (exported to * or empty client list).
Fixed VersionsN/A — this is a configuration fix, not a software patch. Add host-based ACLs to /etc/exports entries: e.g., /data 10.1.2.0/24(ro,root_squash). Then exportfs -ra to apply.
Exposure DataShodan queries for port:2049 consistently show hundreds of thousands of internet-facing NFS servers globally. Internal enterprise exposure is orders of magnitude larger — most orgs with 10k+ hosts have 5–50 NFS servers, many carrying legacy world-readable exports from initial deployment.
Disclosure DateTenable plugin published 2009-10-26, last updated 2024-02-21. The underlying misconfiguration class predates the plugin by decades — NFS world-readability has been a known issue since NFS v2 in the 1980s.
Cross-Scanner CoverageThis finding is detected by all major scanners: Qualys (QID 38116 family), Rapid7 InsightVM/Nexpose NFS checks, OpenVAS NFS tests, and manual showmount -e verification. Broad scanner consensus on the risk.
04 · The Call

Final Verdict
UPGRADED to HIGH (7.0/10)

Why this verdict

  • Zero-authentication access: The attack requires nothing beyond network reachability to port 2049. No credentials, no exploitation framework, no user interaction — just mount -t nfs. This is the absolute lowest possible attack complexity for data access.
  • Internal network is not a meaningful barrier: While NFS is rarely internet-facing, 'requires internal network access' is not high friction in enterprise threat models. Any phished workstation, compromised VPN session, rogue contractor, or malware beachhead provides this position. Post-initial-access, NFS shares with * exports are among the *first* things adversaries and pentesters enumerate — this is day-one lateral movement.
  • Role multiplier: NFS commonly serves high-value data roles: (1) VMware ESXi NFS datastores — world-readable means VMDK theft, full VM cloning, host-to-fleet escalation; (2) Backup repositories (Veeam, Commvault, NetBackup NFS targets) — world-readable means complete data breach of all backed-up systems; (3) /home directory exports — SSH key theft enables fleet-wide lateral movement; (4) Kubernetes NFS-backed PersistentVolumes — container secret and application data exposure. An estimated 20–40% of enterprise NFS deployments serve at least one of these high-value roles. The blast radius for a world-readable backup or datastore share is tenant-to-fleet scale. This floors the verdict at HIGH.
  • Slight downward score adjustment (7.5 → 7.0): The CVSS v3 vector correctly models C:H/I:N — read-only by default. Without the separate no_root_squash misconfiguration, the attacker gets read access only. This limits the *guaranteed* impact to confidentiality and prevents the SUID privilege escalation path, justifying a minor score reduction from the vendor's 7.5.
  • Confirming HIGH against user-stated MEDIUM: The user's stated MEDIUM likely reflects the legacy CVSS v2 score (5.0). The CVSS v3 score of 7.5 and the real-world exploitation ease (literally zero tooling required) confirm the HIGH bucket. The v2-to-v3 recalibration alone accounts for the discrepancy.

Why not higher?

CRITICAL would require either reliable remote code execution or guaranteed write+privilege-escalation in the default configuration. The default NFS configuration uses root_squash (on) and many exports are read-only, limiting the guaranteed impact to data exfiltration. While devastating for backup and datastore shares, the chain to RCE requires *two* co-occurring misconfigurations (no_root_squash + rw), which drops the *probability* of the worst outcome below the CRITICAL threshold. The floor-case is data breach, not domain takeover.

Why not lower?

MEDIUM would dangerously understate the risk for any environment where NFS serves backup, home directory, or hypervisor datastore roles — which represents the *majority* of enterprise NFS deployments by data volume. Zero-auth read access to backup repositories is functionally equivalent to a data breach notification event. The trivial exploitability (no tooling, no credentials, no user interaction) and the complete absence of any authentication gate make this substantially more dangerous than a typical MEDIUM misconfiguration. Every internal pentest that finds this finding converts it to sensitive data access within minutes.

05 · Compensating Control

What to do — in priority order.

  1. Restrict /etc/exports to specific host IPs or subnets immediately — Replace * entries with specific client CIDR ranges: /data 10.1.2.0/24(ro,root_squash). Run exportfs -ra to reload. This is the definitive fix and is a configuration change — no package update, no reboot, no downtime. Deploy within 30 days per the noisgate mitigation SLA for HIGH findings. Most teams can execute this in hours once the authorized client list is confirmed.
  2. Firewall NFS ports to authorized clients at the host level — Configure iptables/nftables/firewalld on every NFS server to allow ports 111 and 2049 only from known NFS client IPs. This provides defense-in-depth: even if /etc/exports is misconfigured, unauthorized hosts cannot reach the service. Deploy within 30 days alongside the exports fix.
  3. Verify root_squash is set on every export — Run grep -r no_root_squash /etc/exports /etc/exports.d/ on every NFS server. Any match must be removed immediately — root_squash is the default, but legacy configs frequently override it. Eliminating no_root_squash blocks the SUID privilege escalation path entirely. Fix alongside the ACL remediation.
  4. Migrate to NFSv4 with Kerberos authentication — Configure sec=krb5 or sec=krb5p on NFSv4 exports to require Kerberos tickets for mount and file access. This eliminates UID spoofing and unauthorized mounts entirely. This is a more involved change requiring Kerberos infrastructure — plan within the 180-day noisgate remediation SLA for HIGH findings.
  5. Segment NFS traffic into dedicated storage VLANs — Place NFS servers and authorized clients on isolated storage VLANs with inter-VLAN ACLs preventing workstation/user segments from reaching port 2049. This limits the blast radius of any compromised endpoint. Plan as part of network segmentation initiatives within 180 days.
What doesn't work
  • EDR on the NFS server does not prevent unauthorized mounts. NFS mount operations are legitimate kernel-level syscalls handled by the kernel NFS daemon — not user-space malware execution. EDR will not alert on a valid NFS mount request arriving from an unauthorized host.
  • POSIX file permissions on exported directories provide only marginal protection on NFSv3 because the server blindly trusts the client's UID assertions. An attacker with root on their own machine creates a local user with any UID (e.g., useradd -u 1000 fakejoe) and reads files owned by that UID on the share. Only NFSv4+Kerberos defeats this.
  • Encryption in transit (NFS-over-TLS, stunnel, IPsec) protects against passive sniffing but does not enforce authentication or access control. A world-readable export encrypted in transit is still world-mountable by any host — the encryption channel simply prevents eavesdropping on the wire.
  • WAF or reverse proxy is irrelevant — NFS is not an HTTP protocol. No web application firewall can inspect or block NFS traffic on port 2049.
06 · Verification

Crowdsourced verification payload.

Run this script from any Linux host with network access to the target NFS server. Usage: bash check_nfs_world_readable.sh 10.1.2.50. Requires showmount (install via apt install nfs-common or yum install nfs-utils). No root privileges needed for the check itself — it only queries export metadata, it does not mount anything.

noisgate-verify.sh
BASHREAD-ONLYSAFE
#!/usr/bin/env bash
# check_nfs_world_readable.sh — Detect world-readable NFS exports
# noisgate verification script for Tenable plugin 42256
# Usage: bash check_nfs_world_readable.sh <target_ip>
# Exit codes: 1=VULNERABLE, 0=PATCHED, 2=UNKNOWN

set -uo pipefail

TARGET="${1:-}"
if [[ -z "$TARGET" ]]; then
  echo "Usage: $0 <target_ip_or_hostname>"
  echo "Example: $0 10.1.2.50"
  exit 2
fi

# Dependency check
if ! command -v showmount &>/dev/null; then
  echo "UNKNOWN — 'showmount' not found."
  echo "Install: apt install nfs-common (Debian/Ubuntu) or yum install nfs-utils (RHEL/CentOS)"
  exit 2
fi

# Query NFS exports from the target
EXPORTS=$(showmount -e "$TARGET" 2>&1)
RC=$?
if [[ $RC -ne 0 ]]; then
  if echo "$EXPORTS" | grep -qi 'no exports\|no such\|not registered'; then
    echo "PATCHED — NFS server at $TARGET has no exports or NFS is not running."
    exit 0
  fi
  echo "UNKNOWN — Could not query NFS exports on $TARGET (port 111/2049 unreachable?)."
  echo "Error: $EXPORTS"
  exit 2
fi

# Parse for world-readable exports (client list is * or (everyone) or empty)
# showmount -e output format: /path  client1,client2  or  /path  *  or  /path  (everyone)
WORLD_READABLE=$(echo "$EXPORTS" | tail -n +2 | awk '{if ($NF == "*" || $NF == "(everyone)" || NF == 1) print $0}')

if [[ -n "$WORLD_READABLE" ]]; then
  echo "VULNERABLE — World-readable NFS exports found on $TARGET:"
  echo "---"
  echo "$WORLD_READABLE"
  echo "---"
  echo "These exports have no host-based ACL restrictions."
  echo "Fix: Add client restrictions in /etc/exports, then run 'exportfs -ra'."
  exit 1
else
  echo "PATCHED — All NFS exports on $TARGET have host-based ACL restrictions."
  echo "Exports found:"
  echo "$EXPORTS" | tail -n +2
  exit 0
fi
07 · Sources

Peer Review

What defenders are saying.

Submit a review attribution: handle + country only
0 flags selected · stored anonymously
Validation Results

Crowdsourced verification outputs.

Results submitted by users who ran the verification payload against their environment.