A vulnerability in the access control mechanism of SonicOS may allow certain management interface functions…

CVE-2026-0204 is an improper access control flaw in SonicOS that can expose some firewall management interface functions when specific conditions line up. Publicly documented affected trains span Gen6 SonicOS before 6.5.5.2-28n, Gen7 branches including 7.0.0.0 through 7.0.1-5169 and later 7.x releases before 7.3.2-7010, and Gen8 releases before 8.2.0-8009; multiple secondary sources simplify that to Gen6/Gen7/Gen8 broadly up to 6.5.5.1-6n / 7.3.1-7013 / 8.1.0-8017. The practical risk is not data theft from the firewall itself; it is control over the thing enforcing your network policy.

Reality is lower than the raw technical impact suggests. There is no vendor baseline CVSS to compare against, only later CISA-ADP enrichment showing an adjacent-network vector plus user interaction required; that combination matters because it usually means the attacker already has local/VPN foothold or access to the management segment. No KEV, no public exploitation evidence, and no widely circulated PoC keep this out of the urgent-fire-drill bucket, but the fact that it touches the management plane of a widely deployed firewall keeps it above LOW.

Why this verdict

• No vendor baseline exists so this is a first-principles assessment; I treated the CISA-ADP 8.0 vector as technical context only, not as a severity anchor to upgrade or downgrade.
• Adjacency requirement cuts the reachable population hard. AV:A usually implies the attacker is already on the LAN, on VPN, or on a routed management segment; that is a major real-world reduction from internet-wide pre-auth edge bugs.
• User interaction and 'specific conditions' add reliability friction. This does not read like a clean one-request unauthenticated takeover, and the lack of public PoC reinforces that view.
• Wide deployment keeps it from being LOW. SonicWall firewalls are common and the affected range spans Gen6, Gen7, and Gen8 firmware trains.
• Control-plane impact keeps it from being IGNORE. If the attacker does reach meaningful management functions, they may be able to rewrite enforcement rather than merely read a page.

Why not higher?

There is no public exploitation evidence, no KEV listing, and no public exploit tooling in the sources reviewed. More importantly, the attack path is narrowed by adjacent access plus user interaction, which means many enterprises would only face this after an initial foothold or from a poorly segmented admin surface.

Why not lower?

This is still a flaw in the management plane of a firewall, not a harmless info leak on an internal tool. If exploitation succeeds, the blast radius for that device is serious because policy enforcement, VPN posture, and administrative trust all sit on the box.

1. Restrict management to SSH-only where operationally possible — SonicWall's own temporary guidance is to disable HTTP/HTTPS-based management and SSLVPN on all interfaces and keep management on SSH only. For a MEDIUM reassessment there is no mitigation SLA; do this opportunistically on high-exposure devices first, especially anything reachable from user VLANs or partner/VPN segments.
2. Collapse management exposure onto a dedicated admin network — The whole exploit path starts with adjacent reachability. Move web management behind a jump host, dedicated VLAN, or out-of-band path so ordinary workstation subnets and VPN pools cannot hit it; for MEDIUM, there is no noisgate mitigation deadline, but this is worth folding into normal network-hardening work rather than waiting for patch day.
3. Alert on firewall config drift and admin-plane access — Because the likely payoff is unauthorized use of management functions, audit logs and change alerts buy you the fastest visibility. Turn on notifications for new admin sessions, rule changes, VPN/user changes, and management-interface exposure changes during the remediation window.
4. Inventory and version-check every Gen6/Gen7/Gen8 appliance — This is a firmware-train problem across multiple generations, so guessing from model alone is sloppy. Use your CMDB, NSM, SSH collection, or runZero/Nessus version telemetry to separate actually vulnerable appliances from already-fixed ones; with MEDIUM, there is no mitigation SLA — go straight to the remediation window.

Run this on an auditor workstation, CI job, or inventory-processing host, not on the firewall itself. Invoke it with a firmware version string exactly as reported by NSM, SSH show version, or your scanner, for example: python3 check_cve_2026_0204.py 7.3.1-7013; no elevated privileges are required.

#!/usr/bin/env python3
# check_cve_2026_0204.py
# Determine likely exposure to CVE-2026-0204 from a SonicOS firmware version string.
# Exit codes: 0=PATCHED, 1=VULNERABLE, 2=UNKNOWN

import re
import sys


def usage():
    print('Usage: python3 check_cve_2026_0204.py <firmware-version>')
    print('Example: python3 check_cve_2026_0204.py 7.3.1-7013')
    sys.exit(2)


def split_version(v):
    s = v.strip().lower()
    if not s:
        raise ValueError('empty version')
    parts = []
    for token in re.findall(r'[0-9]+|[a-z]+', s):
        if token.isdigit():
            parts.append((0, int(token)))
        else:
            # compare letter suffixes after numeric pieces
            letter_value = 0
            for ch in token:
                if 'a' <= ch <= 'z':
                    letter_value = letter_value * 26 + (ord(ch) - 96)
            parts.append((1, letter_value))
    return tuple(parts)


def cmp_ver(a, b):
    aa = split_version(a)
    bb = split_version(b)
    maxlen = max(len(aa), len(bb))
    aa += ((0, 0),) * (maxlen - len(aa))
    bb += ((0, 0),) * (maxlen - len(bb))
    if aa < bb:
        return -1
    if aa > bb:
        return 1
    return 0


def starts_with_major(v, major):
    return v.strip().startswith(str(major) + '.')


def in_range(v, low_incl, high_excl=None, high_incl=None):
    if cmp_ver(v, low_incl) < 0:
        return False
    if high_excl is not None and cmp_ver(v, high_excl) >= 0:
        return False
    if high_incl is not None and cmp_ver(v, high_incl) > 0:
        return False
    return True


def assess(version):
    v = version.strip()

    # Gen6 guidance: affected before 6.5.5.2-28n; fixed at 6.5.5.2-28n+
    if starts_with_major(v, 6):
        if cmp_ver(v, '6.5.5.2-28n') >= 0:
            return 'PATCHED'
        return 'VULNERABLE'

    # Gen7 authoritative ranges from NVD/OpenCVE enrichment:
    # 7.0.0.0 through 7.0.1-5169 inclusive, and 7.1.1-7040 through 7.3.2-7010 exclusive.
    if starts_with_major(v, 7):
        if cmp_ver(v, '7.3.2-7010') >= 0:
            return 'PATCHED'
        if in_range(v, '7.0.0.0', high_incl='7.0.1-5169'):
            return 'VULNERABLE'
        if in_range(v, '7.1.1-7040', high_excl='7.3.2-7010'):
            return 'VULNERABLE'
        return 'UNKNOWN'

    # Gen8 authoritative range from NVD/OpenCVE enrichment:
    # 8.0.0-8035 through 8.2.0-8009 exclusive; fixed at 8.2.0-8009+
    if starts_with_major(v, 8):
        if cmp_ver(v, '8.2.0-8009') >= 0:
            return 'PATCHED'
        if in_range(v, '8.0.0-8035', high_excl='8.2.0-8009'):
            return 'VULNERABLE'
        return 'UNKNOWN'

    return 'UNKNOWN'


def main():
    if len(sys.argv) != 2:
        usage()

    version = sys.argv[1]
    try:
        result = assess(version)
    except Exception as exc:
        print('UNKNOWN')
        print(f'Error: {exc}', file=sys.stderr)
        sys.exit(2)

    print(result)
    if result == 'PATCHED':
        sys.exit(0)
    if result == 'VULNERABLE':
        sys.exit(1)
    sys.exit(2)


if __name__ == '__main__':
    main()

Sources

1. SonicWall PSIRT advisory SNWLID-2026-0004
2. NVD CVE-2026-0204 record
3. OpenCVE JSON view of the CNA record and CISA-ADP enrichment
4. runZero SonicWall SonicOS exposure and version-finding guidance
5. SecurityWeek coverage of SNWLID-2026-0004
6. heise coverage of SonicOS management access flaw
7. SC Media coverage citing discovery context and operational risk
8. CISA Known Exploited Vulnerabilities Catalog