SonicWall published a fix on 6 October 2026 for CVE-2026-102255, a pre-authentication server-side request forgery flaw in the SMA1000 WorkPlace portal. The company scored it 10.0, listed no workaround, and said there was no evidence it was being exploited. Three days later, the security firm Previdian told BleepingComputer that its honeypot network had recorded attempts matching the flaw.
The vendor behaved well, shipping a hotfix before anyone reported an attack. The problem is what that fix competes with: this is the third pre-authentication 10.0 flaw in the same portal since July, after the two we covered in September.
What actually happened
WorkPlace is the SMA1000's user login portal, the page remote staff open to reach internal applications. CVE-2026-102255 comes from what SonicWall's advisory calls an unintended alternate access path into it, and it is reachable before authentication. CISA's enrichment of the CVE record gives the vector AV:N/AC:L/PR:N/UI:N/S:C/C:H/I:H/A:H: no privileges, no user interaction, scope changed.
Affected appliances are the SMA1000 6210, 7210 and 8200v on 12.4.3-03526 and earlier or 12.5.0-02952 and earlier, fixed in 12.4.3-03670 and 12.5.0-03082.
| Date | Event |
|---|---|
| 14 July 2026 | CVE-2026-15409, pre-authentication SSRF in the same portal, 10.0, SNWLID-2026-0008. SonicWall reported multiple cases of exploitation and it reached the CISA Known Exploited Vulnerabilities catalog. |
| 1 September 2026 | CVE-2026-83548, another pre-authentication SSRF in the same portal, 10.0, SNWLID-2026-0016, added to the KEV catalog the next day. |
| 6 October 2026 | CVE-2026-102255, SNWLID-2026-0017. No workaround. SonicWall stated no evidence of exploitation for any flaw in the release. |
| 9 October 2026 | Previdian reports honeypot attempts matching the flaw. |
Previdian's account, as reported by BleepingComputer, describes an OPTIONS request to the WorkPlace Extraweb interface carrying an HTTP Basic header that decodes to admin:admin, attempting to make the appliance reach a CouchDB design document on 127.0.0.1:5984. Previdian said it is unclear whether those attempts would have compromised anything, and that distinction matters: a honeypot record is evidence of interest, not of an intrusion.
Shadowserver's count, cited by BleepingComputer, is more than 400 SMA1000 appliances reachable from the internet. That counts addresses that answered, not organizations, and says nothing about how many are patched.
The gap: the portal answers before it identifies anybody
Everything the SMA1000 does to establish who someone is sits behind the request this flaw abuses.
- Multi-factor authentication and one-time codes evaluate a person once a credential has been presented, and a pre-authentication flaw is defined by never presenting one. SonicWall's guidance after the earlier waves included resetting TOTP tokens.
- The access policy engine decides which internal applications a session may reach. An SSRF asks the appliance to make the request instead, from a position the policy engine already trusts.
- Patching was the right answer and SonicWall provided it promptly. It is also the answer now given three times for one portal since July.
In CSO Online's coverage, an industry analyst called three 10.0 flaws in one interface in roughly three months a pattern rather than bad luck, and advised taking the WorkPlace interface and management console off the open internet where possible.
A portal that has produced three pre-authentication 10.0 flaws since July is not only a patching problem. It is a reachability problem that patching keeps solving one advisory at a time.
What would have had to be true
Ask who legitimately needs to open the WorkPlace portal. The answer is the organization's remote staff, on the laptops, phones and tablets it admitted to its groups. It is not the whole internet, and never was.
Source restriction in front of a published portal is not exotic, and the firewall in front of these appliances can already do it. It is rarely the operating state because the list decays from the moment it is written: somebody works from home, a contractor starts, a provider reassigns an address overnight. The failure mode is lopsided, because an address left in too long is silent while a missing one is a support ticket in minutes.
One objection deserves meeting. A remote-access portal is the front door, so restricting it by source sounds circular, but the answer about where a trusted device is working comes from the device rather than the portal, and it arrives before the portal is asked anything.
Where Veribound would have fitted
Veribound is additive and informs rather than enforces. The appliance stays, the portal stays, the access policy and the one-time codes keep doing their jobs, and the organization's own firewall keeps enforcing its own rules, unchanged.
An agent on each staff device keeps confirming it is still the one the organization trusted. What reaches the firewall in front of the appliance is a trusted origin: the network that device is connecting from, in practice its public address. Those arrive as address-group updates against policy the organization already has, which is the one property of this portal that did not have to wait for the next advisory.
Applied here:
- The internet-wide sweep finds nothing, because an unrelated network gets no reply and the appliance never reaches a target list.
- The crafted OPTIONS request does not arrive, so the unintended access path is never asked to parse it.
- Staff keep working, because the portal still answers the people who need it.
- The list maintains itself, which is the part that was failing, and it changes when somebody changes network.
What this would not have done. It does not fix CVE-2026-102255, and the hotfix is still required, as is the investigation SonicWall's earlier guidance asks for on appliances exposed during the July or September windows. Persistence established in one of those windows survives a change in reachability, because it is already inside. It does nothing about an internal service that answers admin:admin, a separate decision on the far side of the appliance. It would not distinguish an attacker working from a device and network the organization already trusts. And the honest limit is scale: somebody has to decide which people are in, and a portal serving tens of thousands is a larger enrollment undertaking than one serving a department.
Three advisories in three months is a vendor finding and fixing its own bugs, which is what you want. It is also three occasions on which the only thing separating an affected appliance from an unaffected one was whether it answered a stranger.
Source: Max severity SonicWall SMA1000 flaw now exploited in attacks, BleepingComputer, 9 October 2026.