SURIQ
SonicWall patched a flaw in its SMA1000 remote-access gateways on October 6. Within about a day, honeypots were already logging attempts to exploit it. That speed is the real story. CVE-2026-102255 carries a CVSS score of 10.0, and it is the third pre-authentication server-side request forgery disclosed in the same SMA1000 web interface this year. The repeating shape says more than the single bug: an internet-facing VPN appliance whose own front-end can be coaxed into talking to the trusted services on its loopback address. Here is what it reaches, who is exposed, and how you would know if someone got there before you patched.
What CVE-2026-102255 lets an attacker reach
CVE-2026-102255 is a pre-authentication server-side request forgery (SSRF) in the WorkPlace interface of SonicWall SMA1000 appliances. A remote attacker with no credentials can make the appliance send requests on their behalf, including to services bound to its own loopback address. SonicWall rates it CVSS 10.0, the maximum.
SSRF is often filed as a middling web bug: a server is tricked into fetching a URL. On a general web application that usually means scanning an internal subnet or hitting a cloud metadata endpoint. On the SMA1000 it means something sharper. Ryan Dewhurst, founder of Previdian, who captured the live attempts in honeypot logs, reported that the probes steered the appliance toward its own CouchDB database running on the loopback address, presenting the default admin:admin credential pair. That database holds the appliance's own state. So this is not a request-forwarding nuisance. It is a path from the open internet to the control plane of the box that guards your remote access.
Affected versions, the fix, and exploitation status
The flaw affects SonicWall SMA1000 models 6210, 7210, and 8200v. On the 12.4 branch, firmware 12.4.3-03526 and earlier is vulnerable; on the 12.5 branch, 12.5.0-02952 and earlier. SonicWall SMA 100 series devices and the SSL-VPN on SonicWall firewalls are not affected. The fix is 12.4.3-03670 on the 12.4 branch and 12.5.0-03082 on the 12.5 branch.
| Branch | Vulnerable | Fixed in |
|---|---|---|
| 12.4.x | 12.4.3-03526 and earlier | 12.4.3-03670 |
| 12.5.x | 12.5.0-02952 and earlier | 12.5.0-03082 |
On exploitation status, be precise: the in-the-wild activity is confirmed by honeypot telemetry, and SonicWall has published no workaround. At the time of writing the CVE was not yet listed in CISA's Known Exploited Vulnerabilities catalog, though confirmed active exploitation of a CVSS 10 pre-auth flaw clearly meets that bar, so expect it to land there. Treat it as already under attack.
Three pre-auth SSRF holes in one interface this year
This is where it gets uncomfortable for anyone running an SMA1000. In July, SonicWall patched two pre-auth flaws in the same product line, CVE-2026-15409 and CVE-2026-15410, which chained SSRF with command injection and were exploited as zero-days. We wrote about that round again when exploitation was confirmed. Now a third pre-auth SSRF surfaces in the same WorkPlace front-end. Three times in one year, that single web tier has shipped an alternate access path a stranger can reach without logging in.
When one interface produces that cadence of serious bugs, patching the latest CVE is not the whole answer. The right posture is to treat that interface as hostile surface: limit who can reach it, watch it closely, and plan for a fourth. SonicWall gear has drawn sustained attacker attention. By the company's own count reported by BleepingComputer, CISA's catalog already lists 19 SonicWall flaws from the past four years, 13 of them tied to ransomware activity.
Patched in a day, probed in a day
The gap between the fix and the first exploitation attempts was roughly 24 hours. For an internet-facing appliance with no workaround, that window is the whole game. A vendor advisory doubles as a targeting list: publishing it tells every scanner operator exactly which box to point at and what to send. If your SMA1000 was reachable from the internet between disclosure and your patch, you cannot assume you were missed. You can only check.
That is the part the advisory does not cover. Patching closes the hole going forward; it tells you nothing about whether someone walked through it first. On a pre-auth flaw that needs no credentials and leaves no failed-login trail, your only coverage for the exposed window is in the logs.
What to look for in the logs
The live attempts have a recognizable shape. Dewhurst's honeypot data shows probes sending crafted OPTIONS requests to the WorkPlace interface to steer the appliance toward its loopback database, presenting default credentials. Pull your SMA1000 access and application logs and look for these markers.
Method: OPTIONS requests to the WorkPlace / Extraweb interface Target: appliance-originated requests to its loopback CouchDB (127.0.0.1:5984) Credential: HTTP Basic admin:admin against that internal database Anomaly: any loopback or outbound request the appliance does not normally make
None of these are things a healthy SMA1000 produces on its own, so even a handful of matches is worth a full incident review. If you find them after the patch date, the fix held; if you find them before it, treat the appliance as suspect and rotate anything it stored.
Patch now, then hunt the exposure window
Upgrade to 12.4.3-03670 on the 12.4 branch or 12.5.0-03082 on the 12.5 branch today. There is no mitigating configuration, so the update is the only fix. Then do the part the advisory skips: review the logs above for the window your appliance sat exposed, and keep the WorkPlace interface off the open internet where your deployment allows it. On a device with this track record, the safe assumption is that it will be tested again.