SonicWall SMA1000: you patch, you reset the passwords, and they are still in

The reset that does nothing

When a security appliance is compromised, the response playbook is almost always the same: apply the patch, change the passwords, get back to work. It is the right reflex for most incidents. For what happened to SonicWall SMA1000 appliances in July 2026, it is not enough — and understanding why it is not enough is the whole point of this dossier.

On 14 July 2026 SonicWall published advisory SNWLID-2026-0008 for two flaws in the SMA1000 series: CVE-2026-15409, a Server-Side Request Forgery scoring CVSS 10.0, and CVE-2026-15410, a code injection scoring CVSS 7.2. Both, the vendor writes, are "confirmed as being actively exploited in the wild." Rapid7's Managed Detection and Response team had seen them in action before disclosure: they were zero-days.

A proxy the device offers on its own

The first flaw needs no password. The SMA1000 appliance exposes, on the "SonicWall WorkPlace" application served on port 443, a websocket proxy feature reachable at the path /wsproxy. That feature opens a TCP tunnel — a netcat over the browser — to whatever host and port you hand it in the URL parameters. The defect is that it does not check where you point that tunnel. Ask it for localhost, and it opens a channel to the internal services the appliance keeps behind its own firewall, services never meant to be reached from outside.

1. 01
   /wsproxy exposed

   websocket tunnel to a host and port of the attacker's choosing
2. 02
   host = localhost

   the tunnel points at the appliance's internal services
3. 03
   Erlang on :1050

   the authentication cookie is hardcoded: no password needed
4. 04
   command as root

   remove_hotfix with path traversal runs a script as root

These internal services are less hardened precisely because "they only listen on localhost." Rapid7 wrote an exploit against the Erlang process listening on localhost:1050: the cookie that process uses to authenticate calls is hardcoded, identical on every device, so no secret needs to be known. From there, an os:cmd RPC call runs system commands. The first step was done: from the internet, without credentials, to code execution on the appliance — in the context of the couchdb user.

From localhost to root

The second bug is for becoming administrator. CVE-2026-15410 is a path traversal in the remove_hotfix workflow of the ctrl-service service, listening on port 8188. The service expects the name of a hotfix to remove; the attacker hands it a traversal sequence like ../../../../var/tmp/privesc pointing to a script already staged on the device. The system makes it executable and runs it as root, then reboots the appliance. In the system-monitor logs recovered by Rapid7 the sequence is visible line by line: chmod +x, execution of the script, shutdown -r now. The chain — unauthenticated SSRF, then code execution, then escalation to root — is complete.

But if the dossier ended here, it would be a routine patching bulletin. The point comes next.

What they took

With root access, the attackers did not deploy ransomware. They emptied the appliance of three specific things: high-value credentials, the active session databases, and the TOTP seed configurations — the shared secrets that generate the six-digit codes of multi-factor authentication. Rapid7 is explicit about the motive: this local harvesting "was designed to ensure long-term, persistent access that could survive standard network-level remediations."

Here is why the "patch and change the passwords" reflex fails. The password you can change. The already-issued session token you can invalidate, if you think of it. But the TOTP seed is the secret behind the second factor: it is the safety net meant for the day the password leaks. If the attacker has walked off with that seed, they can generate every user's valid MFA codes themselves — and they will keep doing so after the patch, after the password reset, until those seeds are regenerated one by one. Not by accident, the only remediation list that explicitly calls for resetting TOTP tokens is the one from a vendor that watched the compromise up close.

The backdoor inside Active Directory

Having gathered the material, the attackers moved inward. Rapid7 observed a sequence that captures what losing an appliance like this means: authentications to domain controllers with no active VPN tunnel, originating directly from the appliance's internal IP address, with workstation names that do not belong to the corporate inventory — kali among them — under the context of the LDAP service account integrated into the appliance itself.

1. 9 July 2026
   Before disclosure

   System logs capture the root escalation in progress.

2. 14 July 2026
   The advisory

   SonicWall publishes SNWLID-2026-0008: two flaws, exploitation confirmed.

3. 14 July 2026
   CISA KEV

   Both CVEs enter the catalog, under directive BOD 26-04.

4. 15 July 2026
   Rapid7

   The MDR team publishes the technical analysis and a PoC for the SSRF.

5. 16 July 2026
   The IOCs

   Rapid7 adds the attacker workstation names and the IPs used.

A remote-access appliance is, by definition, the bridge between the internet and the internal network: it is built to talk to Active Directory. When the attacker is driving it, that legitimate bridge becomes an unmonitored entry channel — because the traffic does not come from a suspicious VPN client, it comes from the device that is supposed to talk to the domain controllers.

What we don't know

The rule of this site applies: say where certainty ends.

• There is no attribution. Rapid7 names no group. The observed IPs belong to a VPN hosting provider (FNS Holdings Limited, ASN 206092): rented, anonymised infrastructure that says little about who is behind it.
• The intrusion narrative rests largely on a single vendor. SonicWall confirms exploitation in the wild, but the detailed reconstruction of the post-access moves — TOTP seed theft, VPN-less lateral movement — is Rapid7's. Strong, consistent with the published IOCs, but not yet replicated by independent third parties.
• The motive is open. No ransomware observed so far. Credential theft, durable persistence and a pivot into AD are compatible with espionage as much as with pre-positioning for a later action. Saying which would be guessing.
• The ATT&CK IDs at the head of this dossier are a reasoned mapping, not copied from an advisory: neither SonicWall nor Rapid7 publishes an official one. They describe the observed behaviours, not a primary source.

What to do

The patch first, because there are no workarounds: bring SMA1000 appliances (6210, 7210, 8200v and CMS) to version 12.4.3-03453 or 12.5.0-02835 and above. But — and this is the point of the whole dossier — the patch alone assumes you have not already been hit, and exploitation is confirmed from 9 July. So: forensic analysis of the appliance for indicators of compromise; if you find even one, treat the device as compromised and re-image the hardware or redeploy the virtual machine, change user and administrator passwords, and reset the TOTP tokens — not a decorative step, but the one that closes the door a password reset alone leaves open.

For retrospective hunting the indicators are documented: in extraweb_access.log, requests to /wsproxy with suspicious host parameters returning HTTP 101, and requests to /__api__/login or /__api__/logout returning 200; in ctrl-service.log, hotfix removals whose name contains a path traversal; and on the Windows side, NTLM logons (Event ID 4624, logon type 3) to domain controllers originating from the appliance's internal IP, with workstation names like kali and no corresponding VPN session.

A CVE gives you a version to fix and a date to fix it by. A stolen TOTP seed has neither: it stays valid until you regenerate it. The patch closes the window they came in through. It does not close the one they carried out with them.