This is like handing a vandal the breaker-room key but only letting them trip one switch
CVE-2026-0400 is a post-authentication format string flaw in SonicWall SonicOS that lets a remote attacker crash the firewall, i.e. a DoS against the security appliance itself. The CNA record lists affected versions as 7.0.1-5169 and older, 7.3.1-7013 and older, and 8.1.0-8017 and older; NVD later mapped vulnerable CPE ranges to builds before 7.3.2-7010 and before 8.2.0-8009 on covered Gen7/Gen8 platforms. SonicWall's 7.3.2 release notes explicitly mention SNWLID-2026-0001 as fixed there.
Reality check: this is not an edge pre-auth firewall disaster. The decisive friction is that exploitation is post-auth with high privileges, which implies the attacker already has admin-level reach into the management plane or equivalent access. The impact is real—crashing a perimeter firewall can hurt operations—but there is no public PoC, no KEV listing, low EPSS, and the blast radius is availability-only, so this lands at = ASSESSED AT MEDIUM.
4 steps from start to impact.
Obtain privileged access to SonicOS management
curl, or Burp Suite against the admin/API surface.- Management interface or API is reachable from the attacker position
- Attacker has valid privileged credentials or an equivalent authenticated session
- Target is running an affected SonicOS build
- MFA, IP allowlists, and private-only management access stop a lot of real deployments here
- Requiring internal-network reach makes this post-initial-access in many enterprises
- High privileges narrow the reachable population far below 'any internet user'
Reach the vulnerable authenticated endpoint
- Authenticated session has permission to access the vulnerable function
- Management/API service is enabled on the target appliance
- The exact vulnerable request path is still present in the installed build
- No public PoC means attackers still have to reverse or rediscover the bug
- Some admins expose SSL VPN publicly but keep management API on trusted ranges only
- Version-only exposure data does not prove the vulnerable feature path is actually reachable
Send crafted payload to trigger the crash
- Exact triggering input is known or rediscovered
- Payload reaches the management parser without normalization blocking it
- Device is vulnerable and not already on a fixed release
- There is no evidence this becomes code execution; current reporting supports crash/DoS only
- Watchdog recovery or HA failover can shrink real outage time
- An attacker already holding admin access has many easier ways to cause pain
Operational impact: firewall outage or failover event
- Target device is active in the traffic path
- HA or clustering does not fully mask the event
- Ops team does not immediately isolate the source or recover the unit
- HA deployments materially reduce blast radius
- Impact is contained to availability; there is no published evidence of persistence, data theft, or privilege expansion
- Enterprise monitoring usually notices perimeter firewall crashes quickly
- A WAF usually does not help because SonicOS management traffic is often not fronted by a separate application proxy, and the attack already occurs after authenticated access reaches the appliance.
- Routine endpoint AV/EDR on user workstations does nothing for the vulnerable parser on the firewall itself.
- Simply changing the external interface IP does not matter if the management surface remains reachable and the attacker already has valid privileged access.
The supporting signals.
| In-the-wild status | No confirmed exploitation found in the sources reviewed. CISA-ADP SSVC marks Exploitation: none and the CVE is not KEV-listed. |
|---|---|
| Public exploit / PoC | No public PoC located across GitHub/web searches reviewed. That is meaningful friction for an authenticated management-plane bug. |
| EPSS | 0.0026 (0.26%) from the user-supplied intel; secondary mirrors place it around the low-40s percentile. Translation: statistically uninteresting compared with the broader CVE pool. |
| KEV status | Not listed in CISA's Known Exploited Vulnerabilities catalog as checked against the catalog source. |
| CVSS interpretation | There is no vendor CVSS baseline. NVD shows N/A for NVD scoring, while CISA-ADP added CVSS:3.1/AV:N/AC:L/PR:H/UI:N/S:U/C:N/I:N/A:H = 4.9 MEDIUM. That vector fits the real-world story: network reachable, easy once reached, but gated by high privileges and limited to availability. |
| Affected versions | CNA/MITRE data lists 7.0.1-5169 and older, 7.3.1-7013 and older, and 8.1.0-8017 and older for SonicOS on Gen7/Gen8 platforms. |
| Fixed versions | Officially observable fix evidence includes SonicOS 7.3.2-7010 in SonicWall release notes. NVD CPE mapping later points to fixed trains 7.3.2-7010 and 8.2.0-8009; confirm exact branch/hotfix entitlement for 7.0.1 and 8.1.x in MySonicWall/PSIRT because the PSIRT page was not machine-readable in-browser. |
| Scanning / exposure telemetry | GreyNoise reported three SonicWall scanning spikes on 2026-01-18, 2026-01-30, and 2026-02-14 that preceded the 2026-02-24 disclosure of CVE-2026-0400. That signals attacker interest in SonicWall management surfaces generally, but it is not proof of exploitation of this CVE. |
| Disclosure timeline | CVE publication: 2026-02-24. NVD page published 2026-02-24 and last modified 2026-02-26, but still showed NVD assessment not yet provided at review time. |
| Researcher / reporting credit | The CNA record credits Vang3lis and Heuzoo of VARAS@IIE as finders. |
Sources.
Why this verdict
- High-privilege prerequisite cuts hard: this is not unauthenticated remote code execution; it requires authenticated, high-privilege access to the management plane, which implies prior compromise, insider position, or badly exposed admin access.
- Impact is availability-only: current public data supports a firewall crash, not code execution, data exposure, persistence, or tenant breakout.
- Exposure population is narrower than it looks: SonicWall appliances are common, but many enterprises keep management access on internal or trusted ranges, and MFA/IP restrictions should block the first step.
- Threat intel is quiet: no KEV, no confirmed public PoC, and very low EPSS all argue against treating this like an active edge emergency.
- Why not LOW: crashing a perimeter firewall still matters; on flat or poorly segmented shops with public management exposure, an attacker with admin access can cause visible business disruption quickly.
Why not higher?
To score higher, this would need at least one strong amplifier: pre-auth reach, broad public exploit availability, confirmed in-the-wild abuse, or impact beyond DoS. None of those showed up. The attack chain starts too far downfield—authenticated and high-privileged—to justify HIGH or CRITICAL.
Why not lower?
Calling this LOW would understate the fact that the target is the firewall itself, not a back-office app. Even a pure crash bug on a perimeter appliance can interrupt VPN, routing, inspection, or administration, especially in single-device deployments without clean HA.
Crowdsourced verification payload.
Run this on an auditor workstation, jump host, or CI job, not on the firewall. Feed it a firmware string gathered from NSM, MySonicWall inventory, or SSH/GUI show version output; example: python3 check_cve_2026_0400.py 7.3.1-7013. No elevated OS privileges are needed—just the target version string.
#!/usr/bin/env python3
# check_cve_2026_0400.py
# Determine likely exposure to CVE-2026-0400 from a SonicOS version string.
# Exit codes:
# 0 = PATCHED
# 1 = VULNERABLE
# 2 = UNKNOWN / unable to classify
import re
import sys
def parse_version(v):
m = re.match(r'^\s*(\d+)\.(\d+)\.(\d+)-(\d+)\s*$', v)
if not m:
return None
return tuple(int(x) for x in m.groups())
def cmp_ver(a, b):
return (a > b) - (a < b)
def classify(vstr):
v = parse_version(vstr)
if v is None:
return ("UNKNOWN", 2, "Version must look like 7.3.1-7013")
# Best-available evidence used:
# - CNA affected: 7.0.1-5169 and older; 7.3.1-7013 and older; 8.1.0-8017 and older
# - NVD CPE mapping: vulnerable before 7.3.2-7010 and before 8.2.0-8009 on covered Gen7/Gen8 models
# Because SonicWall branch entitlement / hotfix mapping is not fully machine-readable here,
# some trains are intentionally reported as UNKNOWN rather than guessed.
if v[0] == 7:
# Explicitly affected older branch from CNA
if v[:3] == (7, 0, 1):
if v[3] <= 5169:
return ("VULNERABLE", 1, "CNA lists 7.0.1-5169 and older as affected")
return ("PATCHED", 0, "Later than 7.0.1-5169")
# NVD maps affected 7.x covered models to < 7.3.2-7010
if v[:2] == (7, 3):
if cmp_ver(v, (7, 3, 2, 7010)) < 0:
return ("VULNERABLE", 1, "NVD CPE mapping shows affected builds before 7.3.2-7010")
return ("PATCHED", 0, "At or above 7.3.2-7010")
# 7.1.x / 7.2.x not explicitly exposed in accessible advisory text
return ("UNKNOWN", 2, "7.1.x / 7.2.x mapping not confirmed from accessible vendor text")
if v[0] == 8:
# NVD maps 8.x covered models to < 8.2.0-8009; CNA explicitly lists 8.1.0-8017 and older
if cmp_ver(v, (8, 2, 0, 8009)) < 0:
return ("VULNERABLE", 1, "NVD CPE mapping shows affected builds before 8.2.0-8009")
return ("PATCHED", 0, "At or above 8.2.0-8009")
return ("UNKNOWN", 2, "Major version not covered by reviewed advisory data")
def main():
if len(sys.argv) != 2:
print("UNKNOWN - usage: python3 check_cve_2026_0400.py <version>")
sys.exit(2)
status, code, reason = classify(sys.argv[1])
print(f"{status} - {reason}")
sys.exit(code)
if __name__ == "__main__":
main()