Vulnerabilities

On November 3, SonicWall published advisory SNWLID-2026-0019 for two vulnerabilities in its Global Management System (GMS), the on-premises console many organizations and managed service providers use to configure, monitor and report on fleets of SonicWall firewalls. The worse of the two lets anyone who can reach the server read internal files without logging in. Both affect GMS 9.5.2 and every earlier version, on the Virtual Appliance and on Windows.

SonicWall will not fix either one. GMS reached End of Support on September 30, 2026, and the advisory says plainly that "no remediation or security update will be released for these vulnerabilities." If you still run GMS, the only permanent answer is to move to Network Security Manager (NSM), and until you do, the server has to be fenced off.

The two flaws

CVE-2026-109593, CVSS 9.1 (critical). An unauthenticated attacker with network access to GMS may be able to read internal GMS files. SonicWall classes it as CWE-636, "Not Failing Securely", which means a check that should deny the request falls through and allows it instead. The vector is network, low complexity, no privileges and no user interaction, so this is the one that matters for any GMS reachable beyond a small admin network.

CVE-2026-109594, CVSS 6.8 (medium). A SQL injection in a part of GMS that needs a logged-in user with high privileges. Under specific conditions it lets that user read or change records in the GMS database. On its own it needs a valid admin session. Chained with a file read that leaks credentials or session material, that requirement gets much easier to meet, although SonicWall has not said whether the two can be combined.

Matei Badanoiu and Andrei Lungu of Pentest-Tools.com reported the bugs. SonicWall has not published technical details, and as of November 3, CISA's assessment recorded no known exploitation, while marking the file read as automatable. Neither CVE is in CISA's Known Exploited Vulnerabilities catalog at the time of writing.

Why a file read on GMS is serious

GMS is a management plane. It holds the list of every firewall it manages, the tenants and users who log in to it, scheduled reports and the settings it pushes to devices, and it talks to those firewalls over HTTPS or IPsec management tunnels. SonicWall's advisory only says the readable files could expose "sensitive information". Our assessment is that on a typical deployment those files can include configuration and connection details for the managed fleet. That makes a GMS compromise a starting point for attacks on the firewalls themselves.

The version you run changes the picture. In August, advisory SNWLID-2026-0011 fixed four GMS flaws in 9.5.2, including CVE-2026-66145 (CVSS 9.1, unauthenticated code execution via a zip slip file write) and CVE-2026-66147 (CVSS 9.4, unauthenticated command injection in the GMS Dispatcher Service). Any server still on 9.5.1 or older carries those two remote code execution bugs as well as the new pair. Upgrading to 9.5.2 is still worth doing if migration is weeks away, because it removes the code execution flaws, but it leaves the new file read and SQL injection in place.

What to do

1. Find every GMS server. Check hypervisors (ESXi, Hyper-V) and Windows server inventories for GMS installs, and scan internal ranges for the GMS web interface, which listens on TCP 8443 (HTTPS) and TCP 80 (HTTP) by default. The firewalls tell you too: on SonicOS 7, go to Device, Settings, Administration, Audit / SonicOS API, and look under Advanced Management for "Enable Management using GMS". The GMS Settings screen there shows the GMS host name or IP address each firewall reports to. Forgotten secondary or distributed reporting servers are common, so collect every address you find.

2. Take it off the internet. Use an external scan or Shodan-style search against your own ranges to confirm no GMS web, CLI or SSH port is reachable from outside. If remote admins need it, put it behind a VPN with multi-factor authentication instead of a published port.

3. Restrict the ports that stay open. Per SonicWall's port list, allow inbound TCP 8443 and 80 (web), TCP 5595 (CLI) and TCP 22 (SSH, Virtual Appliance only) from named admin jump hosts only. Managed firewalls need to reach GMS on UDP 514 for syslog and UDP 162 for SNMP traps, and GMS polls them on 161, so permit those between GMS and the firewall management addresses and nothing wider. The database ports (1433, 3306, 5029) and the internal control ports in the 21000 range should never be reachable from other hosts.

4. Check whether it has already been touched. Review the GMS web server access logs for requests from addresses outside your admin hosts, especially anything unauthenticated that returned file content. Look in the GMS audit and user lists for admin accounts or tenants you did not create. On the firewalls, compare current configurations against a known-good backup and look for new admin users, changed management settings or new address objects and NAT rules. If anything looks wrong, treat every credential GMS stored as exposed and rotate the firewall admin passwords and any shared secrets it used.

5. Migrate to NSM. SonicWall offers NSM 3.0 as SaaS, which SonicWall hosts, or on-premises on ESXi, Hyper-V, KVM or Azure. For on-premises, the GMS super admin exports a Transition Snapshot from the GMS interface and NSM imports it, bringing tenants, users, firewall acquisition details and scheduled report settings. Logs, reporting data and GMS licenses do not carry over, so export any history you must keep for compliance before you retire the server. Only firewalls with an active support contract can move to NSM, which is worth checking before you plan the cut-over.

After migration, shut the GMS server down and remove it, instead of leaving it running "just in case", and delete its snapshots and backups once the retention period you need has passed.

End of support is a security date

SonicWall announced the end of GMS in May 2025, stopped selling it in October 2025 and ended support on September 30, 2026. The first unfixable flaws arrived five weeks later. Management consoles tend to sit in the background of the network for years, and the lifecycle date is easy to miss because nothing stops working on the day. Putting end-of-support dates for every management and security product into the same tracker as certificate expiry and contract renewals gives you a migration window instead of an advisory with no fix.

If you need help finding management servers you have lost track of, our attack surface management work maps what is reachable from outside, and network penetration testing checks what an attacker could reach from inside once a console like GMS falls. Open the chat and Yaali, our AI agent, will pass your question to an engineer.

---

Sources: SonicWall PSIRT, SNWLID-2026-0019, SonicWall PSIRT, SNWLID-2026-0011, CVE-2026-109593 at NVD, CVE-2026-109594 at CVE.org, SonicWall GMS EOL announcement, GMS End of Life and NSM Transition FAQ, Ports used by GMS, SonicOS 7 GMS management settings, The Hacker News, SecurityWeek.