tenable:50686 · IP Forwarding Enabled

01 · The Real Story

Like flagging that someone left a hallway door propped open, while ignoring that both ends of the hallway lead to locked rooms

Tenable plugin 50686 (CVE-1999-0511) detects that the kernel-level IP forwarding flag (net.ipv4.ip_forward=1 on Linux, IPEnableRouter=1 on Windows) is enabled on a host that is not explicitly a router or firewall. When enabled, the OS will relay IP packets between its network interfaces, potentially allowing an attacker on an adjacent segment to route traffic through the host and bypass network-level access controls. The CVE dates to 1997 and applies to every version of Linux, Windows, and macOS ever shipped — it is a configuration state, not a code defect. Tenable scores it CVSS v3 6.5 (AV:A/AC:L/PR:L/UI:N/S:C/C:L/I:L/A:L), while the NVD inexplicably lists a 9.1.

Tenable's MEDIUM is already generous, and the NVD's 9.1 is indefensible. The CVSS vector correctly marks the attack vector as Adjacent (AV:A) — the attacker must already be on the same L2 segment. It also requires the host to be multi-homed (multiple NICs bridging distinct network zones) for forwarding to mean anything; a single-NIC server forwards packets right back where they came from. Most critically, Docker, Kubernetes, WireGuard, and all container orchestration platforms require ip_forward=1 to function — meaning a large percentage of flagged hosts are operating exactly as designed, not misconfigured. This finding belongs in your CIS hardening audit, not your vulnerability patch queue.

"A 27-year-old config hardening flag, not a weaponizable vulnerability — treat as backlog hygiene."

02 · The Attack Path

4 steps from start to impact.

STEP 01

Attain adjacent network access

The attacker must already be positioned on the same Layer 2 network segment as one of the target host's interfaces. This means either physical access to the LAN, compromise of another host on the same VLAN, or access through a VPN that terminates on the same segment. Without adjacent access, the IP forwarding state is completely irrelevant — remote attackers on the internet cannot exploit this.

Conditions required:

Adjacent L2 network access to the target host
Knowledge of the target host's IP address(es) on the local segment

Where this breaks in practice:

Requires prior compromise or physical presence — this is a post-initial-access technique, not an initial access vector
Modern 802.1X/NAC will block unauthorized devices from joining the segment

Detection/coverage: Network anomaly detection (unexpected ARP entries, traffic from non-inventoried MACs) can flag the prerequisite access.

STEP 02

Identify multi-homed target with forwarding enabled

The attacker must discover a host with IP forwarding enabled that has interfaces in two or more distinct network segments — one the attacker can reach, and one containing the desired target network. A host with a single NIC or multiple NICs on the same VLAN provides no pivoting value. The attacker typically discovers this via TTL analysis, traceroute behavior, or ARP scanning.

Conditions required:

Target host must be multi-homed across distinct network zones
IP forwarding must be enabled on that host

Where this breaks in practice:

The vast majority of servers are single-homed; multi-homed non-router hosts are rare in modern flat or microsegmented networks
Docker/K8s hosts are multi-homed only in a virtual-bridge sense — their forwarding routes to container networks, not to other corporate segments

Detection/coverage: Asset inventory showing multi-homed hosts; Tenable plugin 50686 itself identifies the forwarding state.

STEP 03

Craft and inject routed packets

The attacker crafts packets with destination IPs on the far-side network and sends them to the multi-homed host, relying on its kernel to forward them. This allows the attacker to reach hosts on a segment they could not otherwise access, potentially bypassing firewall rules or NAC policies that only applied at the segment boundary the attacker just circumvented.

Conditions required:

No host-based firewall rules (iptables/nftables/Windows Firewall) blocking forwarded traffic
No network-level ACLs on the destination segment rejecting traffic sourced from unexpected IPs
Destination hosts must accept and respond to the forwarded traffic

Where this breaks in practice:

Host-based firewalls (even default iptables rules) typically do not forward arbitrary traffic even when ip_forward=1 — explicit FORWARD chain rules are required
Destination segment switches/routers will often drop traffic from unexpected source IPs (reverse path filtering, uRPF)
Modern microsegmentation (Illumio, Guardicore, VMware NSX) blocks lateral movement independent of host forwarding state

Detection/coverage: IDS/IPS signatures for unexpected source IPs on destination segments; NetFlow anomaly detection for traffic patterns that should not traverse a non-router host.

STEP 04

Exploit the pivoted access

Once the attacker can route packets to the previously unreachable segment, they use standard reconnaissance and exploitation techniques against hosts on that segment. The IP forwarding itself provides no code execution, no credential theft, and no privilege escalation — it only provides network-level reachability to a segment the attacker was previously isolated from.

Conditions required:

Exploitable services on the destination network
Lack of additional authentication/authorization controls on destination hosts

Where this breaks in practice:

The attacker still needs a separate vulnerability to compromise anything on the destination segment
EDR, host firewalls, and authentication requirements on destination hosts are unaffected by the pivot

Detection/coverage: Standard endpoint detection on destination segment hosts; SIEM correlation of connection sources against expected traffic patterns.

03 · Intelligence Metadata

The supporting signals.

In-the-Wild Exploitation	No known active exploitation campaigns. This is a configuration state, not a weaponized vulnerability. No threat actor campaigns reference CVE-1999-0511 as an attack vector. Not listed in CISA KEV.
PoC / Exploit Availability	No meaningful PoC exists because the "exploit" is simply having IP forwarding enabled. There is no code to run — the kernel does the forwarding natively. One GitHub repo tangentially references the CVE but provides no weaponized tooling.
EPSS Score	6.96% probability of exploitation in 30 days, 93.89th percentile. The high percentile is misleading — EPSS models struggle with ancient configuration-class CVEs. The score reflects the CVE's age and ubiquity, not genuine exploit activity.
KEV Status	Not listed in CISA Known Exploited Vulnerabilities catalog. No federal remediation deadline applies.
CVSS Vectors	Tenable: `CVSS:3.0/AV:A/AC:L/PR:L/UI:N/S:C/C:L/I:L/A:L` → 6.5 Medium. NVD: `CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:N/A:H` → 9.1 Critical (demonstrably wrong — AV:N is incorrect for an adjacent-only finding). Tenable VPR: 6.3.
Affected Versions	Every version of Linux, Windows, and macOS with IP forwarding enabled. This is a kernel configuration flag, not a version-specific software defect.
Fixed Version	N/A — there is no patch. Remediation is a configuration change: set `net.ipv4.ip_forward=0` (Linux), `IPEnableRouter=0` (Windows), or `net.inet.ip.forwarding=0` (macOS). Caution: disabling this will break Docker, Kubernetes, WireGuard, and any VPN/routing functionality.
Scanning / Exposure Data	IP forwarding is not directly observable from internet scanning (Shodan/Censys/GreyNoise) because it only affects traffic through the host, not to the host. The finding is only detectable via authenticated/credentialed scanning (Tenable plugin type: remote, but relies on packet TTL analysis from adjacent positions).
Disclosure Date	1997-01-01 — this finding is 29 years old. It predates the modern CVE numbering system.
False Positive Rate	Extremely high in containerized environments. Docker enables `ip_forward=1` automatically on startup. Kubernetes requires it for pod networking. Any host running containers will trigger this plugin regardless of security posture. Expect 30–60% of flagged hosts to be legitimate container/orchestration hosts.

Sources.

04 · The Call

Final Verdict

↓ DOWNGRADED to LOW (3.0/10)

Why this verdict

Adjacent access requirement (AV:A): The attacker must already be on the same L2 network segment. This is a post-initial-access condition that immediately excludes all remote/internet-based attack scenarios and implies the attacker has already achieved a more serious compromise than IP forwarding alone represents.
Multi-homed prerequisite: For IP forwarding to provide any pivoting value, the host must have interfaces in two or more distinct network zones. Single-NIC hosts (the vast majority of enterprise servers and workstations) provide zero exploitation value even with forwarding enabled. This narrows the exploitable population to <5% of flagged hosts.
No direct impact — forwarding is a transport, not a weapon: IP forwarding provides no code execution, no credential theft, no privilege escalation, and no data exfiltration. It only provides network reachability. The attacker still needs a *separate* vulnerability on the destination segment to achieve any meaningful impact. Scoring this as a standalone vulnerability overstates its value.
Massive false positive rate from containers: Docker and Kubernetes *require* ip_forward=1. In any enterprise running containers (which is most of them in 2026), 30–60% of flagged hosts are operating as designed. This floods vulnerability dashboards with noise and erodes analyst trust.
Role multiplier: IP forwarding is a generic OS kernel flag, not a role-defining component. On workstations (low-value role): nearly always single-NIC, no exploitation value. On container hosts (typical role): forwarding is required and expected — this is a false positive, not a finding. On multi-homed servers bridging management/production networks (high-value role): the chain *could* succeed, but the blast radius is limited to network-level pivoting, not domain takeover, fleet compromise, or data exfiltration. The attacker gains reachability, not control. The worst plausible high-value-role outcome is 'pivot to an adjacent segment' which is a MEDIUM amplifier at best, not a domain/fleet-scale event. This does not trigger the HIGH or CRITICAL floor.
CIS benchmark alignment: CIS correctly flags this as a Level 1 hardening recommendation, which aligns with LOW severity — it should be addressed during standard hardening cycles, not treated as a vulnerability requiring emergency remediation.

Why not higher?

IP forwarding provides no direct compromise capability — it is a transport-layer configuration that enables network pivoting only when combined with adjacent access, a multi-homed host, absent host firewall rules, and a separate exploitable service on the destination segment. Each compounding prerequisite dramatically narrows the realistic attack surface. The worst-case high-value-role scenario (pivoting through a multi-homed server) produces network reachability, not domain takeover or fleet compromise, so the HIGH floor is not triggered.

Why not lower?

While this finding generates enormous false-positive noise from container hosts, there *is* a legitimate security concern when a non-container, multi-homed server has IP forwarding enabled without corresponding firewall rules. CIS benchmarks flag it for a reason. Dismissing it entirely as IGNORE would leave a real (if narrow) hardening gap unaddressed in environments with multi-homed hosts bridging sensitive network zones. A LOW rating ensures it stays in the backlog hygiene queue.

05 · Compensating Control

LOW 3.0→IGNORE 0.0

SEVERITY REDUCED

Suppress findings on container/orchestration hosts — Create a Tenable plugin exception or acceptance rule for plugin 50686 on all hosts tagged as Docker hosts, Kubernetes nodes, or VPN gateways in your CMDB. These hosts *require* ip_forward=1 to function. Suppressing known-good findings reduces dashboard noise by 30–60% and lets analysts focus on genuine issues. No remediation deadline — this is a permanent acceptance.

LOW 3.0→IGNORE 0.5

SEVERITY REDUCED

Deploy host-based firewall FORWARD chain rules on multi-homed hosts — On any non-router multi-homed host where ip_forward must remain enabled, add explicit iptables/nftables FORWARD chain rules that DROP all forwarded traffic except specifically permitted flows. This breaks the attack path at step 3 — even if forwarding is on, the kernel will not relay arbitrary packets. No mitigation SLA for LOW severity — address during standard hardening cycles within the 365-day remediation window.

LOW 3.0→IGNORE 0.0

SEVERITY REDUCED

Disable ip_forward on single-NIC servers not running containers — For the remaining flagged hosts that are single-NIC, non-container servers: disable ip_forward (sysctl -w net.ipv4.ip_forward=0 and persist in /etc/sysctl.d/). This is safe and has no operational impact on single-NIC hosts. Treat as backlog hygiene with no SLA.

LOW 3.0→IGNORE 0.0

SEVERITY REDUCED

Enforce network microsegmentation — Deploy microsegmentation (Illumio, Guardicore, VMware NSX, or cloud security groups) to enforce east-west traffic policies independent of host-level forwarding state. This makes IP forwarding irrelevant as a pivot technique because segment boundaries are enforced at the network fabric, not at host interfaces.

What doesn't work

Patching — there is no patch. This is a configuration state, not a code defect. You cannot 'patch' ip_forward; you either disable it or firewall around it.
WAF / reverse proxy — web application firewalls operate at Layer 7 and have no visibility into Layer 3 IP forwarding behavior. They will not detect or prevent pivoting through a multi-homed host.
Disabling ip_forward globally via GPO/Ansible without exceptions — this will break every Docker host, Kubernetes node, and VPN gateway in your fleet. Do not do this without a per-host exception process.

06 · Verification

Crowdsourced verification payload.

Run this script on each flagged Linux host via SSH or your automation platform (Ansible, Salt, etc.). No root privileges required for the check — it reads sysctl values. Example: bash check_ip_forward.sh. The script identifies whether IP forwarding is enabled, whether the host is multi-homed, and whether containers are running, then outputs a risk-adjusted verdict.

noisgate-verify.sh

BASHREAD-ONLYSAFE

#!/usr/bin/env bash
# check_ip_forward.sh — noisgate verification for Tenable plugin 50686
# Run on: target Linux host (no root required)
# Outputs: VULNERABLE / PATCHED / ACCEPTABLE / UNKNOWN

set -euo pipefail

FWD_V4=$(sysctl -n net.ipv4.ip_forward 2>/dev/null || echo "unknown")
FWD_V6=$(sysctl -n net.ipv6.conf.all.forwarding 2>/dev/null || echo "0")
NIC_COUNT=$(ip -o link show up | grep -cv lo)
HAS_DOCKER=$(pgrep -x dockerd >/dev/null 2>&1 && echo "yes" || echo "no")
HAS_K8S=$(pgrep -x kubelet >/dev/null 2>&1 && echo "yes" || echo "no")
HAS_WIREGUARD=$(ip link show type wireguard 2>/dev/null | grep -q . && echo "yes" || echo "no")

echo "=== noisgate: IP Forwarding Check (plugin 50686) ==="
echo "IPv4 forwarding: $FWD_V4"
echo "IPv6 forwarding: $FWD_V6"
echo "Active NICs (excl lo): $NIC_COUNT"
echo "Docker running: $HAS_DOCKER"
echo "Kubelet running: $HAS_K8S"
echo "WireGuard interfaces: $HAS_WIREGUARD"
echo "================================================="

if [ "$FWD_V4" = "unknown" ]; then
    echo "UNKNOWN — could not read sysctl values"
    exit 2
fi

if [ "$FWD_V4" = "0" ] && [ "$FWD_V6" = "0" ]; then
    echo "PATCHED — IP forwarding is disabled (both v4 and v6)"
    exit 0
fi

# Forwarding is enabled — check if it's expected
if [ "$HAS_DOCKER" = "yes" ] || [ "$HAS_K8S" = "yes" ] || [ "$HAS_WIREGUARD" = "yes" ]; then
    echo "ACCEPTABLE — IP forwarding enabled but required by container/VPN workload"
    echo "ACTION: Suppress Tenable plugin 50686 for this host; verify FORWARD chain rules."
    exit 0
fi

if [ "$NIC_COUNT" -le 1 ]; then
    echo "VULNERABLE — IP forwarding enabled on single-NIC host (low risk, no pivot value)"
    echo "ACTION: Disable with: sudo sysctl -w net.ipv4.ip_forward=0"
    exit 1
fi

# Multi-homed, no containers — this is the real finding
echo "VULNERABLE — IP forwarding enabled on multi-homed host ($NIC_COUNT NICs, no container workload)"
echo "ACTION: Disable forwarding or add FORWARD chain DROP rules. This host can be used as a network pivot."
exit 1

Peer Review

What defenders are saying.

Submit a review attribution: handle + country only

0 flags selected · stored anonymously