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.
4 steps from start to impact.
Reach the Orbi management plane with a browser or curl
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.- 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
- 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
Obtain admin-equivalent privileges using the Orbi web UI
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.- Valid Orbi admin credentials or an existing admin session
- No compensating control preventing management-plane access from the attacker's segment
- 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
Send a crafted request through the vulnerable input path with Burp Suite or curl
- Authenticated admin session is active
- Target firmware is below the fixed version for that model
- 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
Use router-level command execution to pivot, persist, or tamper with traffic
- Successful command injection
- Sufficient shell context on the router OS
- 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
The supporting signals.
| In-the-wild status | No 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 / PoC | No 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. |
| EPSS | 0.00083 — extremely low predicted near-term exploitation probability, which matches the narrow attacker position and privilege requirements. |
| KEV status | Not listed in CISA KEV. Disclosure/publication date in the CNA/NVD ecosystem is 2026-01-13. |
| CVSS vector reality check | CVSS: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 versions | NETGEAR names these affected product families: RBR750, RBS750, RBRE960, RBSE960, RBR850, RBS850, RBE971, RBE970, RBR860, and RBS860. |
| Fixed versions | RBE970/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 mismatch | NVD 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 data | This 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 / credit | Published by NETGEAR on 2026-01-13; finder credited as fxc233 in the CNA/advisory record. |
noisgate verdict.
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.
Why this verdict
- Start from the vendor's 1.1: NETGEAR correctly encoded the biggest friction points —
AV:AandPR: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.
What to do — in priority order.
- 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.
- 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.
- 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.
- 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.
WAFdoes 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 endpointsdoes not protect the router itself and will not stop an authenticated admin request sent directly to the appliance.Perimeter firewalling aloneis insufficient if the attacker is already on the allowed LAN/Wi-Fi segment with admin credentials.
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.
#!/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()
If you remember one thing.
Sources
- NETGEAR January 2026 Security Advisory
- OpenCVE record for CVE-2026-0403
- NVD entry for CVE-2026-0403
- NETGEAR Orbi command injection advisory PSV-2022-0188
- BleepingComputer on public PoCs for related 2023 Orbi bugs
- CISA Known Exploited Vulnerabilities Catalog
- FIRST EPSS project
- Tyler Cybersecurity daily briefing citing Shodan exposure of Orbi devices
What defenders are saying.
Crowdsourced verification outputs.
Results submitted by users who ran the verification payload against their environment.