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

Introduction

A critical flaw in Sentry's SAML SSO implementation let an attacker who controls a malicious Identity Provider hijack arbitrary user accounts on multi-organization self-hosted instances. The attacker only needed to know the victim's email address. The vulnerability has a CVSS score of 9.1 and a straightforward exploitation path, so it is 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 used across the software industry for real-time issue detection, tracing, and diagnostics. Because so many teams run it, either as a SaaS product or as a self-hosted install, a flaw in its authentication layer carries particular weight.

Technical Information

Root Cause: Misplaced Trust in IdP Assertions During SSO Setup

The vulnerability, classified under CWE-290 (Authentication Bypass by Spoofing), is in Sentry's SAML SSO provider setup pipeline. During SSO configuration, Sentry used the email address asserted by the Identity Provider to decide which user account to link the new SSO identity to. It should have used the authenticated session of the administrator performing the setup.

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 read the email field from this identity dictionary to look up the Sentry user account to associate with the new AuthIdentity. The email came straight from the IdP assertion and was never checked against the authenticated session, so Sentry would happily link the SSO identity to whichever account matched that email, no matter who was performing the setup.

Attack Flow

The attack works like this:

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 asserts the victim's email address in its SAML response during the SSO setup flow.
3. When the attacker starts 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 runs over the network, has low complexity, and needs no interaction from the victim. The attacker needs only two things: access to configure SSO on another organization in the same instance, and the victim's email address.

Impact

Successful exploitation is a complete account takeover. The attacker gets the victim's full permissions, including access to all projects, error data, performance monitoring data, and any administrative capabilities the victim holds. Confidentiality and integrity impact are both high.

Patch Information

The vulnerability was patched in 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 small and clean. Instead of trusting the IdP-asserted email, the patched code overwrites the email in the identity dictionary with the email of the user authenticated in 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)

The new setup_identity dictionary spreads the original identity and explicitly replaces the "email" key with request.user.email. As a result, resolve_email_to_user always resolves to the admin who is performing the SSO configuration. That is the correct trust boundary. During setup, the authoritative identity comes from the session-authenticated admin rather than from the IdP assertion.

The commit also adds tests to tests/sentry/auth/test_helper.py in a new SetupPipelineIdentityLinkingTest class (89 lines of additions). Three 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. The IdP asserts the same email as the admin, and normal operation is unaffected.
3. test_setup_links_to_admin_when_email_matches_no_user: When the IdP returns an email that matches no user (e.g., [email protected]), the identity is still pinned to the authenticated admin.

In total, the commit modifies 2 files, with 94 additions (mostly tests) and 1 deletion in production code.

Affected Systems and Versions

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

Whether a deployment is vulnerable depends on its configuration:

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

Vendor Security History

Sentry handled CVE-2026-42354 quickly and responsibly. A researcher known as @jaydns reported the vulnerability through Sentry's private bug bounty program. After verifying the report, Sentry promptly credited the reporter, merged the fix, and released the patched version. It also deployed the fix to its SaaS environment before disclosing the vulnerability publicly, which limited the window of exposure for the majority of its user base.

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