CVE-2024-53704 – SonicWall SSLVPN authentication bypass – what to do

What is CVE-2024-53704?

This vulnerability lives in the SSLVPN authentication path of SonicWall’s SonicOS firmware. An attacker who can reach the VPN endpoint can convince the device that they have already logged in, even though they have not supplied valid credentials. The flaw is classed as an improper authentication issue – the software fails to verify that the user is who they claim to be before granting access.

For the wider picture, our Known Exploited Vulnerabilities tracker lists every flaw CISA has confirmed under active attack.

It is rated 9.8 on the CVSS scale, which places it in the critical range. The rating reflects a combination of easy remote exploitation, full network‑level impact and the fact that the vulnerability is already being used in ransomware attacks.

Why should you care?

If you run a SonicWall appliance that offers SSLVPN, a successful exploit gives a remote attacker the same rights as a legitimate VPN user. In practice that means they can reach internal servers, extract data, or deploy ransomware without ever touching the perimeter firewall. The CISA catalogue lists this as a known‑exploited vulnerability, and the agency has explicitly required organisations to apply the vendor’s mitigations or stop using the product until a fix is in place.

Technical description

The exact code paths have not been published, but the NVD summary tells us the problem lies in the authentication routine that processes SSLVPN login requests. Instead of checking the cryptographic proof that proves a user’s identity, the routine accepts a malformed or replayed token. Because the check is performed after the TLS tunnel is already established, an attacker can bypass the normal username/password step entirely.

What makes the issue especially dangerous is that the SSLVPN service is often exposed to the internet to allow remote workers to connect. An attacker only needs to know the public address of the VPN endpoint and a few bytes of data to trigger the bypass. Once inside, they inherit whatever network permissions the VPN profile grants – typically access to file shares, management consoles and other internal services.

Am I affected?

The vulnerability affects SonicOS releases in the 7.1.1 branch that fall within the range identified by the vendor. The exact list of vulnerable and patched releases is reproduced in the table below, which is generated automatically from the NVD data.

To find out whether your appliance is running a vulnerable build, use one of the following methods:

• Log in to the SonicWall web interface, navigate to System > Settings and note the firmware version displayed on the dashboard.
• From the command‑line interface (CLI), issue the command show version. The output will contain a line that starts with Version: followed by the build identifier.
• If you manage the device through a central management platform, query the inventory for the SonicOS version field.

Cross‑reference the version you see with the table below. If your build appears in the vulnerable column, you are at risk.

What can I do right now?

The first and most reliable defence is to upgrade to the patched release for your branch. SonicWall has published a security update that closes the authentication gap. Follow the vendor’s upgrade guide, but in short the steps are:

• Back up the current configuration – export the settings from System > Settings > Export Settings or use the CLI command write backup.
• Download the latest SonicOS firmware from the SonicWall support portal. Choose the update that matches the 7.1.1 branch; the portal will label it as the security‑only release.
• Upload the firmware via the web UI (System > Firmware) or push it through the CLI with upgrade followed by the file name.
• Allow the appliance to reboot and verify the new version with the same show version command used earlier.

If you cannot apply the firmware immediately, apply the mitigations that SonicWall recommends:

• Disable SSLVPN temporarily. In the web UI, go to VPN > Settings and turn off the SSLVPN service.
• Restrict access to the VPN endpoint to known IP ranges using an access‑control rule. Create a firewall rule that only permits source addresses belonging to your corporate network or approved remote offices.
• Enforce multi‑factor authentication (MFA) for any remaining VPN users. Even though the flaw bypasses the primary credential check, MFA adds an additional challenge that the current exploit does not satisfy.
• Monitor logs for unusual VPN login activity. Look for successful SSLVPN sessions that originate from IP addresses you do not recognise.

If a patch isn’t available

In the unlikely event that you cannot obtain the patched firmware – perhaps because the device is end‑of‑life or you are locked into a custom image – you must treat the appliance as compromised until it can be replaced or patched.

Take these steps:

• Isolate the appliance from the internet. Move the management interface to a VLAN that is not routable from external networks.
• Turn off the SSLVPN service entirely. This removes the attack surface that the vulnerability exploits.
• Deploy network‑based intrusion‑prevention signatures that detect the known exploit payload. Many commercial IPS/IDS platforms have added rules for this specific attack after CISA’s advisory.
• Increase logging verbosity for VPN events and forward those logs to a SIEM for real‑time alerting.
• Plan for replacement. If the hardware is no longer receiving updates, schedule a migration to a supported platform.

How to apply the fix

Upgrading to the patched release for the 7.1.1 branch is the only permanent solution. The vendor’s release notes describe the fix as a change to the SSLVPN authentication module that restores proper credential verification. Follow the standard upgrade workflow – back up, download, install, verify – and you will be out of the critical risk window.

After the upgrade, run a quick sanity check:

• Log in to the VPN using a test account. Verify that the normal username/password prompt appears and that authentication succeeds only with valid credentials.
• Confirm that the version you see matches a patched build in the table below.
• Check the system log for any error messages related to the SSLVPN service during startup.

When the upgrade is confirmed, re‑enable SSLVPN if you had disabled it, and re‑apply any custom access‑control rules you need. Remember to keep the configuration backup in a safe place – you’ll need it if you ever have to roll back or rebuild the appliance.

Bottom line

CVE-2024-53704 is a critical authentication bypass that lets an unauthorised user walk straight into your internal network via SSLVPN. The vulnerability is already being weaponised in ransomware campaigns, and the CISA directive makes remediation mandatory.

If your SonicWall device is running a version that appears in the vulnerable column of the table below, you must act now. Upgrade to the patched release, or, if that isn’t possible, shut down SSLVPN and harden the perimeter until you can replace the appliance.

Stay on top of vendor advisories, keep firmware up to date, and treat remote‑access services as high‑value targets – that’s the best way to keep the threat at bay.

Affected versions

Straight from the NVD record for CVE-2024-53704. If your build is inside one of these ranges, treat it as vulnerable.

Product	Affected range	Fixed in
sonicos	7.1.1-7040 up to 7.1.1-7058	see vendor advisory