Third SonicWall SMA1000 SSRF in 13 Weeks, Same Internal Database, Same admin:admin. One Attacker IP Was Public All Along, and We Missed It.
In July, an attacker Volexity calls UTA0533 tricked SonicWall's SMA1000 remote-access appliance into proxying a request to its own internal CouchDB database, then logged in with admin:admin. In September, CISA added a second pre-authentication SSRF in the same WorkPlace interface to its exploited list. On October 9, a honeypot run by Previdian caught a third one: a crafted request that again asks the appliance to talk to CouchDB on 127.0.0.1, port 5984, and again sends the username admin and the password admin. Three doors in thirteen weeks, and they all open onto the same room.
What the October request actually looks like
SonicWall published advisory SNWLID-2026-0017 on October 5 and shipped hotfixes on October 6. CVE-2026-102255 is a pre-authentication server-side request forgery, CVSS 10.0, which SonicWall describes as an unintended alternate access path in the Appliance WorkPlace interface. Affected: SMA1000 6210, 7210 and 8200v, physical and virtual, on 12.4.3-03526 and 12.5.0-02952 and earlier. Fixed: 12.4.3-03670 and 12.5.0-03082. The SMA 100 series and firewall SSL-VPN are not affected.
Two days later the traffic started. Defused said on October 9 that its SonicWall SMA decoys had been seeing unauthenticated SSRF traffic "since yesterday." Previdian's telemetry page puts its first sighting at October 9, 00:33 UTC, and its last on October 10: 135 attempts, two US addresses, one sensor. Ryan Dewhurst, Previdian's founder, told BleepingComputer they had not determined whether any attempt succeeded.
Previdian posted a screenshot of one request, and it is worth reading slowly. It is an OPTIONS request, the kind a browser sends before a cross-site call, with an Origin header and an Access-Control-Request-Method of GET. The request line does not name a path on the appliance. It names http://127.0.0.1:5984, the internal CouchDB, and walks from an Extraweb translation prefix, __EXTRAWEB__TRANSLATE, through dot-dot segments into a CouchDB design document and its _rewrite handler. The Authorization header is Basic YWRtaW46YWRtaW4=, which decodes to admin:admin. The user agent claims to be Safari 17.4.1 on macOS 14.7.2. Dewhurst says this is a different technique from the July and September bugs. The destination is not different at all.
Same room, third door
Here is what bothers me. In July the wsproxy endpoint was the door. In September it was a WorkPlace alternate access path. In October it is Extraweb. Each fix closed a door. None of them, as far as any public advisory says, changed what was waiting on the other side: a database that answers to whoever the appliance forwards, and an attacker who still expects admin:admin to work. We can't tell from the outside whether those credentials still open CouchDB on a patched box. The attacker's tooling clearly thinks they might.
That's the pattern we wrote about in September, when the July-patched build turned up on the vulnerable list for the next zero-day. The SSRF is the headline. The internal services that trust anything arriving from localhost are the actual problem, and they keep surviving the patches.
Not in KEV yet, and SonicWall still says not exploited
We pulled CISA's catalog again on October 14. The current version is still 2026.10.13, released October 13 at 19:10 UTC, with 1,741 entries, and CVE-2026-102255 is not one of them. Its July siblings, CVE-2026-15409 and 15410, are in, both flagged for known ransomware use. September's pair, CVE-2026-83548 and 83549, are in too. SonicWall's advisory still reads, verbatim, "There is no evidence that these vulnerabilities are being exploited in the wild." Canada's national cyber agency (CCCS) updated its alert AV26-1017 on October 9 to say open-source reporting shows exploitation. Shadowserver counts a little over 400 SMA1000 appliances on the internet.
If you own one of those 400, don't wait for KEV. The last two SMA1000 SSRFs both made the list. Every week you wait is a week the third one gets to be a zero-day for you personally.
A correction: one address was public, and we said none were
Our October 12 post said both attacking addresses were behind Previdian's paywall. One wasn't: Previdian posted 146.70.143.142 publicly on X on October 9, and that post now carries a dated correction.
We checked again on October 14 and it's in our feed, under source manual-batch-sma1000-cve-2026-102255, written, read back by its record id, and confirmed in the downloaded ips.csv. We scored it 75. It's a single sensor's sighting, and the address sits in an M247 data center in Los Angeles, the kind of rented hosting that turns over tenants. That puts it in the default ips.csv, which takes confidence 50 and up, but below the 80 our own edge shield blocks on, so a min_confidence of 80 leaves it out. That's your dial, not ours.
Graph-enriching it turned up context, not attribution. AbuseIPDB has one report, from September 22, of the same address probing generic login paths on someone's web server, so it was scanning before this CVE existed. A neighbor in the same /24, 146.70.143.166, was listed by SSL Blacklist as an XWorm command server in March. Same hosting block, different tenant, probably. Treat it as a hint. The second address is still behind the paywall, and we are not going to guess at it.
What our edge saw: nothing, because it couldn't
We ran our standard edge check for the markers in that request: __EXTRAWEB__, _rewrite, the 5984 port and the published address. Since September 14: zero matches in 17,241 edge blocks, 37,738 canary hits and 1,602 origin honeypot captures. The address itself has no history at our edge.
That zero was blindness, not quiet. We don't run an SMA1000, and until this week nothing at our edge answered like one, so a scanner looking for SMA1000 WorkPlace had nothing to come back for. Defused and Previdian saw this because they run decoys shaped like the real thing.
We've closed that the same way we closed NetScaler, FortiGate, PeopleSoft and Ivanti. Edge Shield 2.12.0 went live on October 14 (Cloudflare version aa776cab; we're on 2.13.x now). It traps requests to /workplace/ and /__api__/, and, anywhere on our zones, the CouchDB SSRF markers extraweb, /_rewrite and :5984. We tested the rule against Previdian's published capture, the OPTIONS request to /__EXTRAWEB__TRANSLATE/…/_rewrite/… with Basic admin:admin. It hasn't caught anything real yet. When it does, the next sweep gets a timestamp instead of a zero. We have no lead to claim on this one and we're not claiming one.
If you only have an hour
First, find out whether you have an SMA1000 6210, 7210 or 8200v, including virtual. If you do, put it on 12.4.3-03670 or 12.5.0-03082 today. Then search the appliance's web access logs back to October 6 for OPTIONS requests containing __EXTRAWEB__TRANSLATE, _design, _rewrite or 127.0.0.1:5984, and for the header value YWRtaW46YWRtaW4=. SOCRadar is right to call those hunting leads rather than confirmed indicators. A hit means somebody tried. Then check for traffic from 146.70.143.142.
If you can't patch today, take WorkPlace off the open internet until you can. And if your appliance was ever exposed during the July or September windows and you never ran a compromise assessment, this is the week. Three SSRFs into the same database means whoever got in before may still have the keys.
Primary sources: SonicWall advisory SNWLID-2026-0017, Previdian's October 9 post and CVE-2026-102255 telemetry page, Defused's October 9 post, CCCS alert AV26-1017, and CISA's KEV catalog version 2026.10.13.
Was this useful? Rate this post. The widget is at the bottom of the page, and we read every response.
Every indicator in this post is in the feed. Free.
1.58M+ IOCs, STIX 2.1 / TAXII, 88% novel vs ThreatFox, exploited-CVE leads ahead of CISA. No credit card — a free API key in 30 seconds, and you can audit every claim above against the live endpoints.
Was this useful? Thirty seconds, no cookies, no tracking, no third parties, your address hashed and never stored. If the box below does not load, the same question lives at https://analytics.dugganusa.com/nps.html?post=sonicwall-sma1000-cve-2026-102255-third-ssrf-same-couchdb-admin-admin
Comments