Automated Threat Modeling

Brief Summary: SonicOS CVE-2026-107155 Permissive Cross-Domain (CORS) Policy in the Management API

A brief summary of CVE-2026-107155, a CWE 942 permissive cross-domain policy flaw in the SonicOS management API rated CVSS 8.8. Covers the root cause, the companion session validation bug, fixed SonicOS 7 and 8 builds, and the post-upgrade configuration checks SonicWall recommends.

CVE Analysis

8 min read

Gaurav Sarraf
Gaurav Sarraf

2026-11-06

Brief Summary: SonicOS CVE-2026-107155 Permissive Cross-Domain (CORS) Policy in the Management API
Experimental AI-Generated Content

This CVE analysis is an experimental publication that is completely AI-generated. The content may contain errors or inaccuracies and is subject to change as more information becomes available. We are continuously refining our process.

If you have feedback, questions, or notice any errors, please reach out to us.

[email protected]

Introduction

A SonicOS management API that trusted requests based on where they came from, and let any web origin read its responses, meant that a single malicious page open in a firewall administrator's browser could act on that administrator's live session. SonicWall has now fixed this behavior in SonicOS 7.3.4 and 8.2.3, but the vendor warns that upgrading alone does not necessarily switch on the safer defaults.

CVE-2026-107155 is tracked as CWE 942 (Permissive Cross domain Policy with Untrusted Domains) and carries a CVSS 3.1 base score of 8.8 (High), as assessed by CISA ADP. SonicWall published it in advisory SNWLID-2026-0014 on November 6, 2026, alongside six other SonicOS CVEs. In this post we summarize the root cause as described in SonicWall's own documentation, how it pairs with a companion session validation bug, which builds fix it, and what to check after upgrading.

Technical Information

Severity vector

The published vector is:

CVSS:3.1/AV:N/AC:L/PR:N/UI:R/S:U/C:H/I:H/A:H

The two values that matter most for understanding the bug are PR:N (no attacker privileges) and UI:R (user interaction required). Both hold at once. The attacker needs no credentials of their own, but a legitimate administrator has to load attacker-controlled content in a browser. NVD shows this score under CISA ADP. NVD's own assessment had not been provided at the time of writing.

Root cause: open CORS on the management API

SonicOS is closed source, so there is no public commit or diff. However, SonicWall's knowledge base article Securing the SonicOS API: CORS and Bearer Token Session Check describes the pre-fix behavior fairly directly:

  • In earlier releases, an API session was tied to the source IP of the administrator's workstation.
  • API responses "permitted cross origin access without restriction."

At the generic weakness level, MITRE describes CWE 942 as a web client protection policy (such as a CORS or cross-domain policy) that permits communication with untrusted domains, where an untrusted domain or overly broad wildcard undermines the intended trust boundary. In SonicOS, the effect was that the browser's same-origin protections no longer shielded API responses from arbitrary web pages.

The companion bug: CVE-2026-107154

CVE-2026-107155 was reported together with CVE-2026-107154, a session validation flaw filed as CWE 291 (Reliance on IP Address for Authentication). Pentest-Tools.com submitted both under a single research ID, PTT-2026-021. According to the patch documentation, the two bugs only work as a pair:

  • CVE-2026-107154 means a request is treated as part of the admin's session simply because it arrives from the admin's IP.
  • CVE-2026-107155 means a page from any origin is allowed to read the API's responses.

IP-based session binding alone would let a malicious page send requests blind. The permissive CORS policy is what lets that page also read the results.

Attack flow

Based on SonicWall's description, the attack sequence looks like this:

  1. An administrator has an active SonicOS management API session from their workstation.
  2. The administrator opens a malicious web page in a browser on that same workstation. This is the user interaction captured by UI:R.
  3. Script on the page sends API requests to the firewall's management interface. Because the requests originate from the workstation's IP, the firewall accepts them as part of the live management session.
  4. The open CORS policy lets the page read the API responses, giving the attacker both visibility into the firewall and the ability to perform unauthorized operations, without any credentials of their own.

The specific API endpoints, request sequences, and allowed origin headers involved have not been published, and we have not seen a public proof of concept. The NVD description characterizes the outcome only as potential unauthorized operations "in specific conditions," and it does not establish command execution.

Patch Information

Fixed releases

SonicWall fixed CVE-2026-107155 in advisory SNWLID-2026-0014, published November 6, 2026. Every affected branch receives the fix through a firmware update:

  • Gen7 hardware (TZ 270 through 670, NSa 2700 through 6700, NSsp 10700 through 15700) and Gen7 NSv (270/470/870): vulnerable in 7.3.3-7015 and older, fixed in 7.3.4-7013 and higher.
  • Gen8 hardware (TZ 80 through 680, NSa 2800 through 5800) and Gen8 NSv (XS/S/M/L): vulnerable in 8.2.2-8015 and older, fixed in 8.2.3-8015 and higher.

The advisory lists "Workaround: None", so upgrading is the only vendor fix.

One caveat for Gen7 NSv: the 7.3.4-7013 release notes state that this build "will not be released at this time" for the NSv Series. The SonicOS 7.3 release notes table of contents now also lists a later 7.3.4-7015 build, and the 7013 page is tagged as superseded.

What the fix changes

The 7.3.4 release changes both halves of the bug pair:

  • CORS locked down (the fix for CVE-2026-107155). CORS for the SonicOS management API is now disabled by default. If an administrator enables it, SonicOS requires an explicit allow list of origins (IPs, FQDNs, or wildcard subdomain patterns) and no longer allows every origin. The setting lives under Device | Settings | Administration | SonicOS API, CORS / Allow CORS Origins.
  • Per-request bearer tokens (the companion fix for CVE-2026-107154). The Bearer Token Session Check for non-GUI management logins is now enabled by default. The client receives a token in the /auth response and must send it in the HTTP header of every subsequent API request. A request from the right IP without the token is no longer treated as part of the session. A cross-origin page cannot obtain the token, so it cannot ride the administrator's session even if a browser lets the request through.

The firewall no longer vouches for requests because of where they come from. Browser same-origin protection is restored by default, and each API call must carry proof that it belongs to the session.

Gen8 branch

The 8.2.3-8015 release notes state that "all features introduced in SonicOS 7.3.4 are available in SonicOS 8.2.3," so the same CORS and bearer token defaults apply. The resolved issues table lists the session validation fix (GEN8-18926) and the other SNWLID-2026-0014 items, but has no separate line for the cross-domain policy CVE. The notes also list a known issue, GEN8-19712, in which guest authentication with a custom captive portal fails because of CORS in 8.2.3. That is consistent with stricter cross-origin enforcement in this release.

Verify the configuration after upgrading

SonicWall's KB warns that upgrading "does not necessarily apply the new defaults." A firewall that previously had a permissive configuration can retain it after the update. After upgrading, open Device | Settings | Administration | SonicOS API and confirm:

  1. CORS is disabled, or limited to a short list of trusted origins.
  2. Bearer Token Session Check is enabled.
  3. The SonicOS API is turned off entirely if nothing uses it.

On compatibility: scripted clients such as curl, Python, PowerShell, and NSM do not use CORS, but they must now send the bearer token. Browser-based tools, including custom captive portals, may need their origin added to the allow list.

Additional exposure reduction

Separately from the fix, SonicWall documents general hardening for management access on SonicOS 7.X:

  1. Create an address object or group for trusted management sources.
  2. Under Network > System > Interfaces, disable unneeded WAN management services (HTTP, HTTPS, Ping, SNMP, SSH), leaving only HTTPS if remote management is required.
  3. Under Policy > Rules and Policies > Access Rules (WAN to WAN matrix), set the management rules' Source Address to the trusted object instead of Any.

This reduces who can reach the management plane, but it does not replace the firmware fix.

Affected Systems and Versions

  • SonicOS 7 (Gen7): 7.3.3-7015 and older. Platforms: TZ 270, 370, 470, 570, 670; NSa 2700 through 6700; NSsp 10700 through 15700; NSv 270/470/870.
  • SonicOS 8 (Gen8): 8.2.2-8015 and older. Platforms: TZ 80 through 680; NSa 2800 through 5800; NSv XS/S/M/L.

The vulnerable configuration is the SonicOS management interface and API, which in affected releases bound sessions to source IP and returned responses with unrestricted cross-origin access. Devices upgraded to fixed builds may still carry a permissive CORS configuration if it was set before the upgrade.

Exploitation status

The CISA Coordinator SSVC assessment embedded in the NVD record, timestamped November 6, 2026 at 19:10:51 UTC, records exploitation as none, automatable as no, and technical impact as total. VulDB lists KEV status as no. No threat actor is attributed. That is a point-in-time assessment and does not guarantee the status will hold.

Vendor Security History

SonicWall, founded in 1991, serves enterprises, governments, and SMBs with a strong MSP and partner focus. The vendor reports 500K+ customers protected and 17K+ global partners. Its appliances have drawn sustained attacker attention in recent years, though none of the following is linked to CVE-2026-107155:

  • SSLVPN activity (2025): In a notice published August 4, 2025 and updated August 22, 2025, SonicWall investigated fewer than 40 incidents affecting Gen 7 and newer firewalls with SSLVPN enabled. It stated with high confidence these were not a new zero day and showed significant correlation with CVE-2024-40766. Many involved Gen 6 to Gen 7 migrations where local user passwords were carried over without reset.
  • Akira ransomware: Arctic Wolf reported in September 2024 that Akira affiliates compromised local SonicWall SSLVPN accounts, with MFA disabled and firmware in ranges vulnerable to CVE-2024-40766. CISA's Akira advisory says the actors likely abused that CVE and also used stolen credentials.
  • Cloud backup incident: The Canadian Centre for Cyber Security reports that on October 8, 2025, SonicWall confirmed unauthorized access to firewall configuration backup files for all customers using its cloud backup service, information that could make firewall exploitation significantly easier.

These incidents involve different mechanisms (credential compromise, a separate firmware CVE, a cloud service breach) and call for different responses than the policy and session flaws fixed here.

References

Detect & fix
what others miss

Works with
  • GitHub
  • GitLab
  • Bitbucket
  • Azure DevOps Services
  • Gerrit
  • CVS
  • Jira
  • Linear
  • Slack
  • Security Compass
Explore integrations
Security magnifying glass visualization