CVE-2026-42354: Sentry SAML SSO Flaw Enables Full Account Takeover — PoC Available

CVE-2026-42354 is a critical improper-authentication vulnerability in Sentry — a widely-used open-source error tracking and application performance monitoring platform — that allows an attacker controlling a SAML Identity Provider to impersonate any user on the same Sentry instance by submitting a crafted SAML assertion containing the victim's email address. Self-hosted Sentry versions 21.12.0 through 26.1.0 are affected; the fix is version 26.4.1. A working proof-of-concept exploit is publicly available.

CVE-2026-42354: Technical Details

Sentry's SAML SSO (Security Assertion Markup Language Single Sign-On — a federated authentication protocol that lets organizations use an external Identity Provider, or IdP, to authenticate users without maintaining passwords in Sentry itself) implementation authenticates users by matching the email address in a SAML assertion against an existing internal user account. When a match is found, Sentry creates an authenticated session for that account.

The vulnerability in CVE-2026-42354 (rated Critical) arises because Sentry does not validate the origin of the SAML assertion across organizational boundaries. On Sentry instances running in multi-organization mode — where SENTRY_SINGLE_ORGANIZATION = False is set in config.yml, the standard configuration for enterprise self-hosted deployments serving multiple product teams or customers — each organization can independently configure its own SAML IdP. The flaw allows an attacker who controls the SSO configuration of any one organization to configure a malicious SAML IdP, then use it to issue a crafted SAML assertion claiming the email address of a victim user in a different organization. Sentry accepts the assertion and grants the attacker a fully authenticated session as the victim — without the victim's password, MFA token, or any user action.

Affected versions: Sentry self-hosted 21.12.0 through 26.1.0. Patched version: 26.4.1 (self-hosted). Sentry's cloud-hosted SaaS offering was patched February 18, 2026.

The CVSS v3.1 vector for CVE-2026-42354 reflects the severity of the attack path: network-accessible, low complexity, and requiring only that the attacker have permission to modify SSO settings in any one of the instance's organizations — a bar that is lower than it appears in large enterprise deployments with many organizational units.

Attack prerequisites:

• SENTRY_SINGLE_ORGANIZATION = False (multi-organization mode enabled — common in enterprise deployments)
• Attacker has access to at least one organization on the Sentry instance
• Attacker has, or can acquire, permission to modify that organization's SSO settings
• Attacker knows the email address of the victim user (often obtainable from the Sentry UI in shared projects, or from external sources)
• Attacker controls a SAML Identity Provider (trivially created with open-source tools)

Attack flow:

• Attacker registers or compromises any organization on the vulnerable Sentry instance.
• Attacker deploys a malicious SAML IdP (using tools such as SimpleSAMLphp or a custom script).
• Attacker configures the malicious IdP as the SSO provider for their organization.
• Attacker crafts a SAML authentication response with <saml:NameID> or <saml:Attribute> containing the victim's email address.
• Attacker submits the forged SAML response to the Sentry SSO endpoint.
• Sentry matches the email, trusts the assertion, and creates an authenticated session for the victim's account — without the victim's involvement.

Exploitation Status and Threat Landscape

A proof-of-concept exploit — demonstrating this attack chain in both Bash and Python — is publicly available. The existence of working PoC code significantly lowers the exploitation bar: any attacker with a Sentry account and SSO-modification privileges can weaponize this vulnerability against the current unpatched software without writing custom exploit code.

CVE-2026-42354 has not been added to the CISA KEV catalog at the time of writing, and there are no confirmed reports of active exploitation in the wild. However, the combination of a public PoC and a low-complexity attack path means that exploitation should be anticipated. Security teams typically model weaponization of public PoC vulnerabilities within a 7–30 day window of PoC release.

The applicable MITRE ATT&CK technique is T1606.002 — Forge Web Credentials: SAML Tokens. This technique, documented extensively in the ATT&CK framework, describes exactly this class of attack: adversaries forge SAML assertions to gain unauthorized access to web services and applications. It is the same technique used in the 2020 SolarWinds supply chain compromise, where nation-state actors forged SAML tokens to access cloud services across victim organizations without credentials — a high-profile example that demonstrated SAML token forgery at scale against enterprise environments.

Who Is Affected

Self-hosted Sentry instances running versions 21.12.0 through 26.1.0 with these conditions present:

• Multi-organization mode is active (SENTRY_SINGLE_ORGANIZATION = False in sentry/config.yml)
• At least one organization on the instance has SAML SSO configured
• An attacker has, or can obtain, SSO-admin permissions in any organization on the instance

Not affected: Sentry SaaS (sentry.io) — the cloud-hosted version was patched on February 18, 2026. Organizations using only SENTRY_SINGLE_ORGANIZATION = True (single-org mode) eliminate the cross-organization attack vector, though they remain on vulnerable software and should still upgrade.

The highest-risk environments are:

• Enterprise self-hosted deployments where multiple teams use separate Sentry organizations on a shared instance
• Managed service providers hosting Sentry for multiple clients — a compromised client with SSO-admin rights could pivot to impersonate users in all other client organizations on the same host
• Security operations teams using Sentry to capture and route security alerts — a Sentry compromise gives attackers direct visibility into an organization's detection telemetry

Sentry is deployed at thousands of software engineering teams worldwide. Its project data routinely includes stack traces containing environment variables, API keys that appear in error contexts, database query logs, user PII from crash contexts, and internal service topology. An attacker impersonating a Sentry project owner gains access to all of this.

What You Should Do Right Now

• Upgrade self-hosted Sentry to version 26.4.1 immediately. This is the patched release. Obtain the upgrade via your deployment method:

“bash # Docker Compose (standard self-hosted deployment) cd /path/to/sentry-self-hosted git pull git checkout 26.4.1 ./install.sh docker compose up -d “

For Helm chart deployments, update the chart tag to 26.4.1 and run helm upgrade.

• Verify your SENTRY_SINGLE_ORGANIZATION setting. If your instance serves only a single organization and SENTRY_SINGLE_ORGANIZATION = True is confirmed in sentry/config.yml, the cross-organization exploit path does not apply. Still upgrade — the setting is not a workaround for the vulnerability itself.

“bash grep SENTRY_SINGLE_ORGANIZATION /path/to/sentry/sentry/config.yml “

• Audit SSO configuration access. Identify every user account with permission to modify SAML SSO settings within each organization. Restrict this permission to named administrators. Remove it from service accounts, shared logins, and regular developers.

• Review SAML authentication logs for anomalous cross-organization assertions. In centralized log aggregation (Splunk, Elastic, etc.), search for SSO authentication events where the authenticating organization's IdP does not match the target user's primary organization. Unexpected cross-org assertions indicate potential exploitation.

“ # Example Splunk search index=sentry source=sentry-auth event_type=saml_login | eval cross_org = if(auth_org != user_primary_org, "ANOMALY", "ok") | where cross_org = "ANOMALY" “

• Enable and enforce two-factor authentication (2FA) for all accounts. While 2FA does not block this specific vulnerability, it can interrupt authentication completion in some configurations and should be enforced regardless on all administrative accounts as a baseline defense.

• Rotate long-lived API tokens and session credentials for high-privilege Sentry accounts if you cannot rule out prior exploitation. Any account with project-owner or org-admin access should be treated as potentially compromised on unpatched instances where an attacker may have had access.

Background: Understanding the Risk

SAML SSO has had a poor security track record in 2026. WorkOS documented five critical SAML vulnerabilities across different platforms in a four-month span, identifying a consistent root cause: multi-tenant SAML implementations often fail to enforce that an IdP is actually authorized for the specific resource being accessed, because the SAML specification itself relies on out-of-band trust establishment that is easy to misconfigure in multi-tenant code paths.

Sentry's vulnerability follows this exact pattern. The SAML specification requires that a Service Provider (in this case Sentry) verify that the assertion came from a trusted IdP. In a single-org deployment, this is straightforward: there is exactly one IdP and it is either trusted or not. In a multi-org deployment, the security model requires verifying that the IdP that signed the assertion is specifically the IdP authorized for the organization that owns the user account being claimed — not just any IdP trusted by any organization on the instance. CVE-2026-42354 is the result of that cross-organization check being absent.

This is not the first SAML issue in Sentry's history. CVE-2026-27197 — an earlier advisory affecting versions 21.12.0 through 26.1.x and patched in 26.2.0 — involved a similar improper SAML account-linking bypass. CVE-2026-42354 represents a newer variant of the same class, bypassing protections introduced in 26.2.0, and requires patching to 26.4.1.

The structural similarity to the Golden SAML attack technique — which was used against SolarWinds victims in 2020 and documented by Mandiant and Microsoft — underscores that SAML token forgery is a mature, well-understood attacker capability that threat actors actively seek to exploit in enterprise environments.

For security teams that rely on Sentry to capture and route application security events — WAF alerts, authentication anomalies, API abuse signals — a Sentry compromise is particularly damaging: it gives attackers direct access to your detection telemetry, enabling them to understand your alert thresholds and evasion opportunities.

Conclusion

CVE-2026-42354 combines a public PoC, a low-complexity attack path, and access to highly sensitive application data. Self-hosted Sentry operators running versions 21.12.0 through 26.1.0 must upgrade to 26.4.1 immediately. Multi-organization deployments serving multiple teams or external customers face the greatest exposure and should treat this as an emergency patching event. Audit SSO admin permissions and review authentication logs for cross-organization assertion anomalies as immediate follow-up actions.