SonicWall published SNWLID-2026-0016 on September 1, 2026, covering two SMA1000 flaws it says are under active exploitation. The advisory lists the affected versions as 12.4.3-03453 and older, and 12.5.0-02835 and older. Those two build numbers are the exact versions SonicWall shipped 49 days earlier as the fix for a different actively exploited pair.
The same two strings, on opposite sides of the table
SNWLID-2026-0008, July 14, 2026, under Fixed Version(s):
12.4.3-03453 (platform-hotfix) and higher versions. 12.5.0-02835 (platform-hotfix) and higher versions.
SNWLID-2026-0016, September 1, 2026, under Affected Version(s):
12.4.3-03453 (platform-hotfix) and older versions. 12.5.0-02835 (platform-hotfix) and older versions.
A team that patched correctly in July landed on that boundary and sat there for 49 days.
The components are the same across both advisories. July's CVE-2026-15409 was an SSRF in the SMA1000 Appliance Work Place interface; September's CVE-2026-83548 is a pre-authentication SSRF in that same interface, "due to an unintended alternate access path." July's CVE-2026-15410 and September's CVE-2026-83549 are both command execution in the Appliance Management Console requiring an administrator.
This is not the same bug, and SonicWall has not called the July fix incomplete. The classifications moved: the SSRF went from CWE-918 alone to CWE-918 plus CWE-441, Unintended Proxy or Intermediary, and the console bug went from CWE-94 to CWE-78. CWE-441 is the tell. July closed a route into the Work Place interface. September describes a second route to the same functionality — one the vendor says can act as a forward proxy.
The practice: retest the component, not the version string
A vendor fix is scoped to a reported reproduction, not to a component's reachability, and nothing obliges the vendor to say which of the two it did. That distinction has cost time before — N-able shipped a silent auth-bypass fix in April and the CVE arrived 95 days later, after the incomplete fix was exploited.
So the question after patching an internet-facing appliance is whether the component the advisory named is still reachable in the way the advisory described. Not whether the build number went up. A scanner answers the version question and cannot answer the reachability question, because reachability is a property of your deployed configuration — which interfaces are exposed, from where, and what they proxy to.
What that looks like on this product: Rapid7's July analysis showed the /wsproxy endpoint accepting an unauthenticated request that opened a WebSocket TCP tunnel to appliance-local services, reaching an Erlang process on localhost:1050 for code execution. Escalation ran through a path traversal in the remove_hotfix workflow on port 8188, executing a staged script as root. None of that is a version number.
The honest cost: this needs a person and a maintenance window on a device in the traffic path, and no product does it for you — the vendor's own tooling reports the version, which is the answer you already have. Budget it per appliance, once a quarter, not per CVE.
When you can't get the window, the fallback is to make reachability your decision rather than the vendor's: source-restrict the Work Place and management interfaces so the exposed surface no longer depends on how narrowly a fix was scoped. Both advisories list Workaround: None, so between an advisory and a hotfix, network placement is the only lever you have.
Hunting is asymmetric here too. July's advisory shipped a greppable indicator list; September's ships none, directing customers to contact support instead. If you are looking today, this is the only published set, and it describes the old chain:
extraweb_access.log /wsproxy requests with suspicious host parameters, HTTP 101
extraweb_access.log /__api__/login or /__api__/logout returning HTTP 200
ctrl-service.log hotfix rollbacks with path-traversal names
/var/lib/unit/conf.json routes for /__api__/login or /__api__/logout
That last one is the strongest single check: SonicWall states those URIs do not exist in a legitimate configuration.
There is a second half that no hotfix reaches. Resecurity reported on August 1 that attackers extracted credentials, active session databases and TOTP seed configurations from compromised appliances, then authenticated to domain controllers from the appliance's internal address without the VPN. Both advisories make password and TOTP resets conditional on finding indicators first. A seed taken in July still works in September, and the window for finding that out closes while the first investigation is still open.
What to check this week
- For every internet-facing appliance patched in the last 90 days: which component did the advisory name, and did anyone confirm after the patch that the component stopped being reachable — or only that the version incremented?
- On SMA1000: are you on 12.4.3-03526 or 12.5.0-02952 and higher? 12.4.3-03453 and 12.5.0-02835 were July's fixed floor and are September's affected ceiling.
- Were administrator passwords, directory bind accounts and TOTP seeds rotated after the July patch, or only after indicators were found?
- Can you still produce
extraweb_access.logandctrl-service.logcovering June 22 through July 14? If they have rolled off, that is the finding. - Who can reach the Appliance Management Console today, and from which source ranges?
No public reporting establishes that any organization which applied the July patch was then compromised through the September flaws. CISA added CVE-2026-83548 and CVE-2026-83549 to the KEV catalog on September 2, the day after the advisory, due September 5; July's pair was added the day it was disclosed. KEV moved fast both times and still could not tell you that the build you patched to in July was the build September would list as affected. That is a fact about scope, not exploitation, and it lives in the version table — KEV membership confirms exploitation rather than setting your patch trigger.
North InfoSec runs AI-assisted penetration testing and security assessments, including the kind of post-patch component retesting described above. northinfosec.com