← Back to Feed CACHED · 2026-05-17 09:42:19 · cache_key CVE-2025-29912
CVE-2026-0403 · CWE-20 · Disclosed 2026-01-13

Insufficient input validation in NETGEAR Orbi routers

ASSESSED — NOISGATE V0.5
Vendor
Reassessed
Verdict:
01 · The Real Story

This is a loaded nail gun left inside the house, not a sniper rifle pointed in from the street

CVE-2026-0403 is an input-validation bug in multiple NETGEAR Orbi models that can turn an authenticated LAN-side admin action into OS command injection on the router itself. The January 13, 2026 NETGEAR advisory lists affected/fixed trains as RBE970/RBE971 before 9.10.0.2, RBR/RBS750/850/860 before 7.2.8.5, and RBRE/RBSE960 before 7.2.7.15.

NETGEAR's LOW 1.1 label gets the attacker-position friction right but undersells what happens after the gate is opened. Command execution on the edge router is operationally meaningful because it can tamper with DNS, firewalling, and traffic paths, but the chain still requires *both* network adjacency and high privileges, which keeps this out of the urgent internet-worm bucket.

"Real router compromise, but only after LAN access and admin-level foothold narrow the exposed population hard."
02 · The Attack Path

4 steps from start to impact.

STEP 01

Reach the Orbi management plane with a browser or curl

The attacker first needs to be on the same LAN or authenticated Wi-Fi segment as the Orbi, then reach the local admin interface exposed via the gateway IP or orbilogin workflow. NETGEAR's own Orbi login guidance points admins to the local gateway, commonly 192.168.1.1, not an inherently public cloud control plane.
Conditions required:
  • Attacker has Wi-Fi access or physical Ethernet access on the target network
  • The target is one of the affected Orbi models
  • The management interface is reachable from that segment
Where this breaks in practice:
  • This is AV:A, so no broad internet spray-and-pray path unless the admin interface is separately misexposed
  • Guest isolation, VLANs, NAC, and separate IoT SSIDs often block direct reachability to the router admin plane
Detection/coverage: External scanners will mostly miss this because reachability is LAN-side. Exposure discovery is inventory/config based, not pure internet scanning.
STEP 02

Obtain admin-equivalent privileges using the Orbi web UI

The CNA vector uses PR:H, which means the exploit path assumes a high-privilege authenticated context. NETGEAR's earlier Orbi command-injection advisory for a similar class of bug explicitly required the Wi-Fi or Ethernet foothold *and* the admin login/password, which is the practical model to assume here as well.
Conditions required:
  • Valid Orbi admin credentials or an existing admin session
  • No compensating control preventing management-plane access from the attacker's segment
Where this breaks in practice:
  • Requiring admin credentials makes this post-compromise, insider, or rogue-guest friendly rather than initial-access friendly
  • Unique admin passwords, password rotation, and not reusing router creds across sites sharply reduce real-world exploitability
Detection/coverage: Authenticated vulnerability checks can infer exposure from model/firmware. Failed and successful admin logins may show in device logs, but telemetry is limited on SOHO gear.
STEP 03

Send a crafted request through the vulnerable input path with Burp Suite or curl

Once authenticated, the attacker delivers malformed input to the vulnerable parameter and abuses weak validation to break into OS command execution. The public advisory does not publish the exact parameter, which slows commodity exploitation but does not materially protect a determined researcher with firmware-diff capability.
Conditions required:
  • Authenticated admin session is active
  • Target firmware is below the fixed version for that model
Where this breaks in practice:
  • No public vendor write-up of the exact sink means there is some reverse-engineering cost
  • Router appliances typically lack rich crash telemetry, so exploit development is noisier for the attacker than browsering a well-documented web app bug
Detection/coverage: Most commercial scanner coverage here will be version-based, not exploit-confirming. Network IDS rarely has good signatures without the exact vulnerable endpoint.
STEP 04

Use router-level command execution to pivot, persist, or tamper with traffic

With code execution on the Orbi, the attacker can modify DNS behavior, firewall/NAT rules, or local services and use the router as a vantage point into the rest of the site. That is strategically valuable because the router sits in the traffic path, but the blast radius is still usually confined to that home/branch environment rather than an enterprise-wide control plane.
Conditions required:
  • Successful command injection
  • Sufficient shell context on the router OS
Where this breaks in practice:
  • Consumer routers are often auto-updated or replaced faster than long-lived server platforms
  • The compromised asset is high value for one site, but not usually a central shared enterprise service
Detection/coverage: Detection is weak at the device level; defenders are more likely to notice downstream symptoms such as DNS changes, unexpected outbound traffic, or config drift.
03 · Intelligence Metadata

The supporting signals.

In-the-wild statusNo current evidence of active exploitation in the reviewed sources. CISA KEV does not list it, and the CISA ADP vulnrichment attached to the CVE record says Exploitation: none and Automatable: no.
Public exploit / PoCNo public PoC for CVE-2026-0403 was surfaced in the reviewed vendor and public sources. Historical context matters, though: related Orbi bugs in 2023 *did* receive public PoCs, so this class is not exotic.
EPSS0.00083 — extremely low predicted near-term exploitation probability, which matches the narrow attacker position and privilege requirements.
KEV statusNot listed in CISA KEV. Disclosure/publication date in the CNA/NVD ecosystem is 2026-01-13.
CVSS vector reality checkCVSS:4.0/AV:A/AC:L/AT:N/PR:H/UI:N/VC:N/VI:L/VA:N/SC:N/SI:N/SA:N says adjacent-only, low complexity, high privileges, no user interaction. The important truth is not the 1.1; it is the combination of *LAN adjacency + admin auth*.
Affected versionsNETGEAR names these affected product families: RBR750, RBS750, RBRE960, RBSE960, RBR850, RBS850, RBE971, RBE970, RBR860, and RBS860.
Fixed versionsRBE970/RBE971: 9.10.0.2+; RBR/RBS750/850/860: 7.2.8.5+; RBRE/RBSE960: 7.2.7.15+. There are no distro backports here; this is appliance firmware, so fixed means fixed firmware train.
NVD/CNA mismatchNVD enrichment now shows a CVSS v3.1 8.0 HIGH while the CNA record stays at CVSS v4.0 1.1 LOW. Both are incomplete lenses: NVD overstates technical impact in a vacuum, while CNA understates what router command execution means once the prerequisites are met.
Exposure / scanning dataThis flaw is fundamentally LAN-reachable, which crushes population exposure compared with WAN-side router RCE. For context only, a March 23, 2023 Tyler briefing citing a Shodan check said there were *almost 10,000* publicly accessible Orbi devices; even then, exploitation still depended on local access, credentials, or separately exposed admin consoles.
Disclosure / creditPublished by NETGEAR on 2026-01-13; finder credited as fxc233 in the CNA/advisory record.
04 · The Call

noisgate verdict.

Final Verdict
UPGRADED to MEDIUM (4.6/10)

The decisive factor is the double prerequisite: the attacker must already be on the local network *and* hold high privileges on the router admin plane. That narrows the reachable population so sharply that this is not a frontline external-exposure fire drill, but router-level command execution is still too consequential to leave in LOW.

HIGH Prerequisite friction: LAN adjacency plus high privileges materially suppress real-world exploitability
MEDIUM Technical impact after successful exploitation is meaningful router compromise
MEDIUM Public exploitation status: no evidence found, but absence of a PoC today does not prove none exists privately

Why this verdict

  • Start from the vendor's 1.1: NETGEAR correctly encoded the biggest friction points — AV:A and PR:H — which means this is not an unauthenticated internet bug.
  • Add back for real impact: once exploited, this is OS command injection on the router, not a cosmetic config issue. Edge-device execution can alter DNS, routing, firewall rules, and visibility into a local site.
  • Push down for attacker position: requiring LAN/Wi-Fi presence implies post-initial-access, insider, rogue guest, or missegmented network conditions. That cuts the exposed enterprise population dramatically compared with WAN-side router flaws.
  • Push down again for privilege requirement: needing admin-level access means modern basics like unique local creds, guest isolation, and segmentation break the chain before the bug matters.

Why not higher?

There is no credible evidence here of active exploitation, no KEV entry, and no unauthenticated remote path. More importantly, the exploit chain is not generally reachable from the internet and assumes a prior foothold plus privileged router access, which is exactly the kind of compounding friction that should keep a vulnerability out of HIGH/CRITICAL even when the end-state is code execution.

Why not lower?

Calling this LOW would treat router OS command execution as if it were a harmless integrity nick, and that is too charitable. If an attacker already has the needed foothold and credentials, compromise of the network edge is operationally valuable enough to justify a MEDIUM bucket.

05 · Compensating Control

What to do — in priority order.

  1. Block management-plane reachability from untrusted segments — Restrict Orbi admin access to a dedicated admin VLAN or a known management host so guest Wi-Fi, IoT networks, and general user segments cannot hit the router UI. For a MEDIUM verdict there is no noisgate mitigation SLA, so do this as normal hardening while tracking the firmware update inside the 365-day remediation window.
  2. Rotate and uniquify Orbi admin credentials — This exploit path is materially weaker if each site has a unique strong router admin password and no reused shared secret across branches or homes. For MEDIUM, there is no mitigation SLA — go straight to the 365-day remediation window, but credential hygiene should still be folded into the same cleanup cycle.
  3. Disable any unnecessary remote administration exposure — Even though the CVE is LAN-adjacent, separately exposing the admin interface to the internet collapses one layer of friction and makes credential abuse much more dangerous. Audit NAT/UPnP/manual port-forwards and close them during standard hardening, then complete firmware remediation within 365 days.
  4. Turn on auto-update and verify firmware inventory — NETGEAR notes that devices with automatic updates enabled may already have the patch. Use inventory to map model-to-firmware and confirm each appliance reaches the fixed train before the remediation deadline.
What doesn't work
  • WAF does not help much here because the vulnerable surface is the router's own local admin interface, not an internet-facing web app behind a reverse proxy.
  • EDR/AV on endpoints does not protect the router itself and will not stop an authenticated admin request sent directly to the appliance.
  • Perimeter firewalling alone is insufficient if the attacker is already on the allowed LAN/Wi-Fi segment with admin credentials.
06 · Verification

Crowdsourced verification payload.

Run this from an auditor workstation, CMDB export job, or config-management runner after you collect the Orbi model and firmware from the admin UI, API, or inventory source. Invoke it as python3 check_cve_2026_0403.py --model RBR750 --firmware 7.2.8.4; no elevated privileges are needed because it performs an offline version check, not exploitation.

noisgate-verify.py
PYTHONREAD-ONLYSAFE
#!/usr/bin/env python3
# check_cve_2026_0403.py
# Offline firmware assessor for CVE-2026-0403 (NETGEAR Orbi)
# Exit codes: 0=PATCHED, 1=VULNERABLE, 2=UNKNOWN

import argparse
import re
import sys

FIXED = {
    'RBE970': '9.10.0.2',
    'RBE971': '9.10.0.2',
    'RBR750': '7.2.8.5',
    'RBS750': '7.2.8.5',
    'RBR850': '7.2.8.5',
    'RBS850': '7.2.8.5',
    'RBR860': '7.2.8.5',
    'RBS860': '7.2.8.5',
    'RBRE960': '7.2.7.15',
    'RBSE960': '7.2.7.15',
}

AFFECTED = set(FIXED.keys())


def normalize_model(model: str) -> str:
    return re.sub(r'[^A-Za-z0-9]', '', model or '').upper()


def normalize_version(ver: str) -> str:
    v = (ver or '').strip()
    v = v.lstrip('vV')
    return v


def parse_version(ver: str):
    v = normalize_version(ver)
    if not re.fullmatch(r'\d+(?:\.\d+)*', v):
        return None
    return tuple(int(x) for x in v.split('.'))


def compare_versions(a: str, b: str):
    pa = parse_version(a)
    pb = parse_version(b)
    if pa is None or pb is None:
        return None
    max_len = max(len(pa), len(pb))
    pa = pa + (0,) * (max_len - len(pa))
    pb = pb + (0,) * (max_len - len(pb))
    if pa < pb:
        return -1
    if pa > pb:
        return 1
    return 0


def main():
    parser = argparse.ArgumentParser(description='Assess NETGEAR Orbi firmware for CVE-2026-0403')
    parser.add_argument('--model', required=True, help='Router/satellite model, e.g. RBR750')
    parser.add_argument('--firmware', required=True, help='Installed firmware, e.g. 7.2.8.4 or v7.2.8.4')
    args = parser.parse_args()

    model = normalize_model(args.model)
    firmware = normalize_version(args.firmware)

    if model not in AFFECTED:
        print(f'UNKNOWN: model {model} is not in the covered affected-model list for CVE-2026-0403')
        sys.exit(2)

    fixed = FIXED[model]
    cmp_result = compare_versions(firmware, fixed)
    if cmp_result is None:
        print(f'UNKNOWN: unable to parse firmware version "{args.firmware}" for model {model}')
        sys.exit(2)

    if cmp_result < 0:
        print(f'VULNERABLE: {model} firmware {firmware} is below fixed version {fixed} for CVE-2026-0403')
        sys.exit(1)
    else:
        print(f'PATCHED: {model} firmware {firmware} is at or above fixed version {fixed} for CVE-2026-0403')
        sys.exit(0)


if __name__ == '__main__':
    main()
07 · Bottom Line

If you remember one thing.

TL;DR
Monday morning, do not treat this like a perimeter emergency; treat it like a real but narrow post-foothold router compromise risk. Identify every affected Orbi model, confirm whether any admin interfaces are internet-exposed, rotate shared router admin credentials where they exist, and close management reachability from guest or flat user networks as standard hardening; for a MEDIUM verdict there is no noisgate mitigation SLA — go straight to the 365-day remediation window, so your formal deadline is the noisgate remediation SLA of ≤ 365 days to move each device onto the fixed firmware train.

Sources

  1. NETGEAR January 2026 Security Advisory
  2. OpenCVE record for CVE-2026-0403
  3. NVD entry for CVE-2026-0403
  4. NETGEAR Orbi command injection advisory PSV-2022-0188
  5. BleepingComputer on public PoCs for related 2023 Orbi bugs
  6. CISA Known Exploited Vulnerabilities Catalog
  7. FIRST EPSS project
  8. Tyler Cybersecurity daily briefing citing Shodan exposure of Orbi devices
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.