NETGEAR WNAP320 `boardDataWW

CVE-2016-1554 is an unauthenticated command injection bug in the NETGEAR ProSAFE WNAP320 access point’s web management stack, specifically the boardDataWW.php handling of the macAddress field. Public reversing and exploit code show the backend validates only that the input *contains* 12 hex characters, then concatenates the whole field into an exec() call. The clearest public proof targets WNAP320 firmware v2.0.3; NETGEAR’s related advisories for the same insecure PHP-form class of bugs indicate WNAP320 fixes arrived in v3.5.5.0 or later, with later PHP-form hardening called out again for v3.5.20.0 and earlier.

In a vacuum this smells like a top-shelf bug: no auth, no user click, straight to command execution on network infrastructure. In the field, though, it is usually *not* an internet-scale crisis because these APs default to a private management IP, live on internal or isolated management segments, and are long-legacy hardware with a comparatively narrow exposed population. That drops it out of CRITICAL, but not out of HIGH: once an attacker reaches the management plane, the exploit path is trivial and the box is theirs.

Why this verdict

• Starts high on raw exploitability: no authentication, no user interaction, and public exploit code gets straight to OS command execution.
• Adjusted downward for attacker position: the attacker generally needs *internal or adjacent network reachability* to the AP management plane, which implies post-initial-access or local-network presence in most enterprise deployments.
• Adjusted downward for exposed population: WNAP320 is an old, EOL access point with a much smaller live footprint than mass-market edge routers or mainstream enterprise VPN/ADC gear.
• Pulled back up by exploit maturity: once reachable, exploitation is low-friction and commodity; a copied PoC or even curl is enough.
• Held at HIGH because of blast potential from network infrastructure: a compromised AP is a meaningful pivot point into wireless segments, management networks, and device credentials even if the single-device blast radius is smaller than a domain controller compromise.

Why not higher?

This does not earn CRITICAL because the hardest part is not payload construction; it is getting to the management interface in the first place. Default private-IP management, internal placement, and legacy product scarcity all compound downward pressure on real-world risk.

Why not lower?

This is still well above MEDIUM because there is no authentication barrier once the target is reachable, and public exploit code removes any meaningful weaponization cost. Old network appliances also tend to be under-monitored, making successful exploitation harder to notice than on a fully managed server.

1. Restrict AP management to an admin VLAN — Apply ACLs so only designated admin jump hosts can reach AP web, SSH, SNMP, and Telnet management paths. For a HIGH verdict, deploy this within 30 days to meet the mitigation deadline and cut off the biggest real-world amplifier: broad internal reachability.
2. Disable unused management services — Turn off HTTP, Telnet, and SNMP where operationally possible, and keep only the minimum management protocol required. Do this within 30 days because every enabled service on a legacy AP increases both discovery surface and post-compromise options.
3. Quarantine or replace EOL WNAP320 units — Move remaining WNAP320 devices into tightly segmented legacy enclaves or replace them outright. Even if firmware is updated, the platform is legacy and should be treated as higher operational debt; begin containment within 30 days and complete actual replacement/upgrade in the remediation window.
4. Alert on boardDataWW.php abuse — Add IDS/WAF/internal proxy signatures for POSTs to /boardDataWW.php containing shell metacharacters in macAddress, and alert on follow-up reads of unexpected files from the AP web root. Stand this up within 30 days to catch exploit attempts while remediation is in progress.
5. Baseline AP egress and east-west traffic — Treat AP IPs as infrastructure identities and alert on unusual DNS, HTTP, SSH, SMB, or lateral movement sourced from them. Implement within 30 days because detection on the appliance itself is weak, so the network is your control plane.

Run this on the target AP over SSH or from a serial/local shell, not from your auditor workstation. Example: ssh [email protected] 'sh -s' < verify_cve_2016_1554.sh; it needs only normal shell access, but root helps if firmware version files are permission-restricted. The script tries several common version locations, extracts a firmware string, and reports VULNERABLE, PATCHED, or UNKNOWN against the conservative fixed threshold 3.5.5.0.

#!/bin/sh
# verify_cve_2016_1554.sh
# Purpose: best-effort local check for NETGEAR WNAP320 firmware level relevant to CVE-2016-1554
# Output: VULNERABLE / PATCHED / UNKNOWN
# Exit codes: 0=PATCHED, 1=VULNERABLE, 2=UNKNOWN

FIXED="3.5.5.0"
VER=""

find_version() {
  for f in \
    /etc/version \
    /etc/fw_version \
    /etc/firmware_version \
    /tmp/firmware_version \
    /tmp/version \
    /etc/banner \
    /etc/issue
  do
    if [ -r "$f" ]; then
      v=$(grep -Eo 'V?[0-9]+\.[0-9]+\.[0-9]+\.[0-9]+' "$f" 2>/dev/null | head -n 1)
      if [ -n "$v" ]; then
        echo "$v"
        return 0
      fi
    fi
  done

  # Broader fallback: search a few likely directories without walking the whole filesystem
  v=$(grep -R -Eho 'V?[0-9]+\.[0-9]+\.[0-9]+\.[0-9]+' /etc /tmp /usr 2>/dev/null | head -n 1)
  if [ -n "$v" ]; then
    echo "$v"
    return 0
  fi

  return 1
}

normalize() {
  echo "$1" | sed 's/^[Vv]//'
}

vercmp() {
  # returns: 0 equal, 1 greater, 2 less
  awk -v A="$1" -v B="$2" '
    function splitver(s, arr,   n,i,tmp) {
      n=split(s,tmp,".")
      for (i=1; i<=4; i++) arr[i]=(i<=n ? tmp[i]+0 : 0)
    }
    BEGIN {
      splitver(A,a); splitver(B,b)
      for (i=1; i<=4; i++) {
        if (a[i] > b[i]) exit 1
        if (a[i] < b[i]) exit 2
      }
      exit 0
    }'
  return $?
}

VER=$(find_version)
if [ -z "$VER" ]; then
  echo "UNKNOWN - firmware version not found"
  exit 2
fi

VER=$(normalize "$VER")
FIXED=$(normalize "$FIXED")

vercmp "$VER" "$FIXED"
RC=$?

if [ $RC -eq 2 ]; then
  echo "VULNERABLE - detected firmware $VER is older than fixed baseline $FIXED"
  exit 1
elif [ $RC -eq 0 ] || [ $RC -eq 1 ]; then
  echo "PATCHED - detected firmware $VER is at or above fixed baseline $FIXED"
  exit 0
else
  echo "UNKNOWN - version comparison failed for detected firmware $VER"
  exit 2
fi

Sources

1. NETGEAR CVE-2016-1555 notification
2. NETGEAR PHP-form vulnerability advisory PSV-2017-0517 / PSV-2016-0258
3. NETGEAR WNAP320 firmware 3.7.9.0 page
4. NETGEAR WNAP320 reference manual
5. Public reverse-engineering writeup for CVE-2016-1554
6. Exploit-DB mirror for EDB-ID 50069
7. NETGEAR enterprise EOL product list
8. CISA Known Exploited Vulnerabilities Catalog