CVE-2026-27197: 
Python vulnerability analysis and mitigation

CVE-2026-27197 is a critical improper authentication vulnerability in Sentry's SAML SSO implementation, allowing an attacker to take over any user account by leveraging a malicious SAML Identity Provider in conjunction with another organization on the same Sentry instance. It affects Sentry versions 21.12.0 through 26.1.0 (pip package). The vulnerability was reported via Sentry's private bug bounty program by researcher Muhammad-Qasim-Munir, disclosed on February 18, 2026, and published to NVD on February 21, 2026. It carries a CVSS v3.1 base score of 9.1 (Critical) (GitHub Advisory, Github Advisory).

The root cause is CWE-287 (Improper Authentication) in Sentry's SSO login pipeline, specifically in how AuthIdentity records for inactive users are handled. The fix (PR #108458) reveals that inactive-user AuthIdentity records were not always routed through the standard handle_unknown_identity verification flow, and stale AuthIdentity records were not cleaned up on user deactivation — allowing an attacker to link a malicious SAML Identity Provider's assertion to a victim's existing account. Exploitation requires the attacker to know the victim's email address and, for self-hosted instances, to have access to modify SSO settings for at least one organization in a multi-organization deployment (SENTRY_SINGLE_ORGANIZATION = False). No privileges or user interaction are required from the victim's side (GitHub Advisory, Sentry PR #108458).

Successful exploitation grants an attacker complete unauthorized access to the victim's Sentry account without valid credentials or any victim interaction, resulting in high confidentiality and integrity impact with no availability impact. An attacker can access sensitive error tracking data, performance monitoring information, source code context, secrets embedded in error reports, and any other data visible to the compromised account. In multi-organization Sentry instances, this could enable lateral movement across organizations if the victim account has cross-organization access (GitHub Advisory, Feedly).

As of the time of reporting, there is no public proof-of-concept exploit and no evidence of in-the-wild exploitation (Feedly). The EPSS score is approximately 0.058% (19th percentile), indicating a currently low probability of exploitation within 30 days (Github Advisory). No threat actor attribution or CISA KEV catalog listing has been identified for this vulnerability. The attack requires no privileges or user interaction, making it straightforward to exploit if the attacker knows the victim's email and meets the multi-organization precondition.

1. Reconnaissance: Identify a vulnerable multi-organization Sentry instance (self-hosted, version 21.12.0–26.1.0 with SENTRY_SINGLE_ORGANIZATION = False) or target Sentry SaaS prior to February 18, 2026. Obtain the victim's email address through OSINT, phishing, or other means.
2. Gain organization access: Register or obtain access to a secondary organization on the same Sentry instance where SSO settings can be modified (requires existing legitimate access to that organization with admin permissions).
3. Configure malicious SAML IdP: Set up a malicious SAML Identity Provider (e.g., a self-hosted IdP such as SimpleSAMLphp or a custom SAML server) and configure it to issue SAML assertions claiming the victim's email address.
4. Link malicious IdP to organization: In the attacker-controlled organization's SSO settings, configure the malicious SAML IdP as the SSO provider.
5. Trigger SSO authentication: Initiate a SAML SSO login flow through the attacker-controlled organization using the malicious IdP, which issues a SAML assertion for the victim's email address.
6. Exploit improper identity linking: Due to the vulnerability in Sentry's SSO pipeline, the stale or inactive AuthIdentity record associated with the victim's email is not properly verified, allowing the malicious SAML assertion to be linked to the victim's existing Sentry account.
7. Account takeover: The attacker is authenticated as the victim user, gaining full access to the victim's Sentry account, projects, and data (GitHub Advisory, Sentry PR #108458).

• Logs: Unexpected SSO login events for a user account originating from an unfamiliar or newly configured SAML Identity Provider; authentication log entries showing a user authenticated via SAML from an organization they do not normally use.
• Logs: Sentry audit log entries showing SSO configuration changes (new IdP added) in an organization, followed shortly by login events for accounts belonging to other organizations.
• Logs: IntegrityError or unusual error messages in Sentry's authentication pipeline logs (src/sentry/auth/helper.py) around the handle_unknown_identity or handle_existing_identity functions.
• Account Activity: Unexpected session creation or API token generation for user accounts, particularly outside normal working hours or from unusual IP addresses.
• Configuration: Presence of an unfamiliar or recently added SAML IdP in an organization's SSO settings, especially one not matching the organization's known identity provider.

Sentry SaaS users were automatically protected when the fix was deployed on February 18, 2026 — no action is required. Self-hosted Sentry users should upgrade to version 26.2.0 or higher immediately; instances configured with SENTRY_SINGLE_ORGANIZATION = True are not vulnerable and require no action. As a workaround for those unable to upgrade, individual users should enable account-level two-factor authentication (2FA) via Account Settings > Security, which prevents an attacker from completing authentication even if identity linking is exploited — note that organization administrators cannot enable 2FA on behalf of users (GitHub Advisory).

The vulnerability was covered by The Hacker Wire, which highlighted the critical nature of the SAML SSO bypass and its account takeover potential (The Hacker Wire). Community discussion was noted on Mastodon and security aggregator platforms shortly after disclosure. Red Hat also tracked the advisory, reflecting broader ecosystem awareness (Red Hat). Overall community sentiment emphasized the severity of the unauthenticated account takeover scenario and the importance of upgrading self-hosted instances promptly.