CVE-2024-40766 is an improper access control flaw in SonicWall’s SonicOS, the firmware that runs the company’s firewalls. CVSS 9.3. SonicWall shipped a fix back in 2024. So why is the SANS Internet Storm Center writing about it again in mid-2026? Because the patch did exactly what it promised, and a lot of organizations are still getting breached through the same boxes. The bug is closed. The accounts that were exposed while it was open are wide open and logging in.

That gap is the most underrated problem in practical cybersecurity right now. We treat “patched” as a synonym for “safe,” and on a spreadsheet it looks like a closed ticket. An attacker who pulled your local firewall credentials during the exposure window does not care that you applied the update last Tuesday. Those passwords still work. The door is fixed; they copied the key months ago.

What CVE-2024-40766 Actually Left Behind

The flaw let an unauthenticated attacker reach SonicOS management and the SSLVPN in ways they shouldn’t have been able to. During the window it was exploitable, threat actors didn’t just poke around. They harvested local user accounts and password material straight off the device. Ransomware crews, Akira among them, leaned on it hard precisely because firewall VPN credentials are a clean, quiet way into a network.

Here’s the part that bites. When you upgrade SonicOS, the patch corrects the code path. It does not rotate the local user passwords sitting in the config. It does not invalidate the credentials an attacker already grabbed. It does not reset the default or carried-over passwords that migrated from device to device over the years. So an organization patches, marks it done, and the attacker logs back in through the VPN with a perfectly valid account weeks later. No exploit required at that point. Just a username and a password that nobody thought to change.

This is configuration debt, and it survives patching because patching was never designed to clean it up.

Where Patch-Centric Cybersecurity Falls Apart

Most patch programs are built around a single question: is the vulnerable version still running? That’s a code question. It misses every problem that lives in state rather than in binaries. Leaked credentials are state. Backdoor accounts are state. A weak local admin password that’s been on the box since 2019 is state. You can patch a firewall to the latest firmware and still be running the same exposed identities you had before the fix.

The WhatsApp phishing campaign making the rounds this month is the mirror image of the same lesson. Attackers push fake business documents that drop VBScript and hand them remote access. No CVE involved. Nothing to patch. The entire intrusion runs on a user’s decision and a foothold that traditional threat-protection tooling often waves through. Whether the way in is a leaked VPN password or a malicious script, the common factor is that your vulnerability scanner reports a clean bill of health while the attacker walks in on legitimate-looking access.

Patch management answers “is this version safe to run.” It does not answer “has this asset already been compromised, and does that compromise persist after the fix.” Those are different questions, and treating the first as if it covers the second is how patched environments keep getting owned.

What To Do Before The Next Valid Login Succeeds

If you run SonicWall firewalls, or any edge VPN appliance that’s been through a critical access-control CVE, patching is step zero, not the finish line. Assume the credentials on any device that was exposed are burned, and act accordingly. The work is tedious and unglamorous, which is exactly why it gets skipped.

Immediate actions, this week:

• Reset every local account on affected appliances, including service and admin accounts. Don’t reuse old passwords or a shared scheme across devices.
• Force a password reset for all SSLVPN users and rotate any pre-shared keys tied to the device.
• Pull the appliance’s account list and hunt for users you don’t recognize. Attacker-created accounts are a common persistence trick after this class of bug.
• Enable multi-factor authentication on every VPN and management login. A stolen password is worthless without the second factor.
• Review logs for successful VPN logins from unexpected geographies or odd hours going back to the original exposure window, not just the last 30 days.

Ongoing, so this doesn’t recur: tighten management-plane exposure so SonicOS administration isn’t reachable from the open internet, and put the SSLVPN behind brute-force controls that lock out credential-stuffing attempts at the edge. Add threat detection that flags a valid account behaving abnormally, since the next intrusion won’t trip a signature; it’ll look like a normal login from a real user. Build a credential-rotation step into your post-patch checklist for every edge device, so “we patched it” automatically triggers “and we rotated what it held.” That’s security hardening that costs an hour and closes a hole patching never touches.

This is what defense in depth actually means in operation. Not a stack of products. A series of independent checks where any single one failing, the unpatched box, the leaked password, the unmonitored login, doesn’t hand over the network on its own.

Exposure And Vulnerability Are Two Different Tickets

The cleanest fix to this whole mess is conceptual. Stop letting one ticket close two problems. A vulnerability ticket tracks “is the flaw present.” An exposure ticket tracks “what did this flaw touch while it was open, and is that still trusted.” When a critical CVE hits an authentication or VPN device, open both. Close them separately. The vulnerability ticket closes when you patch. The exposure ticket closes when every credential, key, and account that device held has been rotated and audited.

CVE-2024-40766 is a year and a half old and still producing fresh victims. Not because anybody failed to patch. Because the patch was treated as the whole job, and your incident response plan needs to assume that a patched device can still be a compromised one. The vendors who keep getting hit aren’t behind on updates. They’re behind on the cleanup the update was never going to do for them.

Sources

• CVE-2024-40766: The Patch Fixed the Bug. Nobody Fixed the Configuration.
• WhatsApp phishing attack uses fake business docs to hack PCs