In this article
SonicWall SSL VPN attacks remain a useful warning for any organization that relies on edge appliances for remote access. In August 2025, Akira affiliates targeted SonicWall environments, and reporting described successful VPN logins even where MFA was enabled. The issue was not that MFA had been mathematically broken: credentials or one-time-password (OTP) secrets may already have been exposed during earlier access. A patch addresses vulnerable software; it does not revoke a secret an attacker has copied.
The vulnerability and the exposure window
CVE-2024-40766 is an improper-access-control vulnerability in SonicOS. SonicWall released fixes in August 2024, and CISA added it to the Known Exploited Vulnerabilities catalog on September 9, 2024. By the 2025 campaign, organizations had a clear patching and exposure-management signal. A 2026 scan later counted about 213,900 publicly reachable SonicWall VPN and management interfaces; that figure measures reachable interfaces, not a confirmed count of devices vulnerable to this CVE. It is a reminder to validate versions and exposure rather than infer them from an internet scan. End-of-life appliances, including SMA 100 devices, create an additional risk because they cannot receive current fixes.
Why MFA can remain exposed after patching
Arctic Wolf reported Akira activity against SonicWall SSL VPNs in 2025. Separately, Google Threat Intelligence Group assessed with high confidence that another financially motivated actor, UNC6148, used credentials and OTP seeds stolen in earlier intrusions against end-of-life SMA 100 appliances. Those reports describe related risks, but they do not establish that every Akira login used stolen OTP seeds or that every event involved the same actor or access path. The practical point is clear: after suspected exposure, patching alone does not invalidate passwords, sessions, tokens, or MFA enrollment secrets.
What “patched” needs to mean in practice
MFA remains a strong control when enrollment, recovery, and the underlying account are protected. A copied TOTP seed can let an attacker generate valid codes until the factor is revoked and replaced. Organizations should therefore treat suspected appliance compromise as an identity incident as well as a firmware issue: review logs, terminate active sessions, rotate affected VPN credentials, reset exposed MFA factors, and investigate whether accounts or configuration were changed. Make those actions evidence-based and scoped to affected systems.
Patch debt at the network edge
Patch debt grows when a known fix does not reach every exposed device. VPN concentrators and security appliances deserve short remediation windows because they are reachable from the internet and provide a route into internal environments. Asset discovery, supported-firmware checks, and configuration review should run continuously; a quarterly or annual assessment can supplement these controls but cannot replace them.
What a current security assessment should verify
- External exposure and version checks. Identify internet-facing VPN and management interfaces, confirm firmware against vendor guidance, and distinguish vulnerable assets from interfaces that are simply reachable.
- Credential and session response. Confirm that incident procedures can revoke credentials, TOTP factors, API tokens, and existing sessions after suspected exposure, then verify completion.
- MFA enrollment controls. Review privileged-account enrollment, recovery methods, factor changes, and administrative access. MFA being enabled does not establish that an enrollment secret remains private.
- Authentication monitoring. Alert on unusual source networks, devices, timing, geography, and post-login activity. Investigate successful logins that depart from a user’s normal pattern.
- End-of-life asset disposition. Find unsupported appliances, document a replacement date, and restrict or remove access while replacement is pending.
Actions for security and IT teams
- Run a current inventory of internet-facing VPN and management interfaces; confirm exact product, firmware, support status, and owner.
- For any suspected exposure, patch or isolate the appliance, rotate affected credentials and MFA factors, revoke sessions, and examine logs for persistence or account changes.
- Require phishing-resistant MFA where supported for remote and privileged access, while keeping recovery and enrollment workflows under the same security review.
- Retire unsupported devices or place them behind tightly restricted access until replacement. A compensating firewall rule does not make an unmaintained appliance supported.
- Test access after remediation and record evidence that every affected instance is fixed, restricted, or retired.
Patching answers whether a known software flaw is closed. Incident response must also answer whether an attacker copied credentials, factors, or session material before that fix arrived. Keep those as linked workstreams and verify both before calling the exposure resolved.
Sources and further reading
SonicWall notice: SSL VPN recent threat activity