SonicWall SMA1000 CVSS 10.0 SSRF flaw under active attack, internal CouchDB targeted

Attack attempts against a maximum-severity SonicWall SMA1000 vulnerability have been observed in the wild, according to BleepingComputer. The flaw, tracked as CVE-2026-102255, is a server-side request forgery (SSRF) weakness rated CVSS 10.0 by the vendor. It lets a remote, unauthenticated attacker force the appliance to issue proxy requests that reach internal services. Security firm Previdian captured the activity on its honeypot network, but has not confirmed that any of the attempts resulted in an actual compromise.

How the attack works

According to BleepingComputer's reporting, the observed requests target the internet-facing Appliance WorkPlace component, also referred to as Extraweb. An attacker sends a crafted HTTP OPTIONS request that abuses the SSRF condition to make the appliance itself connect to a CouchDB database listening on the loopback address 127.0.0.1, port 5984.

The payload then attempts to traverse into a CouchDB design document and invoke its _rewrite function, presenting HTTP Basic authentication credentials that decode to admin:admin. If the internal forwarding is accepted, the attacker could perform unauthorized operations on the appliance itself. From a user's perspective there may be nothing visible on the normal VPN login screen, while administrators would need to look for anomalous OPTIONS requests, unexpected loopback access to CouchDB, and changes to configuration or service state.

Affected versions and the fix

SonicWall's advisory, SNWLID-2026-0017, lists the affected products as the SMA1000 6210, 7210 and 8200v models running hotfix builds 12.4.3-03526 and earlier or 12.5.0-02952 and earlier. The older SMA 100 Series appliances and the SSL-VPN feature on SonicWall firewalls are not affected. Fixed builds are 12.4.3-03670 and later, or 12.5.0-03082 and later.

The same advisory covers three further vulnerabilities, CVE-2026-102256, CVE-2026-102257 and CVE-2026-102258, which if left unpatched introduce additional risks such as remote code execution, path traversal and stored cross-site scripting.

Notably, SonicWall's notice stated at the time of its update that there was no evidence of active exploitation, a position that sits uneasily beside the honeypot observations already collected by Previdian. Separately, Shadowserver counts more than 400 SMA1000 devices exposed to the internet, although it is unclear how many of those are honeypots, already patched, or genuinely vulnerable.

Detection and mitigation

For defenders, the suggested starting points are logs of OPTIONS requests hitting WorkPlace or Extraweb, any paths referencing 127.0.0.1:5984 or the _rewrite function, and Basic authentication headers whose decoded value is admin:admin. Also worth checking are CouchDB audit logs, appliance configuration files, unexpected service restarts, and unusual logins or credential changes for SMA administrators and VPN accounts.

One caveat from the analysis: network logs alone cannot establish whether an attack succeeded, since TLS termination and the appliance's internal requests are typically not visible in standard captures. Correlating external requests, internal CouchDB activity, configuration changes and authentication events over time is the reliable way to tell probing apart from a successful breach.

Priority mitigations are straightforward: apply the fixed hotfix, restrict internet exposure of the WorkPlace interface using firewall rules or a WAF, rotate management credentials, and isolate any appliance where indicators of compromise appear.

Why it matters

Remote access gateways are among the highest-value targets in any network, because a pre-authentication compromise turns the appliance into a foothold behind the perimeter. A CVSS 10.0 SSRF on an internet-facing SMA1000, combined with more than 400 exposed devices and evidence that attackers are already probing the bug, makes this an urgent patch rather than a routine one. The gap between the vendor's statement that no exploitation was known and the honeypot activity also illustrates how quickly attackers weaponize fresh advisories, and why administrators should not wait for confirmation of successful breaches before acting.