Sentry has issued a second critical SAML SSO advisory in three months. CVE-2026-42354 (CVSS 9.1) was published on May 8, 2026 and re-opens the cross-organization account takeover hole that the project tried to close in February with CVE-2026-27197. The original patch shipped in 26.2.0; researchers found it could still be bypassed in versions through 26.4.0. Self-hosted operators running multi-organization Sentry instances need to push 26.4.1 today.

What’s broken

Sentry’s SAML Assertion Consumer Service trusts the email attribute in an inbound assertion to link an SSO session to an existing internal user. The 26.2.0 fix added some cross-organization checks, but they did not fully validate that the IdP issuing the assertion was authoritative for the target user’s home organization. An attacker who controls any organization on the same Sentry instance can:

  1. Configure a malicious SAML IdP under their own org.
  2. Issue a crafted assertion containing the victim’s email address.
  3. POST it to /api/0/saml-acs/{attacker_org}/.
  4. Land in Sentry as the victim — full session, full permissions, no password prompt.

The CVSS vector is AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:N. No victim interaction required, no privileges on the victim’s account required, and the only prerequisite information is the victim’s email. For SaaS providers, internal platform teams, and bug bounty triage tools that run shared Sentry instances, this is essentially “give me any account.”

Affected versions

  • Self-hosted Sentry >= 21.12.0, < 26.4.1
  • SENTRY_SINGLE_ORGANIZATION must be False (the default for any installation hosting more than one team)
  • The attacker must already have permission to add an SSO provider to some organization on the instance — a standard organization owner role on a free tenant is enough

Sentry SaaS (sentry.io) was patched server-side on May 7 — no customer action required. The exposure is entirely in the self-hosted distribution.

The incomplete-fix angle

CVE-2026-27197 in February tightened the link between SAML responses and the issuing organization, but the validation was performed at session-finalization time rather than at the assertion-binding step. Researcher Muhammad Qasim Munir (who reported the original bug) demonstrated that an attacker could still get the binding to occur by replaying the email-only assertion through a second org’s ACS endpoint before the cross-org check fired. 26.4.1 moves the verification earlier in the flow and additionally requires that the target user’s primary organization match the IdP’s claimed scope.

This is the third major incomplete-fix story this quarter after Langflow CVE-2026-33017 — a useful reminder that “patched” is not a state; it’s a hypothesis that needs to be re-tested.

What to do now

For self-hosted Sentry:

1
2
3
4
5
6
7
8

# Docker compose
docker pull getsentry/sentry:26.4.1
docker compose down
docker compose up -d

# pip-installed
pip install --upgrade sentry==26.4.1
sentry upgrade

If you cannot patch within the next few hours:

  • Set SENTRY_SINGLE_ORGANIZATION = True in sentry/config.yml and restart. This is the documented workaround and shuts the bug entirely, but it kills multi-tenancy.
  • Force two-factor authentication on every account via the org-level enforcement setting. 2FA blocks the final session establishment even after a successful assertion bind, per Sentry’s advisory. Note this is per-user — admins cannot enable it on someone else’s behalf, so coverage will be incomplete.
  • Audit sentry.audit_logentry for sso.identity.link events from organizations you don’t recognize. Any unexpected linkage in the last 90 days is suspicious.
  • Block external access to /api/0/saml-acs/* paths from anywhere except your IdP’s egress IPs at the load balancer. This is a stopgap and only helps if your IdP traffic is reasonably static.

Detection

The exploit leaves a clean signal in the audit log. Grep for:

1
2
3
4
5

SELECT actor_label, target_object, data
FROM sentry_auditlogentry
WHERE event = 51  -- sso.identity.link
  AND datetime > now() - interval '7 days'
ORDER BY datetime DESC;

Any record where the linking organization differs from the user’s primary organization, or where the IdP’s entity ID does not match a known org-configured provider, should be treated as a successful exploitation attempt.

References