SonicWall Patched the SMA1000 on July 14. That Exact Build Is What September's Zero-Day Lists as Vulnerable. Same Box, Same Shape, 49 Days Apart.
- Patrick Duggan
- 21 minutes ago
- 6 min read
On July 14, SonicWall told everyone running an SMA1000 remote-access appliance to patch immediately. Two flaws, chained, exploited in the wild as zero-days. CISA added both to the Known Exploited Vulnerabilities catalog the same day and set a three-day federal clock under Binding Operational Directive 26-04. Patch or unplug. The fixed builds were 12.4.3-03453 and 12.5.0-02835.
On September 1, SonicWall disclosed two more SMA1000 flaws, chained, exploited in the wild as zero-days. CISA added both to KEV on September 2.
The versions listed as vulnerable in the September advisory are 12.4.3-03453 and earlier, and 12.5.0-02835 and earlier.
Read those two paragraphs again. The build that resolved July's emergency is the newest build September's emergency affects. If you did the July patch correctly, on the three-day clock, on the weekend, the way the directive told you to, you landed precisely on the version that the next zero-day hits.
The two pairs, side by side
July's pair was CVE-2026-15409 and CVE-2026-15410. The first is an unauthenticated server-side request forgery in the SMA1000 Work Place interface, rated CVSS 10.0, which opens a websocket tunnel to services that are only supposed to listen on localhost. The second is a privilege escalation reachable by anyone who can talk to an internal service on port 8188 on that localhost, executing arbitrary operating system commands as root through a path-traversal in the remove_hotfix workflow. Rapid7's MDR team found them. Exploitation had been running since at least June 22, roughly three weeks before disclosure.
September's pair is CVE-2026-83548 and CVE-2026-83549. The first is a pre-authentication server-side request forgery in the SMA1000 Work Place interface, rated CVSS 10.0, which reaches sensitive functionality through an unintended alternate access path. The second is an operating system command injection in the Appliance Management Console that on its own requires an authenticated administrator, and chained behind the SSRF does not require one.
Same appliance. Same interface named in the critical half. Same CVSS 10.0. Same architecture: an unauthenticated request-forgery primitive that gets you inside the trust boundary, bolted to a command-execution primitive that was only ever considered safe because it assumed you were already inside. Both discovered as zero-days, both after exploitation was already underway.
What I am claiming, and what I am not
I am not claiming this is a patch bypass. SonicWall has not said that. Rapid7, who found the July pair, published on the September pair and does not reference the July one anywhere in the writeup — I went and read the page to check rather than assuming. There is no public proof-of-concept, no indicators of compromise, and no attribution for the current activity.
It is entirely possible these are independent bugs that happen to live in the same subsystem. That would be its own finding, and not a gentler one.
What is not a matter of interpretation is the version arithmetic. Fixed-in 12.4.3-03453 on July 14. Vulnerable-through 12.4.3-03453 on September 1. Same string, seven weeks apart, opposite sides of the ledger. Whatever the causal story turns out to be, the operational consequence for the person running the box is identical: patching perfectly bought them 49 days.
We did not pre-stage either pair, and that is the fourth time on this box
We had no receipt on CVE-2026-15409 in July and we said so in the post at the time. We have no receipt on CVE-2026-83548 now. Both were zero-days found by other people while already being exploited, and nobody outside the attacker had a timestamp on either. Anyone telling you otherwise is reading their own ingest log and calling it foresight.
What we do have is four months of naming this class of box, and this vendor by brand, before any of it. In March we wrote that the edge firewall was the initial-access surface to worry about while the Cisco ASA was getting popped. In May we ran Edge-Appliance Week, after CISA added three remote code executions in fourteen days and two were edge vendors. In June we wrote that the number-two ransomware crew on earth has one favorite door — your SSL VPN — and named Cisco ASA, SonicWall, and WatchGuard in that sentence. In July we wrote the SMA1000 zero-days up and declined to claim a lead.
That is a call on the surface, not on the bug. It is the weaker of the two claims and it is the one the evidence supports, so it is the one we make.
The version line, which is the whole argument
Why this shape keeps happening to remote-access appliances
An SSL VPN concentrator is a machine whose entire job is to be reachable by strangers and to hold the keys to everything behind it. That is not a bug in the product category, it is the product category. And it produces a specific and repeating architecture: a public-facing web front end, a pile of privileged internal services that were written on the assumption that only the front end could ever reach them, and a thin membrane between the two.
Every one of these incidents is the same story. Somebody finds a way to make the front end issue a request on their behalf, and the membrane turns out to be the only thing that was ever protecting a stack of services that authenticate nobody because they were never supposed to hear from anyone. The SSRF is not the interesting half. The interesting half is the dozen internal endpoints behind it that will run commands as root for whoever asks, because for twenty years nobody could ask.
You cannot patch that with a CVE. It is an architectural bet, and the bet is that the membrane holds. In July the membrane did not hold. In September the membrane did not hold. The fix for that class of problem is not a hotfix number, it is authenticating the internal services too, and that is a rewrite nobody schedules until the second time.
What to do about it
If you run an SMA1000 6210, 7210, or 8200v, the fixed builds are 12.4.3-03526 and higher on the 12.4 branch, and 12.5.0-02952 and higher on the 12.5 branch. Anything at or below 12.4.3-03453 or 12.5.0-02835 is vulnerable, and that explicitly includes machines patched in July.
Do not assume you are covered because you remember patching this appliance recently. Recently is the problem. Go read the build string off the box.
If you have not already, put the management console behind something. CVE-2026-83549 needs an authenticated administrator to matter on its own, and the reason it matters anyway is that it is reachable through a hole in the thing in front of it. Every layer you make the SSRF traverse is a layer the chain has to survive.
And when you finish patching, write down the date and the build number somewhere you will find it again. The single most useful artifact in this entire story was a version string in a July advisory that turned out to mean something different in September. That is only visible to someone who kept the first one.
The honest number
Two zero-day pairs, one appliance, 49 days. Zero receipts on our side for either. One correct call on the category, made four months early and repeated four times, which is worth something but is not worth what a real detection lead is worth, and we are not going to inflate it into one.
The next time somebody tells you patch management is a solved problem and the failures are all negligence, this is the counterexample. The diligent operator here — the one who patched inside a three-day federal window in the middle of July — is in exactly the same position today as the one who ignored it.
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-patched-the-sma1000-on-july-14-that-exact-build-is-what-september-s-zero-day-lists-as-vul
Comments