CVE-2025-22146

Executive Summary

A critical vulnerability (CVE-2025-22146) has been discovered in Sentry, a developer-first error tracking and performance monitoring tool. The flaw resides in the SAML SSO implementation, allowing an attacker with a malicious SAML Identity Provider (IdP) and knowledge of a victim's email address to take over any user account on the same Sentry instance. The vulnerability is particularly dangerous in multi-tenant environments where multiple organizations share a single Sentry instance. The CVSS score is 9.1 (Critical), and while no public exploit code or PoC is currently available, the technical details suggest a high likelihood of weaponization. The Sentry SaaS fix was deployed on January 14, 2025, and self-hosted users must upgrade to version 25.1.0 or higher.

Supply Chain & Package Security

Sentry is distributed as a Python package (sentry) via PyPI and as a Docker image. Organizations using Sentry as a dependency in their software supply chain should immediately verify their deployed version and upgrade to 25.1.0 or later. The vulnerability does not affect the core library itself but the SAML SSO authentication flow, which is a critical component for identity federation. Ensure that any CI/CD pipelines or automated deployments that pull Sentry images are updated to the patched version.

CVSS Breakdown & Threat Level

• CVSS Vector: CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H
• Base Score: 9.1 (Critical)
• Attack Vector: Network (AV:N) – The vulnerability can be exploited remotely.
• Attack Complexity: Low (AC:L) – No special conditions or complex steps are required.
• Privileges Required: None (PR:N) – The attacker does not need any prior authentication.
• User Interaction: None (UI:N) – No victim action is needed.
• Scope: Unchanged (S:U) – The vulnerable component and the impacted component are the same.
• Confidentiality Impact: High (C:H) – Full account takeover leads to exposure of sensitive data.
• Integrity Impact: High (I:H) – Attacker can modify data and settings.
• Availability Impact: High (A:H) – Attacker can lock out legitimate users or disrupt service.

Threat Level: Critical. The combination of low attack complexity, no required privileges, and high impact makes this vulnerability extremely dangerous. The only mitigating factor is the requirement for the attacker to know the victim's email address and have control over a malicious SAML IdP.

Deep Dive & Mechanics

The vulnerability lies in the SAML SSO authentication flow within Sentry. When a user authenticates via SAML, Sentry trusts the SAML assertion provided by the Identity Provider (IdP). The flaw allows an attacker who controls a malicious SAML IdP to craft a SAML assertion that impersonates any user on the same Sentry instance, provided the attacker knows the victim's email address.

Technical Breakdown:

1. SAML Assertion Handling: Sentry's SAML implementation does not properly validate the Subject and NameID fields in the SAML assertion against the expected user's identity. Instead, it trusts the email address provided in the assertion without verifying that the assertion was actually issued for that user.

2. Multi-Tenant Context: In a Sentry instance with multiple organizations, each organization can configure its own SAML IdP. An attacker can set up a malicious IdP for their own organization and then craft a SAML assertion that claims to be a user from another organization (e.g., victim@example.com). Sentry's authentication logic does not cross-check the organization association, allowing the attacker to log in as the victim.

3. Exploitation Steps:

   • The attacker registers a new organization on the target Sentry instance (if allowed).
   • The attacker configures a malicious SAML IdP for their organization.
   • The attacker initiates a SAML login flow and intercepts the SAML request.
   • The attacker crafts a SAML response with the victim's email address as the NameID.
   • Sentry processes the assertion and logs the attacker in as the victim.

Root Cause: Insufficient validation of the SAML assertion's subject identity and lack of organization-scoped user verification during the SAML authentication process.

Vulnerable vs. Patched Code

The exact code changes are not publicly available, but based on the advisory, the patch likely involves:

• Vulnerable Code (Conceptual):

  # In SAML authentication handler
  def handle_saml_response(saml_response):
      # Extract user email from SAML assertion
      email = saml_response.get_attribute('email')
      # Look up user by email without verifying organization
      user = User.objects.get(email=email)
      # Log in as that user
      login(request, user)
  

• Patched Code (Conceptual):

  def handle_saml_response(saml_response, organization):
      # Extract user email from SAML assertion
      email = saml_response.get_attribute('email')
      # Verify that the user belongs to the same organization as the SAML IdP
      user = User.objects.get(email=email, organization=organization)
      # Additional validation: ensure the SAML assertion was issued for this specific user
      if not validate_saml_subject(saml_response, user):
          raise AuthenticationError("SAML subject mismatch")
      login(request, user)
  

The patch adds organization-scoped user lookup and validates the SAML subject against the expected user.

Exploitation & Lab Setup

Red Team (Attacker)

Prerequisites:

• Access to a Sentry instance (self-hosted or SaaS) that allows multiple organizations.
• Ability to create a new organization and configure a SAML IdP.
• Knowledge of the victim's email address.

Lab Setup:

1. Deploy a vulnerable Sentry instance (version < 25.1.0) using Docker:

   docker run -d --name sentry -p 9000:9000 sentry:24.12.0
   

2. Create two organizations: attacker-org and victim-org.
3. Configure a malicious SAML IdP (e.g., using SimpleSAMLphp or a custom script) for attacker-org.
4. Create a victim user in victim-org with email victim@example.com.

Exploitation Steps:

1. Initiate SAML login for attacker-org.
2. Intercept the SAML authentication request.
3. Craft a malicious SAML response with the following modifications:
   • Set NameID to victim@example.com.
   • Set Subject to victim@example.com.
   • Sign the assertion with the attacker's IdP private key.
4. Submit the crafted SAML response to Sentry's ACS (Assertion Consumer Service) URL.
5. Sentry processes the assertion and logs the attacker in as victim@example.com.

Example SAML Response (Conceptual):

<samlp:Response xmlns:samlp="urn:oasis:names:tc:SAML:2.0:protocol" ID="response123" Version="2.0" IssueInstant="2025-01-20T12:00:00Z">
  <saml:Assertion xmlns:saml="urn:oasis:names:tc:SAML:2.0:assertion" ID="assertion456" IssueInstant="2025-01-20T12:00:00Z">
    <saml:Subject>
      <saml:NameID Format="urn:oasis:names:tc:SAML:1.1:nameid-format:emailAddress">victim@example.com</saml:NameID>
      <saml:SubjectConfirmation Method="urn:oasis:names:tc:SAML:2.0:cm:bearer">
        <saml:SubjectConfirmationData NotOnOrAfter="2025-01-20T12:05:00Z" Recipient="https://sentry.example.com/saml/acs/"/>
      </saml:SubjectConfirmation>
    </saml:Subject>
    <saml:AttributeStatement>
      <saml:Attribute Name="email">
        <saml:AttributeValue>victim@example.com</saml:AttributeValue>
      </saml:Attribute>
    </saml:AttributeStatement>
  </saml:Assertion>
</samlp:Response>

Blue Team (Defender)

Detection Steps:

1. Monitor SAML authentication logs for anomalies:
   • Multiple successful SAML logins from different organizations using the same email address.
   • SAML assertions where the NameID does not match the expected user's email in the organization.
2. Enable detailed logging for SAML authentication in Sentry:

   # In sentry.conf.py
   SENTRY_OPTIONS['saml.debug'] = True
   

3. Review IdP configurations for unauthorized or suspicious SAML IdPs.
4. Implement network segmentation to restrict SAML IdP access.

Hunting Queries:

• Search for SAML authentication events where the NameID email does not belong to the organization's user list.
• Look for rapid succession of SAML logins from different IPs using the same email.

Indicators of Compromise (IOCs)

• Network IOCs:
  • Unusual SAML authentication requests to the ACS endpoint from IPs not associated with the legitimate IdP.
  • SAML responses with mismatched NameID and Subject fields.
• Log IOCs:
  • Sentry audit logs showing SAML login for a user from an organization different from the IdP's configured organization.
  • Multiple failed SAML authentication attempts followed by a successful login.
• File IOCs:
  • Modified SAML configuration files in /etc/sentry/ or Sentry's database.
• Behavioral IOCs:
  • User accounts exhibiting unusual activity (e.g., accessing projects they don't normally access).
  • New API keys or tokens created by the compromised account.

Detection Engineering

YARA Rule

rule CVE_2025_22146_SAML_Account_Takeover {
    meta:
        description = "Detects SAML responses with potential account takeover indicators"
        author = "Valters IT"
        date = "2025-01-20"
        reference = "CVE-2025-22146"
    strings:
        $saml_response = "<samlp:Response"
        $nameid = "<saml:NameID"
        $email_format = "nameid-format:emailAddress"
        $subject_conf = "<saml:SubjectConfirmation"
    condition:
        $saml_response and $nameid and $email_format and $subject_conf
}

Sigma Rule

title: Suspicious SAML Authentication - Potential Account Takeover
id: 7a8b9c0d-1e2f-3a4b-5c6d-7e8f9a0b1c2d
status: experimental
description: Detects SAML authentication events where the NameID email does not match the expected user for the organization
author: Valters IT
date: 2025-01-20
logsource:
    product: sentry
    service: auth
detection:
    selection:
        EventID: 'saml.login'
        NameID|re: '^[a-zA-Z0-9._%+-]+@[a-zA-Z0-9.-]+\.[a-zA-Z]{2,}$'
    filter:
        Organization|contains: 'expected_org'
    condition: selection and not filter
falsepositives:
    - Legitimate SAML IdP misconfiguration
level: high

Suricata Rule

alert http $HOME_NET any -> $EXTERNAL_NET any (msg:"CVE-2025-22146 - Suspicious SAML Response with Mismatched NameID"; flow:to_server,established; content:"<samlp:Response"; nocase; content:"<saml:NameID"; nocase; content:"nameid-format:emailAddress"; nocase; pcre:"/<saml:NameID[^>]*>[^<]+@[^<]+<\/saml:NameID>/i"; sid:1000001; rev:1;)

Remediation & Mitigation

Immediate Actions:

1. Upgrade Sentry: For self-hosted instances, upgrade to version 25.1.0 or higher immediately.

   docker pull sentry:25.1.0
   docker-compose up -d
   

2. Restrict Organization Creation: If multi-tenancy is not required, set SENTRY_SINGLE_ORGANIZATION = True in the Sentry configuration to prevent new organizations from being created.
3. Audit SAML IdPs: Review all configured SAML Identity Providers and remove any that are unauthorized or suspicious.

Long-Term Mitigations:

1. Implement SAML Assertion Validation: Ensure that the SAML assertion's Subject and NameID are validated against the user's identity in the organization.
2. Enable Multi-Factor Authentication (MFA): Require MFA for all SAML-authenticated users to add an extra layer of security.
3. Monitor SAML Logs: Set up alerts for anomalous SAML authentication events.
4. Network Segmentation: Restrict SAML IdP access to trusted networks only.

Workarounds:

• If upgrading is not immediately possible, set SENTRY_SINGLE_ORGANIZATION = True to disable multi-organization support. This prevents the attack vector but may impact functionality.

Valters IT
DevSecOps & Cyber Threat Intelligence Expert