Cybersecurity in the Cloud: Lessons from a SaaS Breach

When organisations move to SaaS, they often assume security is “handled by the provider”. The 2025 breach of Commvault’s Metallic SaaS platform is a reminder that responsibility is shared, not outsourced.

In early 2025, Microsoft notified Commvault of suspicious activity in its Azure environment. Subsequent investigations and advisories from Commvault and CISA describe how a state-linked threat actor exploited a zero-day in Commvault’s web server (CVE-2025-3928) and abused stored application secrets to gain access to customers’ Microsoft 365 environments.

Although Commvault has patched the vulnerability and worked with affected customers, the incident offers valuable lessons for any organisation relying on SaaS for backup, collaboration or line-of-business workloads.

What happened in the Commvault SaaS breach

Publicly available information paints the following high-level picture:

• Attackers targeted Commvault’s Azure-hosted Metallic SaaS environment.
• They exploited a previously unknown vulnerability, later tracked as CVE-2025-3928, in the web server component.
• This allowed them, once authenticated, to upload and execute web shells, gaining persistent access to the environment.
• The attackers accessed client secrets and credentials Commvault stored to connect to customers’ Microsoft 365 tenants.
• Using those secrets, they could impersonate service principals and potentially access customers’ M365 data.
• CISA added CVE-2025-3928 to the KEV catalog and issued detailed mitigation guidance for Commvault customers and other SaaS users.

While the number of affected customers appears limited, the scenario touches three recurring cloud security themes: misconfigurations and defaults, identity abuse and third-party risk.

Lesson 1: SaaS does not eliminate the need for basic cloud hygiene

ENISA’s long-standing guidance on cloud computing emphasises that economies of scale make cloud both more secure and more attractive for attackers. In the Commvault case:

• A single web server vulnerability had potential impact across many tenants.
• Default or over-privileged configurations for service principals and secrets amplified the blast radius.
• Monitoring gaps at customer side could have made detection of follow-on activity harder.

For cloud and SaaS security teams, that means:

• Treating SaaS platforms that hold credentials or backups as Tier 0 assets, subject to stricter due diligence.
• Reviewing shared responsibility models and asking explicitly which controls the provider implements and which are still your responsibility.
• Ensuring that your own cloud and identity monitoring covers activity initiated by third-party apps and service principals.

Lesson 2: Identity and secrets are the real crown jewels

The core pivot in the Commvault incident was not just web shell deployment, but access to stored secrets. CISA’s advisory stresses that attackers may have obtained client secrets used to authenticate into M365 environments and that organisations should review service principals and Entra logs for misuse.

Practical actions include:

• Minimise long-lived secrets. Where possible, use certificate-based authentication with strong key management rather than static client secrets.
• Apply least privilege to service principals. Avoid granting tenant-wide permissions if an integration only needs access to a narrow set of mailboxes or resources.
• Monitor non-interactive sign-ins. Include service principal logins, consent grants and application role assignments in your SIEM dashboards.
• Rotate secrets and certificates regularly. Build processes to rotate credentials for third-party integrations on a defined schedule, not just after incidents.

DACTA Global’s identity-focused assessments increasingly treat third-party application permissions as first-class risk items, on par with privileged human accounts.

Lesson 3: Third-party risk is now operational risk

Recent analyses of major breaches in 2024–2025 show that third-party and supply chain exposures are central to many large incidents, particularly in cloud and SaaS environments. The Commvault breach fits this pattern:

• Customers may have had sound internal controls but were still exposed through a trusted provider.
• For some, Commvault was the last line of defence for backup and recovery, turning a provider incident into a business continuity concern.

Strengthening third-party SaaS risk management means:

• Maintaining an up-to-date inventory of critical SaaS providers, the data they hold and the permissions they are granted.
• Requiring providers to notify you of security incidents and KEV-listed vulnerabilities in their stack within defined SLAs.
• Evaluating providers on their own cloud security practices, including segmentation of tenant data, identity management and secret handling.
• Incorporating SaaS providers into your incident response playbooks, including communication, log requests and joint forensic procedures.

Lesson 4: Misconfigurations are as dangerous as zero-days

While CVE-2025-3928 was a zero-day at the time of exploitation, advisories and independent analyses highlight that misconfigurations and over-privileged defaults played a key role in the broader campaign. That aligns with broader research showing that cloud misconfigurations remain a leading cause of SaaS security incidents.

Controls to reduce this risk include:

• Enforcing conditional access and IP restrictions for administrative interfaces wherever possible.
• Reviewing default app registration settings in Entra or equivalent identity platforms, ensuring that only authorised admins can consent to high-privilege apps.
• Using CSPM or SaaS security posture management (SSPM) tools to continuously scan for misconfigurations in key SaaS platforms.
• Validating that logs from SaaS platforms are ingested into your SIEM in a timely and structured way.

Lesson 5: Use the incident as a blueprint for readiness

Even if you are not a Commvault customer, the incident provides a ready-made tabletop exercise scenario. A simple exercise could cover:

• How would we know if a third-party SaaS provider we rely on had been breached?
• What logs and telemetry do we have to detect misuse of service principals or OAuth apps in our tenants?
• How quickly could we rotate secrets, revoke consents and validate the integrity of backups?
• Do our contracts and SLAs give us timely access to incident details and forensic artifacts from providers?

DACTA Global often runs such exercises with clients as part of Cyber Resilience and Incident Response Readiness engagements, using real-world breaches as templates to stress-test processes.

Moving forward: from trust to verification

The Commvault SaaS breach is unlikely to be the last incident where attackers weaponise a mix of zero-day flaws, misconfigurations and over-privileged integrations. For CISOs and cloud leaders, the most important mindset shift is from implicit trust in providers to continuous verification:

• Assume that any SaaS platform holding sensitive data or credentials can be targeted.
• Architect identity, logging and backup strategies so that a provider breach does not automatically become a catastrophic event for your organisation.

Organisations that invest now in visibility, least privilege and third-party risk management will be better positioned to use SaaS as an enabler, rather than a hidden source of systemic risk.