IP forwarding is enabled on a machine which is not a router or firewall

CVE-1999-0511 describes a host with IP forwarding enabled even though it is not intended to act as a router or firewall. NVD maps the record to Microsoft Windows NT and Windows 2000, but the underlying condition is broader: any dual-homed or multi-interface system that forwards packets can become an unintended transit point if local policy allows it.

The vendor-style CRITICAL 9.1 scoring does not match operational reality. This is usually a configuration weakness that can aid pivoting or segmentation bypass, not a turnkey unauthenticated compromise; an attacker normally needs internal position, routing influence, and a host that actually sits between useful network segments before this matters.

Why this verdict

• Not a direct compromise primitive: Starting from the supplied 9.1 baseline, this drops hard because the finding does not itself give RCE, auth bypass, or data access; it mainly enables packet transit.
• Requires internal or adjacent positioning: To exploit it in the real world, the attacker usually needs post-initial-access network presence or routing influence, which is a major downward pressure on severity.
• Exposure population is narrow: Only hosts with forwarding enabled *and* useful multi-network placement *and* permissive filtering matter, which is a small subset of enterprise endpoints.
• Modern controls should disrupt the chain: Host firewalls, NAC, segmentation, cloud route controls, and east-west monitoring all add friction before this becomes a meaningful pivot.
• No KEV / no strong exploitation signal: There is no authoritative evidence here that defenders should treat this like an actively weaponized internet-scale bug.

Why not higher?

It is not HIGH or CRITICAL because the attack chain assumes too much: internal adjacency, a transit-capable host, routing influence, and downstream targets that remain reachable through that path. A 9.1-style score treats the configuration like a direct network exploit, which badly overstates both reachability and immediate impact.

Why not lower?

It is not IGNORE because an unintended forwarding host can still collapse segmentation and quietly help lateral movement, especially on admin servers, legacy multi-homed boxes, or poorly understood cloud instances. If you find it on a host straddling sensitive zones, the local business risk can exceed the generic score even though the global CVE deserves a downgrade.

1. Audit forwarding state — Identify systems with IPEnableRouter=1, RRAS enabled, or Linux net.ipv4.ip_forward=1, and confirm they are intentional routers/firewalls. For a LOW verdict there is no mitigation SLA; handle it as backlog hygiene in the next hardening cycle, but do not leave ownership ambiguous.
2. Restrict east-west transit — Use host firewall rules and upstream ACLs so ordinary servers and workstations cannot relay traffic between segments even if forwarding gets enabled. Treat this as configuration hygiene with no SLA for LOW, but prioritize any dual-homed server sitting between user and management networks.
3. Flag multi-homed exceptions — Maintain an allowlist for legitimate routers, VPN concentrators, firewalls, and RRAS systems so the rest can be auto-remediated or escalated. For LOW, there is no formal mitigation deadline, but exception drift should be reviewed during routine network-hardening operations.

Run this on the target Windows host in a PowerShell session. Example: powershell.exe -ExecutionPolicy Bypass -File .\check-cve-1999-0511.ps1; standard user rights are usually enough to read the registry and service state, though admin rights help if local policy is restrictive.

# check-cve-1999-0511.ps1

# Purpose: Detect whether unintended IP forwarding is enabled on a Windows host.

# Output: VULNERABLE / PATCHED / UNKNOWN

# Exit codes: 0=PATCHED, 1=VULNERABLE, 2=UNKNOWN


$ErrorActionPreference = 'Stop'

function Write-Result {
    param(
        [string]$Status,
        [string]$Reason,
        [int]$Code
    )
    Write-Output ("{0}: {1}" -f $Status, $Reason)
    exit $Code
}

try {
    $regPath = 'HKLM:\SYSTEM\CurrentControlSet\Services\Tcpip\Parameters'
    $ipEnableRouter = $null

    try {
        $reg = Get-ItemProperty -Path $regPath -Name IPEnableRouter -ErrorAction Stop
        $ipEnableRouter = [int]$reg.IPEnableRouter
    }
    catch {
        # Missing value usually means disabled / not configured on many systems.

        $ipEnableRouter = 0
    }

    $remoteAccess = Get-Service -Name RemoteAccess -ErrorAction SilentlyContinue
    $serviceStatus = if ($remoteAccess) { $remoteAccess.Status.ToString() } else { 'NotPresent' }
    $serviceStartType = if ($remoteAccess) { (Get-CimInstance Win32_Service -Filter "Name='RemoteAccess'").StartMode } else { 'NotPresent' }

    # Modern Windows can also expose per-interface forwarding state.

    $forwardingEnabled = @()
    try {
        $cmd = Get-Command Get-NetIPInterface -ErrorAction SilentlyContinue
        if ($cmd) {
            $forwardingEnabled = Get-NetIPInterface -AddressFamily IPv4 -ErrorAction Stop | Where-Object { $_.Forwarding -eq 'Enabled' }
        }
    }
    catch {
        $forwardingEnabled = @()
    }

    if ($ipEnableRouter -eq 1) {
        Write-Result -Status 'VULNERABLE' -Reason 'Registry value IPEnableRouter=1' -Code 1
    }

    if ($serviceStatus -eq 'Running') {
        Write-Result -Status 'VULNERABLE' -Reason 'RemoteAccess (RRAS) service is running' -Code 1
    }

    if ($forwardingEnabled.Count -gt 0) {
        $names = ($forwardingEnabled | Select-Object -ExpandProperty InterfaceAlias -Unique) -join ', '
        Write-Result -Status 'VULNERABLE' -Reason ("IPv4 forwarding enabled on interface(s): {0}" -f $names) -Code 1
    }

    if ($serviceStatus -eq 'NotPresent') {
        Write-Result -Status 'PATCHED' -Reason 'IPEnableRouter disabled/missing and no forwarding-enabled interfaces detected' -Code 0
    }

    if (($ipEnableRouter -eq 0) -and ($serviceStatus -ne 'Running')) {
        Write-Result -Status 'PATCHED' -Reason ("IPEnableRouter disabled/missing; RemoteAccess status={0}, start mode={1}" -f $serviceStatus, $serviceStartType) -Code 0
    }

    Write-Result -Status 'UNKNOWN' -Reason 'Unable to determine effective forwarding state conclusively' -Code 2
}
catch {
    Write-Result -Status 'UNKNOWN' -Reason $_.Exception.Message -Code 2
}

Sources

1. MITRE CVE Record
2. NVD CVE Detail
3. CISA Known Exploited Vulnerabilities Catalog
4. FIRST EPSS
5. IBM Security Bulletin: Disable IP forwarding
6. Linux Kernel IP Sysctl Documentation
7. Microsoft Learn: Install Remote Access as a VPN server