On Monday, SonicWall disclosed two critical zero-days in their SMA1000 remote access appliances. By Tuesday, most of the coverage was about patching. Patch your SMA1000. Apply hotfix 12.4.3-03526. Check your firmware.
That advice is correct. It's also incomplete, and the gap between correct and complete is where organizations get into real trouble.
Here's what the headlines mostly didn't say: this is the third major security incident on SonicWall SMA1000 hardware in 2026. The July campaign — the second breach, before September's new zero-days were even discovered — was already over by the time patches shipped. And the thing attackers took in July was more durable than access to a vulnerable device. They took the MFA seeds.
What Happened Before This Week
Targeted exploitation of SMA1000 appliances started no later than June 22, according to Field Effect's incident timeline. On July 14, SonicWall disclosed CVE-2026-15409 (a CVSS 10.0 server-side request forgery vulnerability) and CVE-2026-15410 (remote code execution). Chained together, an unauthenticated attacker on the internet could take full control of the appliance.
What the July advisory didn't stop was what was already happening. Attackers used that access to harvest credentials, session tokens, and TOTP multi-factor authentication seeds. Not one-time codes — the seeds that generate them. The root secrets that produce every MFA code indefinitely.
INC ransomware is the primary group running this campaign. New victims started appearing on their dark-web leak site from late July through early August. Some of those organizations applied the July patches. Some reset their SonicWall passwords. The attackers still had the TOTP seeds, which means they still had the ability to generate valid MFA codes for accounts on those networks. Patches fix the vulnerability. They don't invalidate credentials that were already exfiltrated.
Then September came with two more critical zero-days. CVE-2026-83548, a new pre-authentication SSRF vulnerability with a CVSS of 10.0 — maximum severity, no login required. Chain it with CVE-2026-83549, an OS command injection flaw in the appliance management console, and you have unauthenticated remote code execution on a VPN gateway. Both were actively exploited before SonicWall disclosed them. CISA added both to the Known Exploited Vulnerabilities catalog on the same day as the advisory.
If your organization uses SMA1000 hardware and you haven't applied the September patches, that's the first thing to do. The patched versions are 12.4.3-03526 and 12.5.0-02952. SonicWall's advisory has the full list of affected models.
The Bigger Problem Isn't SonicWall
Forbes published a piece last week pulling together data from Verizon's 2026 Data Breach Investigations Report and Mandiant's M-Trends 2026 findings. The numbers are worth sitting with.
The mean time to exploit newly disclosed vulnerabilities is now negative seven days. That's not a typo. Attackers are on average already using flaws seven days before a CVE exists. The SonicWall June/July campaign started before the July 14 advisory. That pattern has a name now: it's normal.
Meanwhile, the median time to fully patch a known-exploited vulnerability rose from 32 days to 43 days in one year. Moving in the wrong direction.
AI-assisted offensive tooling is most of the reason attackers have gotten so fast. Reconnaissance, vulnerability analysis, and exploit development that used to take a skilled human team weeks can now be compressed into hours using AI-assisted tooling. The CVE-to-exploit window collapsed from 56 days in 2024 to roughly 10 hours in 2026. Organizations that are running on a monthly or quarterly patch cycle are operating with a structural gap that attackers are trained to find.
What the "Patch It" Advice Misses
The SonicWall situation is a clean example of a problem that goes beyond VPN appliances. When the breach happens before the patch, and when attackers take credentials rather than just access, patching becomes a post-breach activity rather than a preventive one.
A few things that actually reduce exposure in this environment:
Treat MFA seeds as credentials, not controls. If your MFA is TOTP-based (Google Authenticator, Authy, most hardware tokens) and there's any chance your authentication systems were accessible to attackers — not just your SonicWall, any device or system — rotating MFA seeds is part of incident response. Not resetting passwords. Rotating seeds. Most orgs don't have a process for this because most orgs don't think of MFA secrets as something that can be stolen and replayed. They can be.
Minimize internet exposure of remote access infrastructure. ShadowServer currently sees over 420 SMA1000 appliances reachable from the open internet. The management console port should never be publicly accessible. Many organizations deploy these appliances with default settings and don't revisit what's exposed. An internet-facing appliance management console with a CVSS 10.0 vulnerability is not a theoretical risk — it's an active target.
Assume breach, then verify. If you're running SMA1000 hardware and you haven't investigated your July and August logs for signs of the CVE-2026-15409 campaign, patching September's CVEs doesn't close that chapter. The question isn't just whether you're vulnerable now. It's whether you were already compromised before you learned the vulnerability existed.
Watch vendor security channels with the same urgency as your invoice inbox. The gap between "advisory published" and "actively exploited" is now hours on a good day and negative on a bad one. If your organization doesn't have a monitored process for vendor security bulletins, you're making decisions with stale information.
The third major SonicWall incident of 2026 is a useful case study not because SonicWall is uniquely bad, but because it illustrates something that applies to every internet-facing device and service your organization runs. Attackers have AI-assisted tooling that finds vulnerabilities faster than vendors can patch them. When they get in, they take credentials that outlast the patch. And patching, while necessary, is increasingly a response to something that already happened rather than something being prevented.
If your organization has internet-facing VPN or remote access infrastructure and you're not sure what's exposed or what the patch cycle actually looks like in practice — not on paper, in practice — that's a concrete two-day audit that changes your risk profile meaningfully.
That's the kind of work we do with small teams. Not a framework. Not a 60-page report about what you might consider someday. Actual answers about what's running, what's exposed, and what needs to close.