Sentry SAML SSO Account Takeover via Identity Spoofing: Brief Summary of CVE-2026-42354

Introduction

A critical flaw in Sentry's SAML SSO implementation allowed an attacker with control over a malicious Identity Provider to hijack arbitrary user accounts on multi-organization self-hosted instances, requiring nothing more than knowledge of the victim's email address. With a CVSS score of 9.1 and a straightforward exploitation path, this vulnerability represents a serious risk for any organization running Sentry in a multi-tenant self-hosted configuration.

Sentry is a developer-first, open source error tracking and application performance monitoring platform built by Functional Software Inc. It is widely adopted across the software industry for real-time issue detection, tracing, and diagnostics. Its broad deployment as both a SaaS product and a self-hosted solution makes vulnerabilities in its authentication layer particularly consequential.

Technical Information

Root Cause: Misplaced Trust in IdP Assertions During SSO Setup

The vulnerability, classified under CWE-290 (Authentication Bypass by Spoofing), resides in Sentry's SAML SSO provider setup pipeline. The core problem is deceptively simple: during SSO configuration, Sentry trusted the email address asserted by the Identity Provider to determine which user account to link the new SSO identity to, rather than relying on the already authenticated session of the administrator performing the setup.

Specifically, the _finish_setup_pipeline method in src/sentry/auth/helper.py passed the identity dictionary (which contained the IdP-asserted email) directly into the identity linking logic:

# Vulnerable code path:
self.auth_handler(identity).handle_attach_identity(om)

The downstream function resolve_email_to_user consumed the email field from this identity dict to look up the Sentry user account to associate with the new AuthIdentity. Because the email came directly from the IdP assertion without any validation against the authenticated session, the system would happily link the SSO identity to whichever account matched that email, regardless of who was actually performing the setup.

Attack Flow

The exploitation path proceeds as follows:

1. The attacker creates or controls an organization on a multi-organization self-hosted Sentry instance (where SENTRY_SINGLE_ORGANIZATION is set to False).
2. The attacker configures a malicious SAML Identity Provider for their organization. This IdP is set up to assert the victim's email address in its SAML response during the SSO setup flow.
3. When the attacker initiates the SSO provider setup for their organization, Sentry processes the SAML assertion and extracts the identity dictionary, which now contains the victim's email.
4. The resolve_email_to_user function resolves this email to the victim's Sentry user account.
5. Sentry creates an AuthIdentity record linking the attacker's SSO identity to the victim's account.
6. The attacker can now authenticate as the victim through the malicious IdP.

The attack vector is network-based, requires low complexity, and demands no user interaction from the victim. The only prerequisites are: access to configure SSO on another organization within the same instance, and knowledge of the victim's email address.

Impact

Successful exploitation results in complete account takeover. The attacker gains the victim's full permissions, including access to all projects, error data, performance monitoring data, and any administrative capabilities the victim holds. This translates to high confidentiality and high integrity impact.

Patch Information

The vulnerability was patched via Pull Request #113720, authored by michelletran-sentry and merged on April 22, 2026. The fix shipped in Sentry release 26.4.1 and was also deployed to Sentry's SaaS platform around the same date. The associated commit is 0c67558.

The fix is surgical and elegant. Instead of blindly trusting the IdP-asserted email, the patched code overrides the email in the identity dictionary with the email of the currently authenticated user from the HTTP session:

# Before (vulnerable):
self.auth_handler(identity).handle_attach_identity(om)

# After (patched):
# The setup flow should always link the identity to the admin who is
# performing setup, so override the email to ensure resolve_email_to_user
# returns the authenticated user rather than whoever the IdP asserted.
setup_identity = {**identity, "email": request.user.email}
self.auth_handler(setup_identity).handle_attach_identity(om)

By constructing a new setup_identity dictionary that spreads the original identity but explicitly replaces the "email" key with request.user.email, the patch ensures that resolve_email_to_user always resolves to the admin who is actively performing the SSO configuration. This is the correct trust boundary: during setup, the session-authenticated admin is the authoritative identity, not the IdP assertion.

The commit also includes a comprehensive test suite added to tests/sentry/auth/test_helper.py in a new SetupPipelineIdentityLinkingTest class (89 lines of additions). Three distinct test scenarios validate the fix:

1. test_setup_links_to_admin_when_assertion_email_differs: When the IdP asserts an email belonging to a different organization member (e.g., [email protected]), the resulting AuthIdentity is still linked to the admin ([email protected]) and no identity is created for the other user.
2. test_setup_links_to_admin_when_emails_match: The happy path scenario where the IdP asserts the same email as the admin, confirming normal operation is unaffected.
3. test_setup_links_to_admin_when_email_matches_no_user: When the IdP returns a completely unknown email (e.g., [email protected]), the identity is still correctly pinned to the authenticated admin.

The total change footprint is minimal: 2 files modified, 94 additions (mostly tests), and just 1 deletion in production code. This reflects a well-scoped, targeted fix.

Affected Systems and Versions

The vulnerability affects Sentry versions from 21.12.0 up to (but not including) 26.4.1.

The following configurations determine whether a deployment is vulnerable:

Only self-hosted multi-organization instances are actively exposed. The vulnerability requires the instance to host more than one organization, and the attacker must have permissions to configure SSO settings on one of those organizations.

Vendor Security History

Sentry demonstrated a mature and responsive approach to handling CVE-2026-42354. The vulnerability was identified through Sentry's private bug bounty program by a researcher known as @jaydns. Upon verification, the vendor promptly credited the reporter, merged the fix, and released the patched version. Sentry also proactively deployed the fix to their SaaS environment before publicly disclosing the vulnerability, limiting the window of exposure for the majority of their user base. This responsible disclosure and rapid remediation cycle reflects well on their security operations.

References

• NVD: CVE-2026-42354
• CVE Record: CVE-2026-42354
• Sentry Security Advisory: GHSA-rcmw-7mc7-3rj7
• GitHub Advisory Database: GHSA-rcmw-7mc7-3rj7
• Pull Request #113720: Pin SSO setup identity link to authenticated session
• Commit 0c67558: Fix for CVE-2026-42354
• Sentry Release 26.4.1
• Endor Labs: CVE-2026-42354 Analysis