Safeguard
Vulnerability Analysis•

CVE-2026-42354: Critical SAML Account Takeover in Sentry

CVE-2026-42354 lets a rogue SAML provider on a multi-org Sentry instance take over accounts. Affects 21.12.0 to before 26.4.1. Upgrade to 26.4.1 or later.

Safeguard Security Team
3 min read

CVE-2026-42354 is a critical flaw (CVSS 9.1) in the SAML single sign-on code of Sentry, versions 21.12.0 up to but not including 26.4.1. On an instance with several organizations, a malicious identity provider can be used to take over another user's account. The fix is Sentry 26.4.1.

What's affected

The NVD record covers Sentry from 21.12.0 to before 26.4.1. The GitHub advisory lists the patched version as 26.4.1.

Sentry SaaS is not something you need to patch. The advisory says the fix was deployed there already. Self-hosted installs are the concern, and only under specific conditions:

  • More than one organization is configured, meaning SENTRY_SINGLE_ORGANIZATION is False.
  • A malicious user already has permission to change SSO settings for another organization on the same instance.

If your self-hosted instance allows only a single organization (SENTRY_SINGLE_ORGANIZATION set to True), the advisory says no action is needed, though it still recommends upgrading.

How to check if you're exposed

Find the version of your self-hosted Sentry and its organization setting.

  1. Look at the Sentry image tag in your self-hosted deployment, or the version shown in your release notes and deploy records. Anything from 21.12.0 up to 26.3.x or the 26.4.0 build is in range.
  2. Open your Sentry configuration and check the value of SENTRY_SINGLE_ORGANIZATION.
  3. In the organization list, note who can edit SSO settings. The attack needs someone with that permission in a different organization from the victim.

The attacker must also know the victim's email address, so the real risk grows with the number of untrusted organization admins on your instance.

What to do now

  1. Upgrade self-hosted Sentry to 26.4.1 or later.
  2. If you cannot upgrade today, ask users to turn on two-factor authentication on their own accounts. The advisory says this stops an attacker completing sign in as the victim. Organization admins cannot do it for users.
  3. Review which people hold SSO administration rights in each organization and remove any that are not needed.
  4. Review recent SSO configuration changes and sign in events for organizations you do not recognise.
  5. If you run a single organization, still schedule the upgrade, since the advisory recommends it.

Why it matters

The weakness is classed as CWE-290, authentication bypass by spoofing. Sentry trusted the identity a SAML provider asserted without tying it firmly enough to the organization that configured that provider. A second organization on the same instance could therefore present a victim's email through its own provider and be treated as that person.

The score is high because no victim action is needed and confidentiality and integrity impact are both high. The need to hold SSO admin rights in another organization limits who can attempt it. The record's KEV flag is false, and I found no statement that it is exploited in the wild.

Quick check

Do I need to act if I only use Sentry SaaS?

No. The advisory says the fix was deployed to Sentry SaaS and no action is required.

Does two-factor authentication really help?

The advisory lists it as a workaround. A user with 2FA enabled on their own account blocks the takeover, but each user has to set it up themselves.

Sources

Last reviewed: 19 October 2026.

Never miss an update

Weekly insights on software supply chain security, delivered to your inbox.

Self-healing security runs on Safeguard.

Your first fix PR is minutes away.

No sales call required, even your agent can complete the purchase over MCP.