CVE-2026-42354 - Sentry SAML SSO identity linking

Self-hosted Sentry versions 21.12.0 through 26.4.0 contain a critical SAML SSO authentication flaw in multi-organization deployments. A malicious user who can configure SAML SSO for one organization on the same Sentry instance can use a malicious identity provider and a known victim email address to link into the victim’s user account.

The highest-risk shape is a shared self-hosted Sentry installation with multiple organizations, organization-managed SAML settings, and users who do not enforce account-level two-factor authentication. Sentry SaaS was patched by the vendor; ordinary application use of Sentry SDKs is not this CVE.

When to use it

Use this recipe when a repository deploys self-hosted Sentry in multi-organization mode, manages SAML SSO settings, or owns Sentry identity-linking configuration. It is designed for source-code/deployment remediation, tenant-scoped SAML identity review, account-takeover impact assessment, session/credential cleanup, and evidence that malicious organization IdPs cannot link victim accounts.

Inputs

  • Sentry server version, Python/package pins, self-hosted image tags, compose or Helm values, SENTRY_SINGLE_ORGANIZATION, SAML SSO settings, and generated dependency or SBOM reports.
  • Source/config paths that deploy Sentry server, configure organizations, manage SAML IdPs, require 2FA, map user email/name IDs, or handle session invalidation.
  • Regression or operator checks for fixed versions, tenant-scoped identity linking, 2FA enforcement, suspicious IdP/link review, and session expiration.
  • Boundary evidence: organizations, SAML providers, account owners, admin users, audit logs, incident-review owner, and rollout owner.

Affected versions

  • Vulnerable: sentry >=21.12.0, <=26.4.0
  • Fixed: sentry >=26.4.1

Indicator-of-exposure

  • The repository owns or deploys a self-hosted Sentry server, not just a Sentry SDK, DSN, or integration.
  • Sentry resolves to a vulnerable sentry Python package version or a vulnerable self-hosted Sentry release/container tag.
  • Multi-organization mode is enabled, such as SENTRY_SINGLE_ORGANIZATION = False.
  • SAML SSO is enabled for one or more organizations, and organization owners can modify SSO identity provider configuration.
  • Account-level 2FA is not required for all users.

Quick checks:

rg -n "getsentry|sentry.*self-hosted|SENTRY_SINGLE_ORGANIZATION|SAML|saml2|sso" .
rg -n "sentry==|sentry[<=>]|getsentry/sentry|self-hosted" requirements*.txt pyproject.toml poetry.lock Pipfile.lock Dockerfile* docker-compose*.yml .github deploy helm charts k8s
docker image ls | rg 'getsentry|sentry'

Remediation strategy

  • Upgrade self-hosted Sentry to 26.4.1+, including Python package pins, container images, Helm/chart values, compose files, and self-hosted release manifests controlled by the repository.
  • If the instance is intended to be single-organization only, set and verify SENTRY_SINGLE_ORGANIZATION = True as a compensating exposure reduction.
  • Require user account-level 2FA for Sentry users, especially administrators and users in organizations with SAML SSO enabled.
  • Inventory organization SAML providers and identity links after patching. If suspicious links or IdP changes are found, expire sessions and require a human-reviewed account recovery plan.
  • Do not treat Sentry SDK dependency updates as remediation unless this repo actually builds or deploys the Sentry server.

The prompt

You are remediating CVE-2026-42354 (Sentry SAML SSO identity linking account
takeover) in this repository or deployment source. Produce exactly one output:

- A reviewer-ready PR/change request that upgrades self-hosted Sentry and
  documents required operator validation, or
- TRIAGE.md if this repository does not own a self-hosted Sentry server or safe
  deployment patch path.

## Rules

- Scope only CVE-2026-42354.
- Distinguish self-hosted Sentry server deployments from ordinary Sentry SDK,
  DSN, logging, CI, or monitoring integrations.
- Do not change unrelated identity provider settings, organization ownership,
  user emails, or account links automatically.
- Do not log SAML assertions, cookies, session tokens, IdP secrets, private
  keys, DSNs, or user secrets.
- Do not auto-merge.

## Steps

1. Inventory Sentry server ownership:
   - Python package pins for `sentry`;
   - `getsentry/sentry` or self-hosted release images;
   - Docker Compose, Helm, Kubernetes, Terraform, Ansible, or release manifests;
   - internal runbooks that pin self-hosted Sentry versions.
2. If the repo only uses Sentry SDKs, DSNs, source-map uploaders, alerting
   integrations, or Sentry SaaS, stop with `TRIAGE.md` explaining why this CVE
   is not patchable here.
3. Determine whether any self-hosted Sentry server version resolves to
   `>=21.12.0, <=26.4.0`.
4. Check exposure-relevant configuration and record it in the PR body:
   - `SENTRY_SINGLE_ORGANIZATION` effective value;
   - whether SAML SSO is enabled;
   - whether organization owners can modify SSO provider settings;
   - whether account-level 2FA is required for administrators and SAML users.
5. Upgrade every vulnerable self-hosted Sentry reference to `26.4.1+` on the
   repository's normal release line. Regenerate lockfiles, image metadata,
   Helm lock files, SBOMs, and deployment render output where applicable.
6. Add or update a short operator runbook section named
   `CVE-2026-42354 operator checks` that requires:
   - verification that the deployed Sentry version is `26.4.1+`;
   - review of recent SAML IdP configuration changes across organizations;
   - review of unexpected SAML identity links for privileged users;
   - session expiration and account recovery steps if suspicious links exist;
   - enforcement or rollout tracking for user account-level 2FA.
7. If upgrade cannot be deployed immediately, add the safest temporary
   containment available in this repo, such as forcing single-organization mode
   for single-tenant deployments, disabling organization-managed SAML setup
   behind a feature flag, restricting Sentry admin access, or documenting an
   emergency 2FA requirement.
8. Run available validation: dependency resolution, image build or manifest
   rendering, configuration tests, and any auth/SSO tests this repo provides.
9. Use PR title:
   `fix(sec): remediate CVE-2026-42354 in self-hosted Sentry`.

## Stop conditions

- The repository does not deploy a self-hosted Sentry server.
- The only Sentry references are SDKs, DSNs, logging exporters, source-map
  upload tooling, or SaaS integrations.
- A fixed self-hosted Sentry version cannot be consumed without a larger
  platform migration.
- The patch would automatically alter SAML identity links, organization
  ownership, or user accounts without operator approval.
- Validation fails for unrelated pre-existing reasons; document the failure
  instead of broadening scope.

Output contract

  • A reviewer-ready PR or change request that upgrades self-hosted Sentry, refreshes deployment artifacts, verifies tenant-scoped SAML linking, enforces compensating controls, and documents account/session review.
  • Or a TRIAGE.md file that lists inspected images/config, owner, observed version, SAML identity-linking boundary, required fix, and residual risk.
  • The output must include exact validation commands and must not create malicious IdPs, link real victim accounts, expose SAML assertions, or dump account data.

Verification - what the reviewer looks for

  • No self-hosted Sentry server reference remains on 21.12.0 through 26.4.0.
  • The change updates the actual deployment source, not only a development or SDK dependency.
  • The PR body records multi-organization, SAML, and 2FA exposure status.
  • Operator checks cover SAML IdP changes, suspicious identity links, session expiry, and human-reviewed account recovery.
  • Build, dependency, image, and deployment-render checks pass or unrelated failures are documented.

Watch for

  • Repositories that contain both Sentry SDKs and a self-hosted Sentry deployment; only the server side is relevant to this CVE.
  • Floating image tags that make the patch non-reproducible.
  • Assuming organization-level SAML controls can enforce account-level 2FA for every user; the workaround depends on users having account 2FA enabled.
  • Confusing this advisory with earlier Sentry SAML identity-linking advisories that have different fixed versions.

References