SURIQ
SonicWall released fixes on July 14 for two zero-day flaws in its SMA 1000 series remote-access gateways that attackers are already using in the wild. The reflex reaction, apply the firmware update, is the easy part. The harder truth, and the one the vendor states plainly in its own advisory, is that a patch does not evict an intruder who already reached the appliance. For an internet-facing box that brokers remote access into your network, the update is step one of a cleanup, not the end of it.
Both bugs, CVE-2026-15409 and CVE-2026-15410, were added to CISA's Known Exploited Vulnerabilities catalog the same day. That listing is the line that matters: CISA adds a flaw only once it confirms real exploitation, so this is not a theoretical race to patch before someone writes an exploit. Someone already has.
What SonicWall actually disclosed
The two flaws hit different parts of the appliance and require different levels of access, which is why they are dangerous in combination.
CVE-2026-15409 is a server-side request forgery, or SSRF, in the SMA 1000 Work Place interface. Server-side request forgery is a bug that tricks a server into making network requests on the attacker's behalf. Per SonicWall's record, a remote attacker needs no login to trigger it and can make the appliance send requests to locations it should never reach, a useful primitive for probing the internal network sitting behind the gateway.
CVE-2026-15410 sits in the SMA 1000 Appliance Management Console, the administrative interface. It allows code injection, meaning an authenticated administrator can run operating-system commands directly on the box. Because it needs admin access, the real concern is an attacker who has obtained or forged an administrator session and then turns console access into command execution on the underlying system.
According to reporting by Help Net Security, SonicWall says the two are being exploited together in observed attacks. The affected and fixed builds break down by branch:
| Firmware branch | Affected builds | Fixed build |
|---|---|---|
| 12.4.x | 12.4.3-03245 through 12.4.3-03434 | 12.4.3-03453 |
| 12.5.x | 12.5.0-02283 through 12.5.0-02800 | 12.5.0-02835 |
If you run any 12.4.3 build from 12.4.3-03245 up to 12.4.3-03434, or any 12.5.0 build from 12.5.0-02283 up to 12.5.0-02800, you are in scope. Upgrade to 12.4.3-03453 or 12.5.0-02835. Note that 12.4.3-03245 was a fixed build in SonicWall's December 2025 SMA 1000 incident; it is an affected build now. Patching this class of device is not a one-time event.
What to do now, in order
SonicWall's guidance goes further than most patch advisories, and the extra steps are the story. After upgrading firmware, the vendor advises that if indicators of compromise are present you should re-image hardware appliances or re-deploy virtual ones, change all user and administrator passwords, and reset every TOTP token, the time-based one-time codes used for multi-factor login. Review the logs before you decide the box is clean.
That sequence exists because a firmware update replaces vulnerable code, not attacker persistence. An intruder who ran commands on the appliance through CVE-2026-15410 could have planted a web shell, harvested session material, or added credentials that survive the update untouched. Rotating passwords and TOTP seeds matters because a remote-access gateway is a credential concentrator: whoever controlled it could read or replay what passed through. Re-imaging is the only way to be sure the running system is the one you shipped, not the one an attacker left behind.
We made this same argument about Ivanti Sentry earlier this year, where organizations that patched but did not rebuild stayed breached through the update. The pattern holds here.
How would you know you were hit
Because the exploited window predates the patch, the useful question is not "am I vulnerable" but "was I already reached." A defender does not need exploit code to hunt for it. Three places to look:
- Outbound requests from the appliance. The SSRF flaw makes the gateway itself originate connections. Traffic leaving the appliance toward internal hosts or unusual external destinations, especially to addresses it has no business contacting, is the clearest tell. This maps to the appliance being used for internal reconnaissance.
- Administrative console activity. Review the management console logs for administrator logins, configuration changes, or command execution you cannot tie to a known change. Unexplained admin sessions are the precursor to the code-injection bug being used.
- Published indicators. SonicWall released indicators of compromise with the advisory. If any match, the vendor's own instruction is to treat the box as breached and rebuild it, not to debate it.
In ATT&CK terms this is exploitation of a public-facing application followed by command execution on the host. If your remote-access gateways are not already feeding their logs into whatever you use for detection, an edge appliance you cannot see inside of is exactly the blind spot attackers are counting on.
The edge keeps being the entrance
This is the second SMA 1000 exploitation story in seven months, and it lands in a long line of remote-access and VPN appliances turned into front doors: we have tracked the ransomware backlog piling up on unpatched edge devices and an authentication bypass in another remote-support appliance. The shape is always similar: a device that sits at the perimeter, speaks to the internet by design, and holds the keys to everything behind it. When one carries an unauthenticated bug like this server-side request forgery alongside an admin-to-command-execution bug, the appliance stops being a boundary and becomes a beachhead.
The practical takeaway is a mindset, not a version number. Treat any internet-facing remote-access gateway on an affected build as compromised until its logs prove otherwise. Patch first, then investigate as if the answer is yes. On a box like this, assuming you are clean is the expensive assumption.