SonicWall disclosed on September 17, 2025, that attackers broke into its MySonicWall cloud backup service and made off with exported firewall configuration files. The company terminated the unauthorized access, but the stolen files—which can contain credentials, VPN keys, and internal network maps—are now in adversary hands. SonicWall is urging affected customers to immediately rotate every potentially exposed secret and hunt for signs of intrusion.
What we know about the breach
The incident involves the cloud backup feature inside SonicWall’s MySonicWall management portal. Administrators who enabled the service had their firewall “preference” files (full device configurations) exported and stored in their MySonicWall accounts. SonicWall’s advisory says that “unauthorized access” to certain accounts allowed threat actors to read those backup files. The vendor has not disclosed how the access occurred—whether through stolen credentials, an application vulnerability, or a misconfiguration—nor how many accounts were affected.
What is clear: once inside, the attackers could pull complete snapshots of a firewall’s setup. SonicWall says it ended the unauthorized access and is working with law enforcement and cybersecurity authorities worldwide. But the company also acknowledges that the configuration files “are now in the hands of the attackers.”
What a leaked configuration file contains
A SonicWall preference file isn’t a simple settings list. It contains a detailed blueprint of the firewall’s role in the network. Depending on the device model and export options, a single backup file can include:
- Local administrator usernames and sometimes password hashes
- VPN configurations and pre-shared keys for IPSec and SSL VPNs
- Certificate objects and, in some cases, private key artifacts
- RADIUS and LDAP server URLs, along with the accounts used to authenticate against them
- Static routes, NAT rules, and network object inventories that expose internal IP addressing
- API keys or automation tokens stored inside configuration objects
- SNMP community strings and monitoring access details
A file that comprehensive gives an attacker both the authentication material and the reconnaissance needed to mount targeted intrusions with minimal effort. Stolen admin credentials or VPN pre-shared keys allow direct remote access. Internal IP maps and firewall rules tell an adversary exactly what to hit after they get inside.
Who needs to act—and who doesn’t
Not every SonicWall customer is affected. The breach is limited to devices that had the cloud backup feature enabled inside MySonicWall. If you never turned on cloud backups, your configuration files were never stored in the cloud, and this incident does not pose a direct risk to you. However, SonicWall still recommends logging into MySonicWall to verify your backup status and confirm that no devices are flagged.
For everyone else—those who used the cloud backup feature—the risk is immediate. SonicWall has begun flagging affected serial numbers inside customer accounts. After you log in to MySonicWall, look for a banner indicating that a device’s backup files were exposed. Treat any flagged appliance as compromised and follow the full remediation steps below. Even if no banner appears but you had cloud backups turned on, the safest approach is to assume exposure until SonicWall releases a tool or list to confirm which accounts were actually accessed.
Your immediate response plan
SonicWall published a remediation guide alongside its advisory. The steps below pull from that guidance and standard incident response best practices. They are ordered by urgency and impact.
-
Verify cloud backup usage and check for flags
Log into MySonicWall. If the cloud backup column shows “Enabled” for any serial number, that device may be affected. Any serial number that SonicWall knows was impacted will now display an informational banner. Even if you don’t see a banner, proceed as if the device is at risk if you have ever used cloud backups. -
Isolate affected appliances (where feasible)
Move flagged or suspected devices to a dedicated management VLAN or restrict access to their administration interface so that only trusted internal hosts can reach them. This limits opportunities for an attacker to use stolen credentials before you finish rotating secrets. -
Rotate all credentials that could appear in a backup
This is the most critical step and must be done immediately. Change every local administrator password, VPN pre-shared key, RADIUS/LDAP service account password, and any API token or automation secret that the firewall ever touched. Do not reuse old passwords, and ensure the new values are strong and unique. Re-push VPN client profiles to all users after rotating the keys. -
Revoke and reissue certificates
If your backup included private keys or certificate artifacts—which depends on how the export was configured—generate new key pairs and replace all certificates used for SSL VPN, SSH, or other services. Treat any PKI material that lived on the device as potentially exposed. -
Apply SonicWall’s remediation preference file
SonicWall has released a technical playbook, including an option to import a new preference file that resets known exposed items. Follow the vendor’s own instructions first. If you cannot use the import method, the same documentation lists manual remediation steps for every credential type. -
Hunt for follow-on activity
Search your firewall management logs, VPN logs, and authentication systems for anomalies: new administrator accounts, configuration imports from unknown IP addresses, successful VPN connections after multiple failures, or unusual RADIUS/LDAP bursts. On endpoints, look for lateral movement patterns that might indicate an attacker used stolen credentials to pivot inside your network. -
Patch and harden
While tackling the exposure, make sure every SonicWall appliance is running the latest recommended SonicOS release. If you had deferred updates, prioritize patching now—known vulnerabilities in older firmware compound the risk. -
Engage incident response and consider regulatory obligations
If you find signs of unauthorized access, bring in your incident response provider and contact law enforcement. Depending on your industry and jurisdiction, you may need to notify regulators or customers about a data breach. SonicWall states it is cooperating with authorities, and customers should do the same.
What to watch for as the investigation unfolds
SonicWall’s notice was fast but left gaps that will matter to response teams. The company has not yet explained how the breach occurred, how many accounts were affected, or whether private cryptographic material was definitively exfiltrated. Those details will shape the final risk assessment. For now, the prudent course is to assume the worst—that any secret in any cloud backup is known to the attacker.
The vendor plans to release additional instructions “in the coming days” to help customers determine whether their particular backup files were impacted. Watch for that update and a more detailed root-cause report. In the meantime, the actions above will drastically reduce the attack value of any stolen config.
Beyond this incident, the MySonicWall breach should prompt every organization to reexamine how they handle cloud backups of security device configurations. Storing a full firewall config in a cloud portal is convenient, but it creates a single point of failure. If you continue to use the feature after remediation, consider enabling client-side encryption so that the vendor never holds usable plaintext. And always enforce multifactor authentication on every account that can access such sensitive data.
SonicWall’s quick disclosure and detailed playbook are appropriate first steps, but the burden is now on customers to move fast. A stolen configuration file is not just a theoretical risk—it is a ready-made attack kit. Containment and credential rotation are the only ways to shut down the threat before it becomes a full-blown intrusion.