What happened
SonicWall confirmed that in around September 2025 an unauthorised party gained access to its cloud-backup environment (via its MySonicWall portal) and extracted firewall configuration backup files for customers. Dark Reading+3SonicWall+3The Hacker News+3
Here are the key facts:
- The files stolen were backups of firewall configuration data (preferences, rules, VPN definitions, credentials/secrets) for customers who used SonicWall’s cloud-backup service. ACA Group+1
- Initially SonicWall reported fewer than 5% of its customers were affected. The Hacker News+2SonicWall+2 Later, after investigation by Mandiant, SonicWall disclosed that all customers who used the cloud backup service were impacted. Dark Reading
- The attacker is described as a “state-sponsored threat actor” by SonicWall. CyberScoop+1
- The breach vector: The unauthorised access came via an API call to a cloud environment storing the backups. Dark Reading+1
- Importantly: SonicWall states that its products, firmware, source code, production network and other tools were not compromised — the breach was isolated to the cloud backup service. BleepingComputer+1
- The configuration files, while encrypted, still contain enough information (network rules, VPN configs, credentials) to pose a serious risk if that data were decrypted or used by an attacker for reconnaissance. ACA Group
- Following the breach, security firms observed increased attacks on SSL-VPN infrastructure and remote access tied to SonicWall gear — suggesting follow-on exploitation may be underway. eSecurity Planet
So in summary: a cloud backup repository of SonicWall firewall configurations was breached by a likely nation-state actor, exposing sensitive configuration and credential material — although SonicWall claims the core firewall products and networks were not directly compromised.
What SonicWall is doing about it
SonicWall has taken a number of remedial actions and issued guidance. Key items:
- They engaged Mandiant for the investigation and concluded it on October 8, 2025. Arctic Wolf
- They updated their advisory to reflect that all customers of the service (not just 5 %) were impacted. SonicWall+1
- They released a portal “Issue List” in MySonicWall.com which customers can use to check whether their devices are flagged, and categorise them as “Active – High Priority”, “Active – Lower Priority”, or “Inactive”. SonicWall
- They are recommending and facilitating credential resets, key rotations, disabling remote management where feasible, and restricting access to WAN-facing management surfaces. Arctic Wolf+1
- They claim the breach did not impact firewall firmware, devices, or other systems — so they are emphasising the containment. BleepingComputer
- They are enhancing their cloud infrastructure, platform monitoring and network hardening going forward. Dark Reading
From a communications perspective, they are trying to reassure customers that the systems are under control, and give concrete remediation steps. That said, attribution remains vague and root cause details (exact API exploited, how API was secured) seem limited in public disclosure. CyberScoop
What organisations using SonicWall should do
If your organisation uses SonicWall firewalls (especially if you use the MySonicWall cloud backup service) then you need to act now. Here’s a recommended checklist, refined from SonicWall’s guidance and independent analysis:
1. Determine if you’re impacted
- Log into your MySonicWall.com portal, go to Product Management → Issue List, check whether your serial numbers/devices are flagged. SonicWall+1
- Check if you have enabled the cloud backup service (firewall configuration backups). If not, your risk from this specific incident is lower (though you still have general firewall risk).
- Find out whether your device is flagged as “Active – High Priority” (i.e., internet-facing services). These are highest risk. Arctic Wolf
2. Reset credentials / rotate keys
- On affected devices (especially internet-facing ones) reset all local admin and device credentials: firewall admin passwords, VPN pre-shared keys, RADIUS/LDAP bind credentials, SNMP strings, etc. SonicWall+1
- Revoke/rotate any certificates, keys, API tokens associated with firewall configuration or remote access.
- Ensure that any credentials stored in the backup files (even if encrypted) are treated as compromised. Assume worst-case.
3. Restrict and harden remote access and management interfaces
- Disable or restrict WAN / internet-facing management interfaces where possible (HTTP/HTTPS, SSH, SSLVPN portals) until the environment is fully validated. Arctic Wolf
- Enforce multi-factor authentication (MFA) for all admin/remote access accounts.
- Review firewall rules for remote access, VPN endpoints: ensure only required endpoints, use zero-trust principles (least privilege).
- Monitor logs for abnormal access behaviour, especially remote logins using valid credentials (there are signs in the wild this occurred post-breach). eSecurity Planet
4. Review configuration and detect anomalies
- Audit your firewall configuration: VPN tunnels, rules allowing wide access, exposures, legacy credentials. The stolen backup gives adversaries insight into your setup.
- Check for unknown or suspicious entries (e.g., rules created that you don’t recognise, remote sites you don’t remember, unusual routing).
- Monitor network activity for lateral movement, unexpected connections, especially from outside your trusted perimeter.
- Review backup files you hold (if you export your config externally) and verify that your secure key material is still protected or rotated.
5. Update and patch devices
- Ensure your SonicWall devices are running the latest firmware. Although SonicWall says the product firmware was not compromised, device vulnerabilities (unrelated) remain a risk.
- If you still have older generation devices (Gen 5/6), consider the risk: some sources say older devices used weaker encryption for backups, increasing exposure. ACA Group
6. Document and plan incident response
- Treat this as a serious incident: you have to assume adversaries may attempt follow-on attacks using stolen configuration data (network topology, rules, VPN endpoints, etc).
- Engage your incident response team, security operations, logs retention, forensic monitoring.
- Consider vulnerability and penetration testing focused on remote access and firewall attack surfaces.
- Review your vendor relationships and backup strategy: storing sensitive configuration data in cloud backup services can become a systemic risk.
7. Communicate to stakeholders
- Inform your senior leadership, board (if appropriate), and affected teams of the risk.
- Review whether regulatory or contractual obligations require disclosure (depending on your industry, jurisdiction). The law firm commentary suggests significant liability if insufficient response. Passle
- Work with your vendor (SonicWall) or partner to ensure you have all the latest updates and support tools they provide.
Why this matters
This breach is especially significant for a few reasons:
- Firewall configuration data is extremely sensitive: it contains network topologies, access rules, credentials, VPN definitions — information that helps attackers map and exploit your network. Wire+1
- It underscores that even security-vendors (not just their customers) are targets for nation-state actors. The breach vector via cloud backup emphasises that supply-chain / vendor trust is brittle. Cyber Security News
- Many organisations may have treated backup of configurations as low risk. This event demonstrates that such backups must be treated like production secrets.
- The residual risk is not hypothetical: early post-incident reports show increased SSLVPN attacks (valid credentials) on SonicWall gear — suggesting attackers may be using the stolen data for follow-on attacks. eSecurity Planet
Final Thoughts
If you use SonicWall gear and particularly the MySonicWall cloud backup service, you must treat this as urgent. While SonicWall says the core firewall firmware was not compromised, the exposed backups create a heightened risk of targeted attacks. Your priority should be to identify whether you were impacted, rotate credentials, lock down access, audit your firewall setups, and monitor for abnormal behaviour.
On the vendor side, this incident shows that convenience (cloud-based backups) can introduce a single point of failure when secrets are centrally stored. Organisations should review their backup architectures, adopt “zero trust” for admin access, restrict remote management, and ensure that secrets are protected with customer-held keys if possible.