SonicWall SMA 1000 SSRF (CVE-2026-102255) Is Already Being Exploited: Patch Now, Then Assume the Worst

If you run a SonicWall Secure Mobile Access (SMA) 1000 appliance, stop treating last week’s patch as a routine maintenance item. According to The Hacker News, attackers started going after a critical flaw in these devices within days of public disclosure. That’s the window most patch cycles don’t account for.

Here’s what’s been reported, why I think it matters more than the attempt count suggests, and what I’d be doing right now.

What happened

The vulnerability is tracked as CVE-2026-102255 and carries a CVSS score of 10.0. It’s a pre-authentication server-side request forgery (SSRF) bug. Per the advisory language quoted by The Hacker News, it could let a remote attacker “direct the appliance to issue requests on their behalf and reach internal functionality and perform unauthorized operations.”

The timeline is short:

• October 6, 2026: SonicWall released fixes in versions 12.4.3-03670 (platform-hotfix) and 12.5.0-03082 (platform-hotfix).
• October 8, 2026: Threat intelligence firms Defused Cyber and Previdian detected the first exploitation attempts.
• As of the report: Previdian had counted 135 attempts from two unique IP addresses located in the U.S.

One detail stood out to me: SonicWall had not yet updated its advisory to reflect active exploitation when the article was published.

This product has a recent history

CVE-2026-102255 isn’t the first SMA 1000 flaw to be exploited this year. The same report notes that in June 2026, two other bugs in the product, CVE-2026-15409 (CVSS 10.0) and CVE-2026-15410 (CVSS 7.2), were exploited as zero-days by a threat actor dubbed UTA0533. That actor used them to deploy Java web shells and a malware family called KNUCKLEBALL.

Rapid7’s observations, as summarized in the article, describe what happens after attackers get onto one of these appliances. The devices served as a stealthy initial access point to run commands on the operating system and maintain long-term, persistent access. Rapid7 put it this way:

“Once they established a foothold on the appliance, the actors systematically extracted high-value credentials, active session databases, and Time-Based One-Time Password (TOTP) multi-factor authentication (MFA) seed configurations.”

And then:

“With these harvested resources, the threat actors quickly shifted to lateral movement, pivoting from the compromised appliance directly into the internal corporate network.”

To be clear, the source doesn’t say the October activity is tied to UTA0533 or that the new SSRF has been used to drop web shells. What we know is that attempts are happening. The June campaign shows what an attacker can do once they’re inside this class of device.

My take: why 135 attempts is not a small number

It would be easy to read “135 attempts from two IPs” and relax. I wouldn’t.

First, that’s what one vendor’s sensors saw. It tells you exploitation has started. It doesn’t tell you how widespread it is. Early, low-volume activity from a handful of sources often looks like someone testing a working exploit before scaling up.

Second, think about what an SMA appliance is. It’s a remote access gateway. It sits on the edge, faces the internet, and is trusted by the internal network. An SSRF bug in that position is especially bad because the whole point of the attack is to make the appliance send requests you can’t send directly. The device’s privileged network position is what turns a request-forgery bug into a path to internal functionality.

Third, the June incident shows the payoff. Credentials, session databases, and TOTP seeds are exactly what an attacker needs to quietly log in as your users later, even after you patch. If MFA seeds get stolen, your MFA is effectively cloned. Patching the appliance doesn’t undo that.

Finally, the advisory lag matters. If your patch prioritization depends on a vendor marking something as “exploited,” you would have been waiting while attacks were already underway. For edge devices with a CVSS 10.0 pre-auth bug, I’d treat “critical and internet-facing” as enough of a trigger on its own.

What I’d do if I ran an SMA 1000

These are my recommendations, not steps from SonicWall or the researchers. Check the vendor advisory for authoritative guidance.

1. Patch immediately. Get onto 12.4.3-03670 or 12.5.0-03082 (platform-hotfix), or whatever SonicWall currently lists as fixed for your branch. If you can’t patch today, seriously consider taking the appliance’s public exposure down until you can.

2. Don’t stop at patching. If your appliance was internet-facing and unpatched at any point after October 6, I’d treat it as possibly compromised until you’ve checked. Patching closes the door. It doesn’t remove anyone who already got in.

3. Hunt for persistence. Given the June campaign involved Java web shells, look for unexpected files, modified components, and unfamiliar processes on the appliance. If you have endpoint or integrity monitoring that covers it, review that data. If you don’t, ask SonicWall support how to validate the device’s integrity.

4. Look at what the appliance talked to. SSRF means the appliance makes requests on the attacker’s behalf. Review logs for unusual outbound or internal requests originating from the appliance, especially to internal services it doesn’t normally contact.

5. Plan for credential and MFA reset. If you find any sign of compromise, assume credentials, active sessions, and TOTP seeds handled by the appliance are exposed, based on what Rapid7 described in June. That means forcing password resets, invalidating sessions, and re-enrolling MFA so old seeds stop working. It’s painful, but it’s the only way to cut off an attacker holding cloned tokens.

6. Watch for lateral movement. Check authentication logs on internal systems for logins that trace back to the appliance or to VPN sessions at odd times or from odd places.

7. Rethink exposure. This is the third critical SMA 1000 bug exploited this year based on this report. Ask whether the management interface needs to be reachable from the internet at all, and whether you have monitoring on the appliance comparable to what you’d have on a server.

The bigger pattern

Edge appliances keep showing up in these stories for a reason. They’re exposed, they’re trusted, and they’re often harder to monitor than a normal server. The gap between a patch and the first exploitation attempt here was about two days. If your process for edge devices runs on a monthly cycle, this is a good moment to carve out a faster lane for them.

Patch first. Then go check whether you needed to patch sooner.

Sources

• Critical SonicWall SMA 1000 Flaw Targeted in 135 Exploitation Attempts After Patch — The Hacker News, 2026-10-12