A major SonicWall backup breach is now at the center of a federal lawsuit after Marquis Software Solutions alleged that exposed firewall configuration backups directly enabled a ransomware attack on its network.

Filed in a Texas federal court, the complaint claims that a vulnerability in SonicWall’s MySonicWall cloud backup infrastructure allowed attackers to download sensitive firewall configuration files — including unencrypted MFA scratch codes — without authentication.

For CISOs, security engineers, and enterprise decision-makers, this case highlights a critical reality:

Third-party cloud misconfigurations can undermine even well-secured, MFA-protected networks.

In this in-depth analysis, we examine:

What allegedly went wrong in the SonicWall backup breach
How exposed MFA codes enabled ransomware
The API vulnerability mechanics
Regulatory and compliance implications
Defensive lessons for organizations relying on cloud security providers

Background: Lawsuit Against SonicWall

SonicWall, a well-known firewall and network security vendor, is facing legal action from Marquis Software Solutions.

According to court filings:

August 14, 2025: Marquis suffers ransomware attack.
Investigation finds no unpatched local vulnerabilities.
Root cause traced to MySonicWall cloud backup infrastructure.
Exposed firewall configuration backups allegedly enabled intrusion.

Marquis claims negligence, gross negligence, and unjust enrichment — seeking full reimbursement for damages.

What Happened in the SonicWall Backup Breach?

The API Vulnerability

In February 2025, SonicWall reportedly introduced a code change to its cloud API.

The lawsuit alleges this change:

Allowed firewall backup downloads via predictable serial numbers.
Required no authentication.
Exposed configuration files across customer accounts.

In essence, if attackers guessed or enumerated device serial numbers, they could retrieve backup files.

This represents a classic Insecure Direct Object Reference (IDOR) vulnerability.

MITRE ATT&CK Mapping

T1190 – Exploit Public-Facing Application
T1078 – Valid Accounts
T1556 – Modify Authentication Process

Exposed Data: Why This Was So Dangerous

The firewall configuration backups reportedly contained:

Usernames
Local firewall passwords
SSL certificates
Network architecture details
Unencrypted MFA scratch codes

The Critical Failure: Unencrypted MFA Codes

Multi-Factor Authentication (MFA) is designed to prevent credential abuse.

However, scratch codes — meant as backup authentication factors — were stored unencrypted within the configuration backups.

This allegedly allowed attackers to:

Access backup files.
Extract MFA scratch codes.
Bypass two-factor authentication.
Access protected perimeter devices.

Key Security Insight:
MFA is only as strong as the protection of its recovery mechanisms.

Timeline of Disclosure

According to the lawsuit:

February 2025 – API change introduced.
August 14, 2025 – Marquis ransomware incident.
September 2025 – Suspicious activity reportedly detected.
October 2025 – Alleged admission that all customer backup files were exposed.

Initially, SonicWall allegedly stated only 5% of firewalls were affected. Later disclosures suggested broader exposure.

Delayed breach detection and underestimation of impact are central claims in the case.

How the Ransomware Attack Occurred

Marquis asserts that attackers:

Downloaded its firewall configuration backup.
Extracted unencrypted MFA scratch codes.
Bypassed perimeter MFA protection.
Gained internal network access.
Deployed ransomware.

Despite having:

SonicWall firewalls
MFA enabled
No unpatched local vulnerabilities

The breach allegedly originated from the vendor’s cloud environment.

Business & Legal Impact

Marquis now faces:

30+ consumer class action lawsuits
Commercial trade secret litigation
Lost banking industry contracts
Reputational damage
Incident response and legal costs

This demonstrates the cascading impact of third-party cloud failures.

Compliance & Regulatory Implications

Marquis argues that storing MFA scratch codes unencrypted violates guidance from:

National Institute of Standards and Technology (NIST)
Cybersecurity and Infrastructure Security Agency (CISA)

Relevant Standards

NIST SP 800-63

Recommends secure handling of authentication secrets.

NIST CSF

Emphasizes:

PR.AC – Access Control
DE.CM – Continuous Monitoring
RS.AN – Incident Analysis

CISA Secure-by-Design Principles

Advocate:

Default secure configurations
Strong authentication protection
Cloud infrastructure monitoring

If proven, the case could set precedent around vendor liability in cloud security incidents.

Lessons for CISOs and Security Leaders

1. MFA Alone Is Not Enough

If recovery codes or backup authentication mechanisms are exposed, MFA protections can collapse.

Organizations must:

Encrypt MFA backup codes.
Rotate scratch codes regularly.
Treat them as sensitive credentials.

2. Vendor Risk Management Must Include Cloud Controls

Perform due diligence on:

API security practices
Data encryption standards
Backup storage architecture
Monitoring and detection capabilities

Ask vendors:

Are configuration backups encrypted at rest?
Are API endpoints authenticated and rate-limited?
Is serial number enumeration possible?

3. Monitor Third-Party Cloud Exposure

Implement:

Continuous vendor risk assessments
External attack surface monitoring
Cloud configuration audits
Contractual breach notification clauses

Zero Trust must extend beyond internal infrastructure.

4. Apply the Shared Responsibility Model Carefully

Even if infrastructure is vendor-managed:

You remain accountable for security impact.
Contracts should define liability boundaries.
Incident response plans must include vendor escalation procedures.

Common Security Misconceptions

“Our firewall is secure, so we’re protected.”

If cloud backups expose configuration data, the firewall becomes irrelevant.

“MFA prevents ransomware.”

MFA can be bypassed if backup codes are exposed.

“Cloud vendors handle everything.”

Cloud providers manage infrastructure — not your risk exposure.

Incident Response Recommendations

If your organization uses SonicWall cloud backups:

Rotate firewall passwords immediately.
Regenerate MFA scratch codes.
Review access logs for unusual backup downloads.
Audit API access history.
Validate encryption of stored backups.

Proactive remediation reduces long-term liability.

FAQs

1. What is the SonicWall backup breach?

It refers to an alleged API flaw in SonicWall’s cloud backup system that exposed firewall configuration files.

2. How did attackers bypass MFA?

By extracting unencrypted MFA scratch codes from downloaded configuration backups.

3. What is an IDOR vulnerability?

An Insecure Direct Object Reference allows unauthorized access to resources through predictable identifiers.

4. Can this happen with other vendors?

Yes. Any cloud service with weak API access controls or unencrypted sensitive data could face similar risks.

5. What should organizations do now?

Audit firewall backup security, rotate credentials, and reassess vendor risk management practices.

Conclusion

The SonicWall backup breach lawsuit underscores a critical cybersecurity principle:

Security controls are only as strong as their weakest dependency.

Even with patched systems and MFA enabled, organizations can be compromised if third-party cloud services expose sensitive configuration data.

For CISOs and enterprise leaders, this case reinforces the need to:

Expand Zero Trust to vendor ecosystems
Encrypt authentication recovery mechanisms
Continuously monitor cloud API exposure
Strengthen contractual security accountability

As legal scrutiny intensifies around cloud vendor security, this case may redefine expectations for secure-by-design infrastructure.