CVE-2026-42849: Wie ein Link eine Authentik-Session übernimmt

Eine OAuth-URL reicht

Am 12. Mai 2026 hat das Authentik-Team die Sicherheitslücke CVE-2026-42849 veröffentlicht. Wir sind im Rahmen eines Penetrationstests gegen die Hochsicherheits-Infrastruktur eines Kunden auf den Bug gestoßen und haben ihn am 24. April 2026 als Reflected Cross-Site-Scripting im Simple Flow Executor an Authentik gemeldet. Eigene Schwachstellen in eingesetzter Software zu entwickeln, statt sich auf die Abarbeitung dokumentierter CVE-Listen zu beschränken, gehört bei uns zum Standardvorgehen. Die offizielle CVSS-Bewertung liegt bei 9.3 (CVSS:3.1/AV:N/AC:L/PR:N/UI:R/S:C/C:H/I:H/A:N). Betroffen sind Authentik 2026.2.2 und älter sowie 2025.12.4 und älter. Gepatcht ist die Schwachstelle in 2026.2.3 und 2025.12.5.

Praktisch heißt das: Wer einen aktiven Authentik-Tenant mit OAuth2-Provider betreibt und nicht innerhalb der letzten Stunden auf die Patch-Version aktualisiert hat, sitzt heute auf einer ausnutzbaren XSS auf der eigenen Single-Sign-On-Origin. Eingeloggte Anwender klicken auf einen präparierten OAuth-Link, und der Authentik-Server reflektiert den injizierten Payload zurück in den Browser. Der Code läuft im Vertrauenskontext der Authentik-Domain, mit Zugriff auf Session-Cookies, lokal gespeicherte Tokens und alle Backend-APIs, die der Anwender ansprechen darf.

Dieser Beitrag erklärt die Sink, beide Angriffsvektoren, die nötigen Voraussetzungen und die Konsequenzen für SSO-Betreiber, die nicht sofort patchen können.

Anatomie der Sink

Der Simple Flow Executor ist eine zweite, schlanke Rendering-Variante der Authentik-Login-Flows. Authentik nutzt ihn, wenn der Browser kein modernes JavaScript-Bundle ausführen kann oder wenn der Aufrufer ?sfe an die Flow-URL anhängt. Der SFE ist in JavaScript implementiert und liegt unter web/packages/sfe/src/index.ts.

Die zentrale Methode ist AutosubmitStage.render. Sie baut ein HTML-Formular via Template-Literal-Konkatenation auf und schreibt das Ergebnis ohne Sanitierung in den DOM. Der folgende Auszug ist gegenüber dem Original um Brand-Logo, Titel-Heading und Spinner gekürzt; die XSS-relevanten Interpolations-Stellen sind unverändert:

render() {
    this.html(`
        <form id="autosubmit-form" action="${this.challenge.url}" method="POST">
            ${Object.entries(this.challenge.attrs).map(([key, value]) =>
                `<input type="hidden" name="${key}" value="${value}" />`
            )}
        </form>`);
    $("#autosubmit-form").submit();
}

html(html: string) {
    this.executor.container.innerHTML = html;
}

Sowohl this.challenge.url als auch jeder Wert in this.challenge.attrs wird unescaped in ein HTML-Attribut interpoliert. Sobald ein Wert ein Anführungszeichen enthält, bricht er aus dem Attribut aus. Der Sink ist container.innerHTML, der jQuery-Submit nutzt nach der Zuweisung das gerenderte Formular, aber zu diesem Zeitpunkt hat der Browser den injizierten DOM-Inhalt bereits geparst und Side-Effects wie <img src=...> ausgelöst.

Das Authentik-Team nennt im Advisory selbst den Grund: Der SFE wurde geschrieben, um Kompatibilität mit Legacy-Browsern zu erhalten, und nutzt jQuery ohne saubere Sanitierung der Eingaben.

Vektor 1: der state-Parameter

Der OAuth2-Flow akzeptiert einen state-Parameter, der zwischen Client und Authorization Server zur CSRF-Absicherung mitgereicht wird. Authentik schreibt den Wert ungeprüft in AutosubmitChallenge.attrs["state"]. Im SFE landet er anschließend im value-Attribut eines Hidden-Inputs.

Ein Angreifer baut folgende URL und schickt sie an ein eingeloggtes Opfer:

https://authentik.example.com/application/o/authorize/?
  client_id=<gueltige_id>
  &redirect_uri=<registrierte_uri>
  &response_type=code
  &response_mode=form_post
  &state="><img src="https://attacker.example/xss"><input name="z" value="
  &sfe

Das angehängte &sfe zwingt Authentik in den Simple Flow Executor. Der state-Wert bricht aus dem value="..."-Attribut aus, schließt das Input-Tag, fügt ein <img> mit beliebiger Quelle ein und öffnet ein neues, harmloses Input-Tag, damit der Rest des Templates valides HTML bleibt.

Der Effekt: Sobald der Browser des Opfers den innerHTML-Aufruf ausführt, parst er das injizierte <img>-Tag und löst einen Cross-Origin-Request gegen die Angreifer-Domain aus. Die Request-Header enthalten Origin: https://authentik.example.com. Damit ist bewiesen, dass der Code im Authentik-Origin-Kontext ausgeführt wurde, also mit Zugriff auf Cookies, lokal gespeicherte Tokens und das authentifizierte Session-Material.

Voraussetzung am Tenant ist ausschließlich, dass mindestens ein OAuth2-Provider mit gebundener Application existiert und der Authorization Flow auf der Default-Konfiguration default-provider-authorization-implicit-consent steht. Der Angreifer braucht eine gültige client_id und eine registrierte redirect_uri. Beide sind über öffentlich zugängliche Quellen oder über passive Beobachtung legitimer OAuth-Flows zu beschaffen. .well-known/openid-configuration enthält sie nicht, aber JS-Bundles der angebundenen Anwendungen, Fehlermeldungen oder Setup-Dokumentation in der Regel schon.

Vektor 2: der redirect_uri-Parameter

Der zweite Pfad nutzt die redirect_uri. Authentik schreibt sie in AutosubmitChallenge.url, die im SFE in das action-Attribut des Formulars eingesetzt wird. Aus dem action="..." auszubrechen funktioniert analog zum state-Vektor.

Voraussetzung ist ein OAuth2-Provider, der matching_mode: regex für die redirect_uri verwendet, mit einem permissiven Pattern. Der Worst Case ist .*, in der Praxis kommen auch Patterns wie https?://.* oder https://example\.com/.* vor. Sobald das Regex einen vom Angreifer kontrollierten String erlaubt, ist der redirect_uri-Vektor offen. Bei matching_mode: strict ist dieser Pfad blockiert; der state-Vektor bleibt offen.

Wer in der Vergangenheit von CVE-2024-21637 betroffen war oder davon gelesen hat, kennt das Anti-Pattern. Die Empfehlung war schon damals, Regex-Matching nur in begründeten Sonderfällen einzusetzen. Setup-Anleitungen Dritter und Migrationen aus älteren OIDC-Stacks tragen das Pattern dennoch weiter in produktive Tenants.

Impact

Der Code läuft im Browser des Opfers auf der Authentik-Origin. Vier Konsequenzen sind dadurch trivial:

• Session-Hijacking über den authentik_session-Cookie. Authentik setzt HttpOnly=True als Default. Wer diesen Default deaktiviert hat, ist direkt betroffen; wer ihn nicht angefasst hat, ist über CSRF-API-Aufrufe mit der aktiven Session weiterhin angreifbar.
• Exfiltration von Tokens aus localStorage der Authentik-Domain, falls die Anwendung dort Material ablegt.
• CSRF-fähige API-Calls gegen alle Authentik-Endpunkte mit der Identität des Opfers.
• Tenant-Übernahme, wenn das Opfer ein Mitglied einer privilegierten Rolle ist.

Im MITRE ATT&CK Framework entspricht der Angriffspfad der Technik T1539 Steal Web Session Cookie. Sie beschreibt, wie ein authentifizierter Browser-Kontext über Session-Cookies übernommen wird, ohne dass ein Anmeldevorgang ein zweites Mal durchlaufen werden muss.

Der Angreifer benötigt keinen Account am Tenant und keinen Admin-Zugang. Er braucht einen funktionierenden Link, eine gültige client_id, ein eingeloggtes Opfer und eine Sekunde. Der OWASP Top 10 Listenpunkt A03:2021 Injection zeigt, warum eine ungesanitierte innerHTML-Zuweisung trotz aller modernen Framework-Konventionen weiterhin in Produktivsystemen landet: Legacy-Pfade und Kompatibilitäts-Code werden seltener auditiert als die modernen Renderpipelines.

Patch und Mitigation

Der primäre und vom Authentik-Team empfohlene Fix ist das Update auf 2026.2.3 oder 2025.12.5. Die offiziellen Authentik-Releases enthalten den Patch und brechen keine bestehende Konfiguration. Authentik dokumentiert den Vorfall zusätzlich in der hauseigenen CVE-Doku zu CVE-2026-42849 mit Patch-Anleitung, betroffenen Versionen und Workarounds für nicht aktualisierbare Tenants.

Wer aus operativen Gründen nicht sofort patchen kann, hat drei kurzfristige Härtungsschritte. Der erste ist der Wechsel von matching_mode: regex auf matching_mode: strict an allen OAuth2-Providern und das Eintragen der exakten Callback-URLs. Das schließt den redirect_uri-Vektor vollständig.

Der zweite Schritt ist die Deaktivierung des Simple Flow Executors über den Reverse Proxy. Ein nginx-Snippet, das alle Anfragen mit ?sfe oder dem entsprechenden Cookie ablehnt, bricht zwar Legacy-Browser-Support, schließt aber beide Vektoren. Für die meisten Unternehmens-Tenants ist das ein tolerabler Trade-off:

if ($arg_sfe) { return 400; }
if ($http_cookie ~* "sfe=") { return 400; }

Der dritte Schritt ist eine harte Content Security Policy auf den Flow-Routen /if/flow/*. Die OWASP Cross Site Scripting Prevention Cheat Sheet empfiehlt eine restriktive Policy als Defense in Depth:

Content-Security-Policy: default-src 'self'; script-src 'self'; img-src 'self'; object-src 'none'

Wichtig ist die Beschränkung von img-src auf 'self'. Der Exfil-Vektor in beiden PoCs läuft über <img src=...> ohne Skriptausführung. Eine CSP, die nur script-src einschränkt, blockiert diesen Pfad nicht.

Lehren für SSO-Deployments

Der Vorfall ist klein in seiner Codeänderung und groß in seiner Lehre. Erstens: Legacy-Renderpfade sind ein eigenes Audit-Subjekt. Wer den Hauptpfad einer Anwendung absichert, hat oft noch eine zweite, ältere Rendering-Variante, die unter speziellen Bedingungen aktiv wird und deutlich weniger Schutzschichten hat. Der SFE in Authentik ist ein Beispiel, ähnliche Pfade existieren in vielen Identity-Stacks.

Zweitens: innerHTML mit String-Interpolation ist in 2026 keine akzeptable Pattern mehr. Moderne UI-Frameworks bieten DOM-API-Konstruktoren, die das Problem strukturell ausschließen. Wer eigene Komponenten baut, sollte document.createElement plus appendChild als Standard etablieren und String-Templates nur für reinen Text via textContent zulassen.

Drittens: Regex-redirect_uri ist eine selbstgebaute Angriffsfläche. Authentik dokumentiert das seit der Patch-Welle um CVE-2024-21637 deutlich, dennoch finden sich permissive Patterns in Produktivkonfigurationen. Wer einen SSO-Tenant betreibt, sollte alle OAuth2-Provider in einer Inventory führen und für jeden den matching_mode regelmäßig auditieren.

Fazit

CVE-2026-42849 ist eine textbuchklassische Reflected XSS, in einem schlanken, leicht zu übersehenden Legacy-Pfad eines sonst sauberen IAM-Produkts. Der Sink ist eine einzige unsanitisierte innerHTML-Zuweisung, der Angriff braucht weder Admin-Zugang noch Tenant-Manipulation, und der Effekt ist Session-Übernahme im SSO-Vertrauenskontext. Wer Authentik betreibt, patcht heute auf 2026.2.3 oder 2025.12.5. Wer nicht patchen kann, schaltet den SFE über den Reverse Proxy ab und setzt eine restriktive CSP auf den Flow-Routen. Und wer einen SSO-Audit plant, prüft Legacy-Renderpfade, innerHTML-Sinks und permissive redirect_uri-Regexe als drei eigenständige Punkte. Ein begleitender Penetrationstest gegen die Login-Flows zeigt, ob die Mitigation in der eigenen Umgebung wirklich greift.