An unlocked file cabinet in the SOC that holds the keys to every firewall, VPN tunnel, and gateway in the building
CVE-2026-109593 affects SonicWall Global Management System (GMS) 9.5.2 and earlier. The application fails to enforce authorization on one or more endpoints — CWE-636 failing open — so an unauthenticated attacker who can reach the management interface can read internal GMS files. Those files can include configuration data, device records, logs, and potentially secrets used to manage SonicWall firewalls, VPN appliances, email security, and access points. The product is EOL and has no patch.
SonicWall rates this 9.1 CRITICAL. That's directionally fair for the *management plane* of a fleet of security devices: a file-read primitive there is the equivalent of finding the security team's key locker unlocked. But the vector assumes network access to GMS, and GMS is typically an internal console, not a public-facing service. No public exploit exists as of 2026-11-03, so for many enterprises the immediate real-world exposure is lower than a 9.1 would suggest. The deployment-role reality, however, keeps the floor at CRITICAL: if the file read exposes device credentials or VPN PSKs, it becomes a fleet-compromise pivot.
4 steps from start to impact.
Reach the GMS management interface
- Network route from attacker to GMS management interface
- GMS version 9.5.2 or earlier
- GMS is typically deployed on internal management VLANs, not Internet-facing
- Most enterprises restrict management plane access to admin jump hosts
- No mass internet exposure reported in search results
Trigger the failing-open authorization path
- Vulnerable endpoint must be reachable
- GMS must be running affected software
- No public PoC exists as of 2026-11-03
- Exact endpoint details are not in the public advisory
- WAF may catch obvious traversal strings, but failing-open behavior may resemble a normal transaction
Harvest internal GMS files for secrets and configs
- Sensitive files must be accessible through the failing-open endpoint
- Secrets must be stored in a usable form
- Some secrets may be encrypted or hashed
- File access may require path traversal or valid internal references
- GMS may not store all secrets in plaintext
Pivot to managed SonicWall devices
- Harvested credentials/configs must still be valid
- Attacker must have network path from GMS or use credentials remotely
- Some device credentials may be rotated or have separate management networks
- VPN PSKs and configs may require further decryption
- A WAF in front of GMS will not reliably block this because the failing-open endpoint may not show obvious path traversal or malicious payload; no current signatures exist and EOL means none will come from vendor.
- Changing GMS passwords or enabling MFA at the application layer does not stop this vulnerability — the issue is unauthenticated access to an internal file-read endpoint, not credential misuse.
- Waiting for a vendor hotfix is not a valid control: SonicWall has marked GMS EOL and stated no fix version is available.
The supporting signals.
| In-the-wild status | No known exploitation; CISA ADP lists exploitation: none |
|---|---|
| Proof of concept | None public as of 2026-11-03; VulDB notes no exploit available |
| EPSS | Not found in FIRST EPSS feed yet; CISA ADP rates automatable: yes |
| KEV status | Not listed in CISA KEV as of 2026-11-03 |
| CVSS vector | CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:N/A:H — network, low complexity, no privileges; note A:H appears in vendor vector despite advisory describing confidentiality impact |
| Affected versions | SonicWall GMS 9.5.2 and earlier, Windows and Linux/virtual appliance; product is EOL |
| Fixed versions | None — vendor states no remediation or security update will be released |
| Exposure | Typically internal management console; not normally Internet-facing |
| Disclosed | 2026-11-03; SonicWall PSIRT advisory SNWLID-2026-0019 |
| Researcher/org | Vendor-credited vulnerability (SonicWall PSIRT) |
Sources.
Why this verdict
- Role multiplier: GMS is a central management plane for SonicWall firewalls, VPN, email security, and access points; an unauthenticated file read can expose device credentials, PSKs, and config backups, enabling a pivot to the entire managed fleet — CRITICAL floor.
- Network exposure friction: GMS is generally deployed on internal management VLANs, not public-facing; this lowers the reachable population, but since the bug requires only network access and no credentials, any internal compromise or network chokepoint failure re-exposes it.
- Weaponization status: No public PoC or active exploitation was found as of 2026-11-03, so we shave slightly from the vendor score; the vendor and CISA ADP still rate it automatable with AC:L.
- No patch: EOL, no fix, no workaround, so exposed assets stay exploitable until decommissioned.
Why not higher?
Score sits at 9.0 rather than 10 because the advisory describes information disclosure (C:H) while the vector also asserts A:H; no proof yet that the read is arbitrary across the entire filesystem or that all secrets are plaintext, and typical GMS deployments are internal rather than public-facing. Those factors shave a fraction off the vendor's 9.1 baseline.
Why not lower?
The verdict cannot drop below CRITICAL because GMS is, by definition, the management plane for a fleet of edge security devices; an unauthenticated file read on it is a single low-complexity request away from exposing credentials and configs for every managed firewall/VPN/access point. There is no patch and no vendor workaround, so any reachable instance remains permanently exploitable.
Crowdsourced verification payload.
Run from a host with network access to the GMS web interface; no special privileges needed beyond outbound TCP/443 and 80. Invoke: bash check_cve_2026_109593.sh <GMS_IP_or_hostname>. The script probes HTTPS/HTTP and fingerprints the GMS UI; it exits 1 for VULNERABLE and 3 for UNKNOWN.
#!/bin/bash
# CVE-2026-109593 exposure check for SonicWall GMS
HOST="$1"
if [ -z "$HOST" ]; then
echo "Usage: $0 <GMS_IP_or_hostname>"
exit 3
fi
tmp=$(mktemp)
rm -f "$tmp"
code=$(curl -sk -o "$tmp" -w '%{http_code}' --connect-timeout 5 "https://$HOST/")
if [ "$code" = "000" ]; then
code=$(curl -sk -o "$tmp" -w '%{http_code}' --connect-timeout 5 "http://$HOST/")
scheme=http
else
scheme=https
fi
if [ "$code" = "000" ]; then
echo "UNKNOWN: host unreachable"
rm -f "$tmp"
exit 3
fi
body=$(cat "$tmp")
if echo "$body" | grep -qiE 'SonicWall.*Global Management System|GMS' ; then
ver=$(echo "$body" | grep -oiE 'GMS[ /_-]?[0-9]+(\.[0-9]+)+' | head -1)
if [ -n "$ver" ]; then
echo "VULNERABLE: SonicWall GMS $ver identified; <=9.5.2 affected and EOL."
exit 1
else
echo "VULNERABLE: SonicWall GMS web UI identified; version not detected but all known releases <=9.5.2 are affected."
exit 1
fi
else
echo "UNKNOWN: service reachable but not identified as SonicWall GMS"
rm -f "$tmp"
exit 3
fi
rm -f "$tmp"