Wer Sentry betreibt, hat ein Problem. Am 8. Mai 2026 wurde mit CVE-2026-42354 eine kritische Schwachstelle (CVSS 9.1) in der SAML-SSO-Implementierung des weit verbreiteten Error-Tracking-Werkzeugs offengelegt. Die Lücke betrifft jede Sentry-Installation zwischen Version 21.12.0 und 26.4.1 – und damit faktisch jeden Entwicklungsstack, der Sentry seit Ende 2021 in Produktion einsetzt. Der Angriff ist bedrückend trivial: Eine SAML-Assertion mit der bekannten E-Mail-Adresse des Opfers reicht, um dessen Konto vollständig zu übernehmen. Kein Passwort. Kein Klick. Kein Phishing.

Was genau ist passiert?

Sentry ist die De-facto-Standardlösung für Application Performance Monitoring und Fehlerverfolgung in JavaScript-, Python-, Go- und Mobile-Stacks. Wer in Github, in der Cloud oder in der CI/CD-Pipeline nach Trace-IDs sucht, landet früher oder später bei einem Sentry-Dashboard. Genau dort liegen Daten, die jede Cyberkriminalität liebt: Stack Traces mit internen Pfaden, Datenbank-Queries mit Tabellennamen, vereinzelt auch Tokens und Header, die in Fehlermeldungen versehentlich mitprotokolliert wurden. Ein übernommenes Sentry-Konto ist also kein nettes Beifang – es ist Aufklärungsmaterial erster Güte für jeden, der einen Folge-Angriff auf die Produktivumgebung plant.

Die Schwachstelle wurde am 8. Mai 2026 öffentlich – mit einem CVSS-Score von 9.1 und einer klaren Empfehlung des Sentry-Sicherheitsteams: sofort auf Version 26.4.1 aktualisieren und alle SSO-Sitzungen invalidieren. Sofort bedeutet: nicht im nächsten Wartungsfenster, nicht im freitäglichen Patch-Run, sondern jetzt.

Der technische Mechanismus: Wenn die Vertrauenskette reißt

SAML (Security Assertion Markup Language) ist das XML-basierte Protokoll, mit dem die meisten Enterprise-SSO-Verbindungen aufgebaut werden. Im Normalfall funktioniert es so: Ein Identity Provider (IdP) – etwa Okta, Microsoft Entra ID oder ein selbst betriebener Keycloak – stellt eine signierte XML-Assertion aus, die behauptet: „Dieser Benutzer ist Max Mustermann mit der E-Mail max@firma.de." Der Service Provider, in unserem Fall Sentry, prüft die Signatur, vertraut der Aussage und gewährt Zugang.

Die Lücke in CVE-2026-42354 entsteht an der Stelle, an der Sentry diese Aussage einer internen Identität zuordnet – konkret: über die E-Mail-Adresse. Auf einer Mehrmandanten-Sentry-Instanz – sentry.io selbst oder jede selbst gehostete Variante mit mehreren Organisationen – durfte bislang jede Organisation ihren eigenen Identity Provider konfigurieren. Sentry hat diese SAML-Aussagen pro Organisation isoliert geprüft, aber bei der finalen Verknüpfung mit dem Benutzerkonto die Organisationsgrenze ignoriert: Wer als angreifende Organisation einen eigenen, bösartigen IdP einrichtete, konnte eine Assertion über die E-Mail-Adresse eines fremden Benutzers ausstellen – und Sentry verknüpfte diese Anmeldung mit dem bestehenden Konto in der echten Organisation.

Der Angriff in fünf Schritten:

  1. Angreifer registriert eine eigene Organisation auf der Sentry-Instanz – kostenlos auf sentry.io, trivial bei selbstgehosteten Mehrmandanten-Setups.
  2. Angreifer richtet einen eigenen SAML-IdP ein, den er kontrolliert – zum Beispiel ein selbstgebauter SimpleSAMLphp oder ein Ad-hoc-Mock.
  3. Angreifer löst eine SSO-Anmeldung aus und liefert eine Assertion mit der E-Mail-Adresse des Opfers (beispielsweise cto@kunden-firma.de).
  4. Sentry akzeptiert die Assertion, sucht nach einem Konto mit dieser E-Mail und führt den Angreifer in genau dieses Konto.
  5. Angreifer hat vollen Zugriff auf alle Projekte, Issues, Source Maps und Token-Sammlungen, die das Opfer sehen darf.

Was diesen Bug so gefährlich macht, ist nicht die Komplexität – die ist überschaubar – sondern die Voraussetzung. Wer eine Liste von E-Mail-Adressen hat (und die hat jeder, der LinkedIn lesen kann), kann jedes Sentry-Konto übernehmen, das auf SAML-SSO umgestellt wurde. Eine SAML-Assertion ist hier kein Token, das man stehlen muss – sie ist eine Behauptung, die ein angreifendes IdP einfach ausstellt.

Wer ist betroffen – und wer ist es nicht?

Betroffen sind alle Sentry-Installationen ab Version 21.12.0 bis einschließlich der Versionen unmittelbar vor 26.4.1. Das deckt einen Zeitraum von Dezember 2021 bis Anfang Mai 2026 ab – fast viereinhalb Jahre Produktivbetrieb. Wer auf sentry.io als SaaS-Kunde liegt, wurde vom Sentry-Team automatisch gepatcht. Wer Sentry self-hosted betreibt – und das tun viele Unternehmen mit Datenschutz-Anforderungen oder On-Prem-Stacks – muss den Patch eigenhändig aufspielen.

Nicht betroffen sind:

  • Sentry-Installationen ohne SAML-SSO. Wer ausschließlich Passwort- oder OAuth-Login verwendet, ist außerhalb der direkten Angriffsfläche.
  • Single-Tenant-Self-Hosted-Setups, in denen es per Konfiguration nur eine einzige Organisation gibt – die Mehrmandanten-Voraussetzung des Angriffs entfällt.

Aber Achtung: Auch ein Single-Tenant-Setup ist nur dann sicher, wenn Sie wirklich überprüft haben, dass die Organisationsanlage administrativ deaktiviert oder durch Ihre Identity-Provider-Konfiguration zwingend an Ihre Domäne gebunden ist. Standardinstallationen erlauben das Anlegen weiterer Organisationen – und genau das ist die Voraussetzung des Angriffs.

Sofortmaßnahmen – die nächsten 48 Stunden

Wenn Sie Sentry in Ihrer Pipeline haben (und mit hoher Wahrscheinlichkeit haben Sie das), arbeiten Sie folgende Reihenfolge ab:

1. Patch einspielen

Aktualisieren Sie auf Sentry 26.4.1 oder höher. Bei sentry.io-SaaS müssen Sie nichts tun – der Patch ist serverseitig ausgerollt. Bei On-Prem-Sentry führen Sie den Standard-Upgrade-Prozess durch und prüfen anschließend in den Audit-Logs auf ungewöhnliche SAML-Anmeldungen der letzten 30 Tage.

2. Sitzungen invalidieren

Im Admin-Bereich alle aktiven SSO-Sitzungen beenden. Auch wenn Sie keinen Vorfall beobachtet haben: Wenn ein Angreifer in den vergangenen Tagen aktiv war, ist sein Token möglicherweise noch gültig. Wer keine Cookie-Invalidierung erzwingt, hat den Angriff nicht beendet, sondern nur die Tür für die nächste Welle geschlossen.

3. Audit-Logs prüfen

Sehen Sie sich die SSO-Anmeldelogs der letzten 30 Tage an. Verdächtig sind:

  • Anmeldungen aus IP-Bereichen, die nicht zu Ihren Standorten oder Ihrem IdP passen.
  • Login-Events, in denen die issuer-URL der SAML-Assertion nicht zu Ihrem konfigurierten IdP passt.
  • Konten, die Sentry-Projekte betreten haben, mit denen sie sonst nichts zu tun haben (laterale Bewegung).
  • API-Token, die nach einem auffälligen Login erstellt wurden – diese überleben das Invalidieren der Sitzung.

4. Kreditkartensensible Daten rotieren

Der schmerzhafteste Schritt: Alle Tokens und Geheimnisse, die jemals in Sentry-Issues gelandet sein könnten, müssen rotiert werden. Ja, auch wenn Sie „eigentlich" nichts Vertrauliches loggen. In der Praxis enthalten Stack Traces fast immer Substrings, die irgendwo Authentifizierungsmaterial sind – Connection Strings, Authorization-Header, JWT-Fragmente. Wer hier nicht rotiert, hat den Bug zwar geschlossen, die durchgesickerten Geheimnisse aber unverändert in Umlauf gelassen.

5. Multi-Tenancy abschalten

Wenn Ihre Self-hosted-Sentry-Instanz für mehrere Organisationen offen ist, prüfen Sie, ob das wirklich nötig ist. Einer der nachhaltigsten Härtungsschritte gegen ähnliche Klassen von Bugs ist, Mehrmandanten-Konfigurationen nur dort zu erlauben, wo sie unverzichtbar sind.

Warum dieser Bug Teil eines Musters ist

CVE-2026-42354 ist nicht der erste SAML-Bug dieser Art und wird nicht der letzte sein. Allein im vergangenen Jahr haben PortSwigger, GitHub und mehrere SaaS-Anbieter Schwachstellen offengelegt, die alle dasselbe Grundmuster zeigen: SAML-Assertions werden zu vertrauensvoll behandelt – über Organisationsgrenzen hinweg, an Parser-Differenzen vorbei oder mit unzureichenden Signaturchecks. Die Ursache ist immer dieselbe: SAML ist ein altes, komplexes XML-Protokoll mit vielen Konfigurationsoptionen, dessen Sicherheitsmodell darauf beruht, dass eine Handvoll vertrauenswürdiger IdPs ehrliche Aussagen über Benutzer macht. Sobald jemand selbst zum IdP wird, kollabiert diese Annahme.

Für Unternehmen, die ihren Identity-Stack als Rückgrat ihrer Informationssicherheit betreiben, bedeutet das: Ein einziger Bug in einem einzigen Service Provider kann den Schaden eines klassischen Phishing-Angriffs um Größenordnungen übertreffen, weil SSO-Token Zugriff auf alle verbundenen Anwendungen geben. Wer SSO einführt – und das ist der Mittelstand 2026 fast flächendeckend – muss sich der Konzentrationsrisiken bewusst sein und die einzelnen Service Provider regelmäßig auf solche Schwachstellen prüfen.

Was bleibt zu tun?

Der Sentry-Bug zeigt erneut, dass die Sicherheitsdiskussion in Entwicklerteams zu lange auf Source-Code-Schwachstellen fokussiert war und die Tools, mit denen wir diesen Code beobachten und betreiben, als gegeben hingenommen hat. Jede Komponente in der Softwareentwicklungs-Pipeline ist ein potenzieller Angriffspunkt – und je tiefer eine Komponente in der Identity-Federation verankert ist, desto höher der Schaden, wenn sie fällt.

pleXtec unterstützt Mittelständler dabei, ihre Identity-Stacks zu durchleuchten, SSO-Integrationen kritisch zu prüfen und Patch-Prozesse so aufzustellen, dass eine 9.1-CVE keine zwei Wochen Reaktionszeit braucht. Wenn Sie unsicher sind, ob Ihre Sentry-Instanz – oder eine andere SaaS-Komponente in Ihrer Pipeline – im Falle eines analogen Bugs schnell genug gepatcht würde, sprechen Sie mit uns über einen Identity-Audit.

Bis dahin gilt: Patchen Sie heute. Rotieren Sie morgen. Und überdenken Sie übermorgen, wie viele Service Provider Sie wirklich an dieselbe SSO-Wurzel hängen wollen.