How to Fix CVE-2026-0205: SonicOS Post-Authentication Path Traversal

Last verified: 2026-05-25

CVE-2026-0205 is a post-authentication path traversal flaw in SonicWall SonicOS, the operating system that runs SonicWall TZ, NSa and NSsp firewalls. A user who already holds valid credentials can abuse .../...//-style path sequences to reach services on the appliance that the management interface is supposed to keep walled off. SonicWall disclosed it in advisory SNWLID-2026-0004 on 29 April 2026, alongside several other SonicOS issues in the same release cycle. This page covers what the flaw is, exactly which builds are affected, and the vendor-correct way to remediate it.

What CVE-2026-0205 actually is

SonicOS is the firmware that powers SonicWall's firewall line, and like most appliance operating systems it exposes a set of internal services that the management interface is supposed to gate carefully. CVE-2026-0205 breaks that gate. It is a path traversal flaw classified as CWE-35, the specific .../...// variant where doubled and nested traversal tokens survive a naive sanitiser that only strips a single ../ pass. SonicWall's own description is blunt: the flaw "allows an attacker to interact with usually restricted services."

The word that matters most in that sentence is post-authentication. This is not a pre-auth, internet-facing remote code execution bug. To exploit it, an attacker needs to be on the adjacent network and already hold a valid SonicOS session, and the CVSS vector also flags UI:R (user interaction required). That combination is why the score lands at 6.8 Medium rather than in the critical range. It is a privilege-and-reach problem: someone with a foothold widens it, reaching services they should not be able to touch from the management plane.

Read the CVSS vector in plain language: AV:A means the attacker must be adjacent (same broadcast domain or directly reachable management network), PR:N means no privileges are required by the scoring model beyond an authenticated path, C:L/I:L means limited confidentiality and integrity loss, and A:H means a successful interaction with the wrong internal service can take availability down hard. On a firewall that fronts your whole perimeter, that availability impact is the part worth losing sleep over.

Which builds are affected

SonicWall advisory SNWLID-2026-0004 lists the affected SonicOS trains across three firewall generations. The version field uses an "and older" ceiling for each train, so anything at or below these builds is vulnerable:

• SonicOS 6.5.5.1-6n and older (Gen6 platforms)
• SonicOS 7.0.1-5169 and older (Gen7)
• SonicOS 7.3.1-7013 and older (Gen7/Gen8)
• SonicOS 8.1.0-8017 and older (Gen8)

The CNA assigning this CVE is SonicWall itself, and the platform list in the record explicitly names Linux, Gen6, Gen7 and Gen8. If you do not know which train your appliance runs, the management UI shows it under System > Status (Gen7/Gen8) or System > Settings (Gen6), and the same string is returned by the API and the support bundle.

How to fix it (the vendor-correct path)

There is exactly one real remediation here, and it is a firmware upgrade. SonicOS is a closed appliance OS. There is no apt, dnf, yum, winget or package-manager command that touches it, and any guide that tells you to run one is wrong for this product. The fix ships as a signed firmware image that you load through the SonicOS console or pull from MySonicWall.

Important honesty note: the CVE record itself does not publish an exact fixed-build string. It only lists the affected ceilings. SonicWall names the corrected build for each generation inside advisory SNWLID-2026-0004, so that advisory is the authoritative source for the exact image to load. Do not guess a version number; match your generation to the fixed build the advisory lists.

1. Read the advisory first. Open SNWLID-2026-0004 and note the fixed build for your train (6.5.x, 7.0.x, 7.3.x or 8.1.x).
2. Back up the running config. In SonicOS, export the settings file (Device > Settings > Firmware & Settings > Export Configuration on Gen7/Gen8). A firewall config rollback is painful without it.
3. Download the fixed image from MySonicWall. Use the firmware download tied to your registered serial so you get the correct platform build, not a generic image.
4. Upload and boot the new firmware. Load the image under the firmware management page, then boot the new image (SonicOS keeps the previous image in the secondary slot, which is your rollback).
5. Confirm the version after reboot. Re-check System > Status and verify the build now matches or exceeds the fixed build named in the advisory.

If you run an HA pair, upgrade through the standard SonicOS HA firmware procedure so the standby takes the new image first and you fail over cleanly, rather than upgrading both units cold.

Interim mitigation if you cannot patch today

Because this is post-authentication and adjacent-network with user interaction required, the exposure is driven entirely by who can reach an authenticated management session. Shrinking that audience is the most effective stopgap:

• Lock down management access. Restrict HTTPS/SSH management to a dedicated management interface or a tight source-IP allow list. A path traversal you cannot reach is a path traversal you cannot exploit.
• Enforce MFA on every admin account. The bug needs a valid session; making sessions harder to obtain raises the bar directly.
• Audit and prune admin accounts. Remove stale local admins, and rotate credentials for any account you are not certain about.
• Separate the management plane. If management currently shares a VLAN with general user traffic, move it. Adjacent-network attack vectors shrink fast when the adjacent network is small and trusted.

These are risk reducers, not a fix. The only thing that actually closes CVE-2026-0205 is the patched firmware.

Checking whether you were already touched

Since CVSS flags limited confidentiality and integrity impact, treat a compromised appliance as one where internal services may have been probed. Pull the SonicOS logs and look for the signals an authenticated traversal would leave:

• Management-interface log entries showing requests with unusual nested path tokens (sequences containing .../...// or repeated dot-slash patterns).
• Admin logins from accounts or source addresses that do not match your normal operator pattern, especially just before any anomalous management activity.
• Unexpected changes to firewall rules, NAT policies, VPN configuration, or admin user objects, which is the kind of state an attacker who reached a restricted service might alter.
• Configuration-change audit entries you cannot tie back to a known change ticket.

If you find any of these, rotate admin credentials, export the current config for forensic comparison against your last known-good backup, and review what an adjacent attacker with a valid session could have reached on your specific deployment before you upgrade over the evidence.

For the canonical exploitation status and SSVC breakdown, see the Exploitation status section above: CISA records Exploitation as none, Automatable as no, and Technical Impact as partial. Post-auth firewall bugs still matter to anyone holding stolen admin credentials, so patch on your normal Medium-severity schedule rather than waiting for a KEV listing.

References

• Official vendor advisory: https://psirt.global.sonicwall.com/vuln-detail/SNWLID-2026-0004
• NVD entry: https://nvd.nist.gov/vuln/detail/CVE-2026-0205
• CISA KEV catalog: https://www.cisa.gov/known-exploited-vulnerabilities-catalog
• Related SonicOS advisory item: How to Fix CVE-2026-0204

Frequently asked questions

What does CVE-2026-0205 actually let an attacker do?

It lets an already-authenticated user on the adjacent network use crafted .../...// path sequences to interact with SonicOS services the management interface normally keeps restricted. It is not pre-auth remote code execution; the CVSS 6.8 vector requires a valid session and user interaction.

Which SonicOS versions are affected?

Per SNWLID-2026-0004: 6.5.5.1-6n and older, 7.0.1-5169 and older, 7.3.1-7013 and older, and 8.1.0-8017 and older, across Gen6, Gen7 and Gen8.

How do I fix it?

Upgrade SonicOS firmware to the patched build SonicWall names in SNWLID-2026-0004 for your generation. The fix is a firmware image loaded through the SonicOS console or MySonicWall; there is no package-manager command for an appliance OS.

Is it on CISA KEV or being actively exploited?

No. It is not on CISA KEV, and the SSVC assessment lists Exploitation as none with no public exploit linked. Patch on a normal Medium-severity schedule.

Can I mitigate it without patching immediately?

Restrict who can reach an authenticated management session: tighten management-access source restrictions, move management to a dedicated interface or VLAN, and enforce MFA on admin accounts. These reduce risk but do not replace the firmware fix.

Related fixes

Related guides worth a look while you sort this one out:

• How to Fix CVE-2026-0121: Information disclosure in Android
• How to Fix CVE-2026-0122: Remote code execution in Android
• How to Fix CVE-2026-0123: Elevation of privilege in Android
• How to Fix CVE-2026-0124: Security Vulnerability in Android
• How to Fix CVE-2026-0203: Denial of Service in Junos OS
• How to Fix CVE-2026-0204: CWE-1390 Weak Authentication in SonicOS