Synology’s Hidden Backdoor: How CVE-2025-4679 Exposed Microsoft 365 Data Across Tenants

In a stark reminder of how third-party integrations can silently erode cloud security, a critical vulnerability—CVE-2025-4679—was discovered in Synology’s Active Backup for Microsoft 365 (ABM). This flaw exposed sensitive organizational data across every Microsoft 365 tenant using the product, without requiring compromise of the target tenant itself.

The breach wasn't the result of a sophisticated exploit chain or zero-day vulnerability in Microsoft 365. Instead, it stemmed from a quiet failure in OAuth implementation—one of the foundational protocols for cloud-based identity and access control. The simplicity of the mistake belies its massive blast radius.

The Vulnerability, Explained

Synology ABM allows IT teams to back up cloud data—including emails, Teams chats, SharePoint content, and calendars—from Microsoft 365 accounts to local NAS devices. Like many services, ABM integrates using OAuth, leveraging Microsoft’s identity platform to request delegated permissions on behalf of the administrator.

To simplify onboarding, Synology implemented a centralized, global Azure AD app. During the OAuth setup, Synology’s synooauth.synology.com middleware handles the authentication and authorization flow. However, in this flow, a client_secret—essentially a master password for the Synology OAuth app—was leaked via an HTTP 302 redirect response.

Any network actor intercepting this redirect could extract the secret and reuse it to impersonate Synology’s application. Since this app was authorized in multiple customer tenants, a single captured secret unlocked access to all of them.

The app was granted wide permissions: Microsoft Graph access to messages, calendar events, group metadata, and files. And due to the design of Synology’s architecture, the same client_id and client_secret pair were reused globally. There was no tenant isolation, no app scoping, and no rotation strategy.

This is akin to every customer sharing the same admin key—one that briefly appeared in plaintext during the setup process.

The Risks Behind the Curtain

The implications of CVE-2025-4679 are broad and unsettling.

Any malicious actor monitoring ABM OAuth flows could extract the secret and quietly begin harvesting data. Because the access happened via Microsoft Graph using Synology’s registered application, it wouldn’t necessarily trigger typical security alerts—especially if admins had authorized the app themselves.

There was no tenant-specific validation. This meant an attacker with the client_secret could retrieve data from any tenant that had previously authorized the Synology ABM app—without needing to compromise the customer’s network, credentials, or systems.

This vulnerability essentially turned Synology’s ABM into a global backdoor.

The Anatomy of an Exploitation Scenario

Imagine an attacker sets up a rogue Wi-Fi hotspot at a security conference where an IT admin happens to initiate an ABM configuration. The OAuth flow is redirected through the attacker's network. A simple packet capture reveals the client_secret.

With that, the attacker constructs access tokens using Microsoft’s OAuth token endpoint. Since Synology’s app is already authorized in dozens—or hundreds—of tenants, the attacker doesn’t need phishing, malware, or brute force. They simply walk in the front door.

They can now read Teams messages from a law firm’s internal channels. View HR calendars at a hospital. Download board communications from a global NGO. All without triggering MFA prompts, login anomalies, or user alerts.

Why This Happened

The core issue lies in Synology’s choice to use a single, globally deployed multi-tenant application with a shared secret. While this approach simplifies onboarding and support, it massively increases risk if the secret is ever exposed—which it was.

OAuth 2.0, while powerful, assumes secrets are kept confidential. Leaking them—even momentarily—renders all trust assumptions invalid. Unfortunately, Synology failed to follow best practices:

The client_secret was embedded in a location header during a redirect, exposing it to logs, network observers, and even browser history. The app was global, so compromise affected all tenants. No automated rotation or secret lifecycle management was in place.

Furthermore, Synology initially downplayed the issue, rating it a medium severity (CVSS 6.5), while independent security researchers from ModZero assessed it at 8.6, citing its ease of exploitation and global scope.

What Should Be Done

Remediation starts with Synology rotating the leaked client_secret and rearchitecting their authentication flow. But for end-users, it’s not that simple.

Every organization that has used ABM must assume the possibility of data exposure. They should audit any access by Synology’s application in Azure AD, check Graph API logs for unusual reads, and consider revoking access entirely until scoped apps or tenant-specific credentials are available.

This incident reinforces a crucial lesson: convenience in cloud integration should never come at the expense of isolation, auditability, and least privilege.

Vendors offering centralized services must ensure their integrations are tenant-scoped and secrets are ephemeral—not static. And customers must demand transparency from their providers, particularly around permission scoping and identity federation.

Real-World Implications

There are no confirmed incidents yet tying CVE-2025-4679 to active breaches, but the potential is chilling.

Corporate espionage campaigns could target strategic partners via ABM access. Ransomware operators could silently harvest communications and use them to tailor social engineering pretexts. Competitors might scrape insights from executive calendar data or project communications.

This is not a theoretical weakness. It is a real, architectural flaw that created a system-wide vulnerability across an entire backup product’s customer base.

Conclusion

CVE-2025-4679 is a case study in the dangers of abstraction and scale in cloud integrations. A single misstep in OAuth flow design, compounded by shared credentials, opened the door to cross-tenant data exposure with global consequences.

Organizations entrusting third-party tools with access to Microsoft 365 must now reevaluate their posture. Every external integration becomes part of your trust boundary—and as Synology’s case shows, one weak link in that chain can compromise the entire system.