SonicWall SMA1000 CVE-2026-15409: An Unauthenticated SSRF That Chains to Root on Your Remote-Access Appliance

The box that terminates your remote workforce is supposed to be the one machine on the network an attacker cannot reach without a credential. On the SonicWall SMA1000 remote-access appliance, that assumption broke this week. A single unauthenticated request to the login page is now enough to open a tunnel straight into the services running on the appliance's own loopback interface, and from there to a root shell. Rapid7's managed-detection team watched it happen in customer environments before SonicWall shipped an advisory, and CISA added both bugs to the Known Exploited Vulnerabilities catalog the same day.

The chain is two CVEs. CVE-2026-15409 is a server-side request forgery in the SMA1000 Work Place interface, scored CVSS 10.0, reachable with no authentication. CVE-2026-15410 is a post-authentication code-injection flaw in the appliance management console, scored 7.2, that runs commands as root. Neither is dramatic on its own. Together they take an attacker from the public internet to full control of the appliance that holds your VPN sessions, your session database, and a trusted foothold inside your network.

Who this actually affects

The affected product is the SMA1000 series specifically: the 6210 and 7210 hardware appliances and the 8200v virtual appliance. SonicWall's product notice (SNWLID-2026-0008) lists the vulnerable builds as 12.4.3-03245 through 12.4.3-03434 and 12.5.0-02283 through 12.5.0-02800. If you run one of those appliances on one of those builds and its Work Place portal faces the internet, this is yours, and the CISA due date of July 17 is already here.

If you run the SMA 100 series, a TZ or NSa firewall, or someone else's SSL VPN, these two CVE numbers are not yours. The SMA1000 is SonicWall's larger-deployment line; plenty of small shops and the MSPs that serve them run the 100 series or a firewall-terminated VPN instead, and those products are not named in this advisory. I am spelling that out because chasing a patch you do not need is how the appliance you actually should be watching goes unpatched. Confirm the model and the build before you spend a maintenance window on it. What does carry across every product line is the lesson underneath this one: an internet-facing remote-access appliance is your perimeter, and a zero-day in it is an assume-breach event, not a routine patch.

What the two bugs actually do

CVE-2026-15409 lives in a websocket proxy feature at the /wsproxy path on the Work Place application on port 443. The feature is meant to broker websocket connections for the portal. In practice it lets an unauthenticated caller specify an arbitrary destination host and port and open a raw TCP tunnel to it, netcat-style. Point that tunnel at localhost and the appliance's own perimeter stops mattering: you are now talking to services that were only ever meant to listen on the loopback interface, including an Erlang control process on port 1050. That loopback-only trust is exactly what the SSRF converts into remote access.

CVE-2026-15410 is what turns that access into root. The appliance's ctrl-service on port 8188 exposes a hotfix-rollback workflow, and the remove_hotfix routine is vulnerable to path traversal. An attacker who can reach that service stages a shell script outside the expected directory (Rapid7 observed payloads written through traversal to paths like ../../../../var/tmp/privesc) and triggers it through the rollback mechanism, which executes it as root. The two bugs compose cleanly: the SSRF reaches the internal control plane, code execution there gives an authenticated position, and the injection flaw escalates to root. The end state is complete appliance takeover, with the attacker holding whatever the appliance holds.

What it holds is the point. Rapid7 reported theft of the appliance session store at /tmp/temp.db, which contains live VPN session data. From there the intruders pivoted into the connected domain: the clearest downstream signal was NTLM logons from the appliance's own internal IP address that had no matching VPN session and carried odd workstation names. That is an attacker using the compromised box as a jump host into everything behind it.

Patch to the exact hotfix, then assume it was reached

There is no workaround. SonicWall's fix is a platform hotfix: 12.4.3-03453 or later on the 12.4 branch, or 12.5.0-02835 or later on the 12.5 branch, both available from mysonicwall.com. Apply it now if you have not. But because this was exploited as a zero-day before the advisory existed, a clean patch does not tell you whether the box was already used. You have to look.

Start with the appliance's own Work Place access log. A successful SSRF tunnel shows up as a websocket upgrade (HTTP status 101) on /wsproxy, and the in-the-wild requests carried loopback targets and internal ports, RDP's 3389 among them. Pull the log and grep for the shape of it:

# SMA1000 Work Place access log — look for the SSRF tunnel signature:
# a websocket upgrade (HTTP 101) on /wsproxy pointed at loopback or an
# internal service port. 3389 was seen tunneled in the wild.
grep -E 'GET [^ ]*/wsproxy' extraweb_access.log \
  | grep -E ' 101 ' \
  | grep -Ei '0\.0\.0\.0|localhost|127\.0\.0\.1|::ffff:127\.0\.0\.1|=-3389'

# Root-stage payloads land outside the web root via traversal, and the
# session store gets copied out. Hunt the filesystem on any suspect box:
find / \( -path '*/var/tmp/privesc' -o -name 'temp.db*' \) \
  -newermt '2026-07-01' 2>/dev/null

Rapid7 attributed the activity to infrastructure in ASN 206092 and published source ranges worth blocking and hunting: 45.131.194.0/24, 45.146.54.0/24, 63.135.161.0/24, and 173.239.211.0/24, plus discrete addresses including 193.37.32.179, 193.37.32.214, 216.73.163.151, and 216.73.163.158. Treat a hit in the access log or a match on those ranges as a confirmed intrusion, not a scan, and move to containment.

Hunt the blast radius in your SIEM

Most teams cannot get a forensic image of a production VPN concentrator on the day a CVE drops. You can still find the part that matters most, which is whether the appliance was used to move into the domain. The tell is a Windows logon sourced from the appliance's inside interface that does not correspond to a VPN user session. If you forward domain-controller and server security events to Splunk, hunt for it directly:

index=wineventlog EventCode=4624 Logon_Type=3
  Source_Network_Address="10.10.20.5"        ``` your SMA1000 inside interface ```
| eval hour=strftime(_time,"%Y-%m-%d %H:%M")
| stats count min(_time) as first_seen max(_time) as last_seen
        values(Workstation_Name) as workstations
        values(Account_Name)     as accounts
        by Source_Network_Address
| where count > 0

The appliance should authenticate to the domain in narrow, predictable ways. A network logon (type 3) from its IP carrying a workstation name you do not issue, an attacker default like kali, or a burst of distinct accounts from that one source is the signature of the box being ridden inward. If your logs live in Microsoft Sentinel, the same hunt is a SecurityEvent query on EventID == 4624 and LogonType == 3 filtered to the appliance address. Either way, any match sends you to credential resets for accounts that authenticated through the box and a hard look at what those accounts can reach.

Shrink what the appliance can reach next time

Two changes make the next SMA1000 zero-day less useful to whoever finds it, and neither waits on a vendor. First, take the management plane off the internet. The management console and the control services this chain abused have no reason to be reachable from anywhere but a small administrative network; restrict them to a management VLAN or a short source-IP allowlist so an unauthenticated internet request cannot even start the conversation. Second, treat the appliance as untrusted toward the inside. Segment it away from your domain controllers, give the account it uses only the directory rights it needs, and put egress filtering in front of it so a rooted box cannot freely call home or pivot. A remote-access appliance is a high-value target precisely because it straddles the boundary; the less it is allowed to touch, the smaller the fire when it burns.

The next 72 hours

• Confirm model and build. Patch SMA1000 6210 / 7210 / 8200v to 12.4.3-03453 or 12.5.0-02835 or later.
• Grep extraweb_access.log for HTTP 101 on /wsproxy with loopback or internal-port targets; scan the ASN 206092 ranges above.
• Hunt 4624 type-3 logons from the appliance IP with unexpected workstation names; reset credentials for any account that transited the box.
• Move the management console and control services behind an allowlist; segment the appliance from the domain and add egress filtering.

Patch the box, then hunt the domain behind it

SonicWall shipped the hotfix, and installing it closes the door for the next attacker. It does nothing for the one who may already be inside, because this shipped as a zero-day and the exploitation predates the fix. So do both jobs: patch the appliance to the exact build, and go read the logs on the domain it fronts as if it were already used against you, until the access log and your SIEM say otherwise. If your team does not have a current picture of what is exposed at your edge or how far a compromised appliance could reach, that is the assessment worth booking before the next one of these lands.