CVE-2026-97854 · Yamaha NWR100 Wireless LAN Router pre-auth OS command injection via…

01 · The Real Story

Like leaving the master key under the doormat, except the door only faces the living room — not the street

CVE-2026-97854 is an unauthenticated OS command injection in the Yamaha NWR100 wireless LAN router, affecting all firmware through Rev.26.00.07. An attacker who can reach the device's web management GUI can send a single specially crafted HTTP request to execute arbitrary OS commands — no credentials, no session token, no user interaction. The NWR100 is a SOHO-class device sold exclusively in Japan, targeting small offices with up to 20 users and 30 devices. It launched in September 2025. Yamaha holds the #1 SOHO router vendor share in Japan (IDC 2025, 22nd consecutive year), but cumulative shipments across *all* Yamaha network models hit 6 million in 2026 — the NWR100's individual footprint is a small fraction of that. A companion vulnerability, CVE-2026-109822, allows unauthenticated read of exported configuration files and is fixed in the same firmware release.

The vendor CVSS of 9.8 CRITICAL is technically accurate for the vulnerability primitive — pre-auth, low complexity, full CIA impact. But Yamaha's own advisory quietly reveals the context the score ignores: the web GUI is not reachable from the internet by default. WAN-side exploitation requires the administrator to have explicitly port-forwarded the management interface — a non-standard, inadvisable configuration. The realistic attack vector is LAN-adjacent: a device already connected to the Wi-Fi or wired network. This is still serious (any rogue device on the network gets full router takeover with one HTTP request), but it is *not* the 'spray the internet' scenario a 9.8 implies. Yamaha's only prior CVE in this class, CVE-2024-22366 on WLX access points, required authenticated admin access (CVSS 6.8). This NWR100 flaw is considerably worse because it's pre-auth, but the real-world exposure profile does not support CRITICAL for the majority of deployments.

"Pre-auth RCE on a SOHO router, but LAN-only by default — not the internet-facing 9.8 the CVSS implies."

02 · The Attack Path

5 steps from start to impact.

STEP 01

Gain LAN adjacency

The attacker needs network access to the NWR100's management interface. By default, the web GUI is only reachable from the LAN subnet (192.168.100.0/24). The attacker must be connected to the NWR100's wireless or wired network, or must have compromised a device already on that network. Internet-based exploitation requires the rare case where the admin has port-forwarded the web GUI to the WAN — a non-default configuration that Yamaha's own advisory calls out.

Conditions required:

Physical or wireless proximity to the target network, OR a compromised device already on the LAN
Wi-Fi PSK or 802.1X credentials (if wireless), OR wired Ethernet access

Where this breaks in practice:

Default configuration blocks all WAN access to the web management GUI
Wi-Fi authentication (WPA2/WPA3-Personal or Enterprise) required to join the network
Physical access to Ethernet ports implies already being inside the small office

Detection/coverage: 802.1X/RADIUS authentication logs; NWR100 DHCP lease logs for new MAC addresses; wireless association logs

STEP 02

Locate the NWR100 web GUI

The attacker identifies the NWR100's management interface. The default gateway at 192.168.100.1 serves the web GUI over HTTP/HTTPS. The device model is typically identifiable from the login page HTML or HTTP response headers. No authentication is needed to reach the login page. No specialized tooling required — a browser or curl suffices.

Conditions required:

LAN connectivity established (Step 1)
HTTP port 80 or HTTPS port 443 reachable on the gateway address

Where this breaks in practice:

If Yamaha's IP-based access restrictions are configured, only whitelisted source IPs can reach the GUI
Non-default port configurations would require a port scan

Detection/coverage: HTTP access logs on the NWR100; network IDS signatures for management-page fingerprinting

STEP 03

Send crafted HTTP request with injected OS command

The attacker sends a specially crafted HTTP request to the NWR100's web GUI that exploits the CWE-78 command injection flaw. No authentication token, session cookie, or credentials are required — this fires *before* the login check. The exact injection parameter is not publicly disclosed in the JVN advisory, and no proof-of-concept exists. The attack is a single HTTP request with shell metacharacters in a vulnerable parameter.

Conditions required:

HTTP/HTTPS connectivity to the web GUI (Step 2)
Knowledge of the vulnerable parameter and injection syntax (currently undisclosed)

Where this breaks in practice:

No public PoC or exploit code exists as of disclosure date (2026-10-28)
The exact injection point requires independent firmware reverse engineering or parameter fuzzing
Yamaha embedded devices use a custom web server, limiting transferability of generic router exploits

Detection/coverage: WAF-style inspection for shell metacharacters in HTTP parameters (unlikely to exist in a SOHO deployment); anomalous HTTP request patterns in NWR100 logs if logging is enabled

STEP 04

Achieve root-level code execution on the router

The injected command executes in the context of the NWR100's web server process, which on embedded Yamaha routers typically runs as root or an equivalent privileged user. The attacker now has arbitrary command execution on the network boundary device. This grants control over routing tables, DNS relay settings, DHCP configuration, firewall rules, IPsec VPN tunnels, and all traffic passing through the device.

Conditions required:

Successful command injection from Step 3

Where this breaks in practice:

Embedded Linux environment uses BusyBox with limited tooling
Persistent backdoors require knowledge of the NWR100's flash layout and boot sequence
Firmware integrity checks (if any) may detect modifications on reboot

Detection/coverage: Configuration change monitoring via periodic config export and diff; unexpected outbound connections from the router's management IP; syslog anomalies

STEP 05

Post-exploitation: traffic interception and pivot

With root access on the router, the attacker can intercept all plaintext traffic traversing the device, modify DNS responses to redirect users to phishing or malware sites, inject content into unencrypted HTTP sessions, capture credentials from protocols like SMTP/POP3/FTP, and use the router as a pivot point to attack other LAN devices. For a typical NWR100 deployment this compromises the entire small-office network of ≤30 devices.

Conditions required:

Persistent or session-level access to the router OS (Step 4)
Office traffic routes through the compromised NWR100

Where this breaks in practice:

TLS/HTTPS traffic resists passive interception without certificate spoofing
HSTS and certificate pinning limit the effectiveness of DNS hijacking against modern browsers
Small blast radius: ≤20 users and ≤30 devices per NWR100 deployment

Detection/coverage: Certificate transparency monitoring; DNS response anomaly detection; users reporting unexpected certificate warnings; network baseline deviation from traffic analytics

03 · Compensating Control

HIGH 7.2→IGNORE 0.0

SEVERITY REDUCED

Apply firmware Rev.26.00.08 immediately — The definitive fix. Rev.26.00.08 patches both CVE-2026-97854 (command injection) and CVE-2026-109822 (config disclosure). The update is applied via the NWR100 web GUI under Maintenance > Firmware Update. Per the noisgate remediation SLA for HIGH, complete patching within 180 days — but given this is a single-device firmware flash with no dependency chain, treat it as the primary action and deploy within 30 days alongside compensating controls.

HIGH 7.2→LOW 3.5

SEVERITY REDUCED

Restrict web GUI access to specific management IPs — Configure the NWR100's IP-based access control to allow web GUI connections only from 1–2 designated administrator workstations with static IPs. This is Yamaha's recommended workaround from the advisory. It eliminates the 'any LAN device can exploit this' condition — the attacker must now first compromise a specific whitelisted admin machine before reaching the injection point. Deploy within 30 days per the noisgate mitigation SLA for HIGH.

HIGH 7.2→MEDIUM 5.5

SEVERITY REDUCED

Verify no port-forwarding rules expose the web GUI to the WAN — Audit the NWR100's NAT/port-forwarding configuration (Web GUI > Network Settings > Port Forwarding) to confirm no rules forward external traffic to ports 80 or 443 on the router itself. This eliminates the internet attack vector entirely. While the default config already blocks this, explicit verification is required after any configuration changes, especially if VPN or remote management has been set up. Deploy within 30 days per noisgate mitigation SLA.

HIGH 7.2→HIGH 6.5

Enable logging and monitor for anomalous requests to the gateway — Enable HTTP access logging on the NWR100 and forward syslog to a central collector. Monitor for unusual request patterns to the gateway IP — high request volume from non-admin hosts, non-browser User-Agents, URL paths or parameters containing shell metacharacters (;, |, $(), backticks). This provides detection but not prevention. Deploy within 30 days.

What doesn't work

Changing or strengthening the admin password — CVE-2026-97854 is a *pre-authentication* vulnerability. The command injection fires before any credential check, so password strength, rotation, or MFA on the web GUI has zero effect on exploitability.
Placing a WAF or IPS upstream of the router — In a SOHO deployment the NWR100 *is* the network edge. There is no realistic insertion point for a WAF between LAN clients and the router's own management interface without a fundamental network redesign that negates the device's purpose.
Switching management to HTTPS-only — The command injection is in the HTTP request-processing logic, not the transport layer. TLS encrypts the malicious payload in transit but does not sanitize it. The vulnerability is equally exploitable over HTTP and HTTPS.

04 · Intelligence Metadata

The supporting signals.

In-the-wild exploitation	None observed. Not listed in CISA KEV. No reports of active exploitation from JPCERT/CC, Yamaha, or any threat intelligence feed as of disclosure date (2026-10-28). Yamaha routers are not a common target for mass-exploitation campaigns.
Proof-of-concept	None public. No PoC found on GitHub (no repos named after CVE-2026-97854), ExploitDB, or nuclei templates. The exact injection parameter is undisclosed in the JVN advisory. Exploitation requires independent reverse engineering of NWR100 firmware images.
EPSS score	Not yet scored. CVE published 2026-10-28; FIRST EPSS API returns empty data (`total: 0`). Expect initial scoring within 1–3 days. Given the niche product, Japan-only market, and absence of public PoC, anticipate a low EPSS percentile (<10th).
KEV status	Not listed in the CISA Known Exploited Vulnerabilities catalog as of 2026-10-29.
CVSS v3.1 vector	`CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H` = 9.8 CRITICAL. The AV:N rating is technically valid (reachable over IP from the LAN) but misleading for risk — the management interface defaults to LAN-only. A realistic Environmental override using AV:A (Adjacent) yields 8.8, which better reflects the default exposure.
CVSS v4.0 score	`CVSS:4.0/AV:N/AC:L/AT:N/PR:N/UI:N/VC:H/VI:H/VA:H/SC:N/SI:N/SA:N` = 9.3 CRITICAL. Same caveat — no Environmental or Threat metrics applied for the LAN-only default or the absence of exploit code.
Affected versions	Yamaha NWR100 firmware Rev.26.00.07 and all earlier revisions. The NWR100 launched September 2025 with initial firmware, so every unit shipped before the fix is affected. No other Yamaha models (RTX, NVR, WLX, SWX series) are impacted.
Fixed version	Rev.26.00.08 — originally released 2026-07-01 to add IPsec/IKEv2 site-to-site VPN. The JVN advisory confirms this revision as the security fix. The companion CVE-2026-109822 (config file disclosure, CVSS 6.5) is also patched in this release. No distro backports apply — this is proprietary Yamaha firmware updated via the web GUI.
Exposure footprint	Minimal internet exposure. No Shodan, Censys, or GreyNoise signatures found for the NWR100. Web GUI is LAN-only by default; WAN exposure requires explicit port forwarding. Product is Japan-market-only SOHO. Yamaha holds #1 SOHO router vendor share in Japan (IDC Japan 2025) across all models, with 6M cumulative device shipments company-wide — NWR100-specific unit counts are not public but represent a small fraction given its Sep 2025 launch.
Reporter	Chuya Hayakawa of 00One, Inc., reported to JPCERT/CC under coordinated disclosure. JPCERT/CC coordinated with Yamaha Corporation. Published 2026-10-28.

Sources.

05 · The Call

Final Verdict

↓ DOWNGRADED to HIGH (7.2/10)

Why this verdict

Default LAN-only management interface eliminates the internet attack surface — Yamaha's own advisory confirms the web GUI is unreachable from the WAN in default configuration. Port-forwarding the management interface externally is required for remote exploitation — a non-standard, inadvisable setup that likely applies to <1% of NWR100 deployments. This converts the effective attack vector from AV:N (9.8) to AV:A (8.8) for the vast majority of installations, a full tier reduction in reachability.
No public PoC, no exploitation, undisclosed injection point — Zero proof-of-concept code exists on GitHub, ExploitDB, or aggregator sites. The JVN advisory does not disclose the vulnerable parameter. Weaponization requires firmware reverse engineering of a niche Japanese SOHO device, materially raising the practical attack complexity above CVSS AC:L. No KEV listing, no threat-intel sightings, EPSS not yet scored but expected low.
Niche installed base caps the addressable target population — The NWR100 is a Japan-market-only SOHO router launched September 2025, priced at ~¥60,000. Even with Yamaha's dominant Japanese SOHO market share, the NWR100's individual unit count is a small fraction of their 6M cumulative all-model shipments. The global internet-facing population is effectively zero by default.
SOHO-class blast radius constrains post-exploitation impact — Each NWR100 serves ≤20 users and ≤30 devices. Compromise yields traffic interception and pivot capability for a single small office, not fleet-scale or enterprise-scale impact. There is no domain controller, no centralized identity system, and no supply-chain artifact behind this device.
Role multiplier: The NWR100 is a SOHO wireless LAN router for small Japanese offices. It does *not* occupy a high-value deployment role from the catalog: it is not an enterprise perimeter appliance (FortiGate, F5, Palo Alto class), not an identity provider, not a hypervisor, not a CI/CD system, and not a backup target. (a) *Low-value role* — home/personal use: blast radius is one household, chain succeeds from Wi-Fi. (b) *Typical role* — small office gateway for ≤20 people: chain succeeds from LAN, outcome is full traffic interception for that office (host → local network). (c) *High-value role* — none applicable; the NWR100 is not canonically deployed in any high-value-role position. The worst plausible outcome is 'full control of one small office network,' which does not reach domain-takeover, fleet-compromise, or supply-chain-scale. The CRITICAL floor does not apply. The HIGH floor is appropriate given the pre-auth RCE primitive on a network boundary device.

Why not higher?

CRITICAL would require either internet-facing exposure by default (the web GUI is LAN-only) or a deployment role where compromise cascades beyond a single small office. The NWR100 is not an enterprise edge appliance managing thousands of sessions — it is a SOHO box for 20 people in Japan. With no PoC, no exploitation in the wild, an effective attack vector of Adjacent rather than Network, and a blast radius capped at ≤30 devices, the urgency does not warrant CRITICAL despite the genuinely dangerous pre-auth primitive.

Why not lower?

Pre-authentication command injection on a network boundary device cannot be MEDIUM regardless of exposure constraints. From the LAN, any connected device — a compromised phone, a rogue IoT sensor, an evil-twin guest, a malware-infected laptop — achieves full router takeover with a single unauthenticated HTTP request requiring no user interaction. Router compromise enables DNS hijacking, traffic interception, credential harvesting, and lateral movement for the entire office. The zero-click, zero-auth nature of the exploit and the network-pivoting capability of the target device keep this firmly at HIGH.

06 · Verification

Crowdsourced verification payload.

Run from any workstation on the same LAN as the NWR100 (typically the 192.168.100.0/24 subnet). Usage: bash check_cve_2026_97854.sh 192.168.100.1. Requires curl; optionally uses snmpget (from net-snmp) as a fallback. No elevated privileges needed — the script performs only HTTP GET and SNMP read operations against the target router.

noisgate-verify.sh

BASHREAD-ONLYSAFE

#!/usr/bin/env bash
# CVE-2026-97854 Checker - Yamaha NWR100 firmware version audit
# Determines whether the target NWR100 is vulnerable to pre-auth
# OS command injection (CWE-78).
#
# Output: VULNERABLE (exit 1) / PATCHED (exit 0) / UNKNOWN (exit 2)
# -------------------------------------------------------------------
set -uo pipefail

TARGET="${1:?Usage: $0 <NWR100_IP_ADDRESS>}"
FIXED="26.00.08"

echo "[*] CVE-2026-97854: Checking Yamaha NWR100 at ${TARGET} ..."

FW=""

# --- Attempt 1: HTTP login page (often shows firmware version) ---
BODY=$(curl -sk --connect-timeout 5 --max-time 10 "http://${TARGET}/" 2>/dev/null) || true
if [ -n "$BODY" ]; then
  FW=$(echo "$BODY" | grep -oP 'Rev\.\d+\.\d+\.\d+' | head -1) || true
fi

# --- Attempt 2: HTTPS fallback ---
if [ -z "$FW" ]; then
  BODY=$(curl -sk --connect-timeout 5 --max-time 10 "https://${TARGET}/" 2>/dev/null) || true
  if [ -n "$BODY" ]; then
    FW=$(echo "$BODY" | grep -oP 'Rev\.\d+\.\d+\.\d+' | head -1) || true
  fi
fi

# --- Attempt 3: SNMP sysDescr ---
if [ -z "$FW" ] && command -v snmpget &>/dev/null; then
  echo "[*] HTTP did not reveal version; trying SNMP (community=public) ..."
  SNMP_OUT=$(snmpget -v2c -c public -t 3 -r 1 "${TARGET}" \
    1.3.6.1.2.1.1.1.0 2>/dev/null) || true
  FW=$(echo "$SNMP_OUT" | grep -oP 'Rev\.\d+\.\d+\.\d+' | head -1) || true
fi

if [ -z "$FW" ]; then
  echo "[!] Could not determine firmware version automatically."
  echo "[!] Log in to the Web GUI > System Information to check manually."
  echo "[!] Vulnerable: Rev.26.00.07 and earlier.  Fixed: Rev.${FIXED}"
  echo "RESULT: UNKNOWN"
  exit 2
fi

echo "[*] Detected firmware: ${FW}"
VER=$(echo "$FW" | grep -oP '\d+\.\d+\.\d+')

# Compare detected version against the fixed version using sort -V
LOWEST=$(printf '%s\n%s' "$VER" "$FIXED" | sort -V | head -1)

if [ "$LOWEST" = "$FIXED" ]; then
  echo "[+] Firmware ${FW} >= Rev.${FIXED} -- patched."
  echo "RESULT: PATCHED"
  exit 0
else
  echo "[-] Firmware ${FW} < Rev.${FIXED} -- VULNERABLE"
  echo "[-] CVE-2026-97854: Pre-auth OS command injection (CWE-78)"
  echo "[-] Update to Rev.${FIXED} immediately."
  echo "RESULT: VULNERABLE"
  exit 1
fi