Authentik-Sicherheitslage im Sommer 2026: Was Betreiber jetzt patchen müssen

Inhaltsverzeichnis

• Drei Advisory-Wellen in zehn Wochen: die Lage im Überblick
• CVE-2026-49448: der kritische Source-Stage-Bypass im Detail
  • Wie der Bypass funktioniert
  • Wer betroffen ist und wer nicht
• Die weiteren Advisories: SAML im Fokus
• Versionsmatrix: Welche Authentik-Version ist jetzt sicher?
• Der neue 3-Monats-Zyklus und was er für den Betrieb bedeutet
• Patch-Strategie für Selbst-Hoster: eine ehrliche Checkliste
• Wann Managed Hosting die Patch-Last abnimmt und was es nicht löst
• Fazit
• Quellen

Drei Advisory-Wellen in zehn Wochen: die Lage im Überblick

Wer nur die nackten Zahlen sieht, könnte erschrecken: 16 Security Advisories für Authentik zwischen Mitte Mai und Mitte Juli 2026, zwei davon als Critical eingestuft [1]. Die richtige Lesart ist eine andere. Authentik bündelt Schwachstellen-Veröffentlichungen inzwischen in koordinierten Wellen, kündigt sie mindestens 24 Stunden vor dem Patch-Release über die Security-Mailingliste an [8] und lieferte die Fixes jeweils am selben Tag für alle unterstützten Versionslinien [9]. Die hohe Zahl ist vor allem ein Zeichen für gezielte Sicherheitsforschung und einen transparenten Disclosure-Prozess, nicht für ein unsicheres Produkt. Hinweise auf eine aktive Ausnutzung der Lücken gibt es in den Advisories nicht.

Ernst nehmen muss man die Wellen trotzdem, denn die Inhalte haben es in sich. Die Welle vom 28. Mai enthielt mit CVE-2026-49448 einen unauthentifizierten Auth-Bypass der höchsten Kategorie [2]. Die Juli-Welle traf Betreiber der 2025.12-Linie ohne Patch, weil deren Support bereits am 22. Mai 2026 endete [12]. Und auffällig oft steht die Föderations-Schicht im Fokus: Vier der 16 Advisories betreffen die SAML-Verarbeitung [1].

CVE-2026-49448: der kritische Source-Stage-Bypass im Detail

Wie der Bypass funktioniert

Source Stages binden externe Identitätsquellen wie ein anderes SSO oder Social Logins in Authentik-Flows ein. Der Fehler: Ist eine Source Stage in einen Flow eingebunden, deren Quelle einen Login-Button exponiert, und kann ein Angreifer die Stage erreichen, ließ sich die Source-Authentifizierung mit einem leeren POST-Request komplett überspringen [2]. Der Angreifer braucht dafür weder ein Konto noch Nutzerinteraktion: Die Lücke ist mit CVSS 9.8 bewertet (Vektor AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H) und als CWE-287, Improper Authentication, klassifiziert [10].

Wer betroffen ist und wer nicht

Betroffen sind Installationen bis einschließlich 2025.12.5, 2026.2.3 und 2026.5.0 [2]. Gefixt wurde in 2025.12.6 und 2026.2.4; für die 2026.5-Linie nennen die Advisory-Metadaten 2026.5.1 [2], dieser Versionstag wurde jedoch übersprungen: Die Release Notes vermerken die Version als Skipped, ein Git-Tag existiert nicht, ausgeliefert wurde der Fix mit 2026.5.2 vom 28.05.2026 [6][9]. Wer keine Source Stage mit exponiertem Login-Button in seinen Flows verwendet, war von diesem konkreten Bypass nicht betroffen, sollte die Patch-Stände aber trotzdem einspielen, denn dieselbe Welle schloss zwei weitere High-Lücken.

Für den Ernstfall lohnt außerdem ein Blick auf die Reaktionsseite: Seit 2026.5 bietet Authentik mit Account Lockdown ein Enterprise-Feature für die Sofort-Reaktion auf kompromittierte Konten; die Details zeigt unser Beitrag zum Authentik Account Lockdown.

Die weiteren Advisories: SAML im Fokus

Die Welle vom 28. Mai brachte neben dem Bypass zwei weitere High-Advisories. CVE-2026-49443 (GHSA-wr38-7xg8-fqxr, CVSS 8.8): Die Felder UserSourceConnection.user und GroupSourceConnection.group ließen sich über die API ändern; ein Angreifer mit einem Source-Account und Rechten auf Source-Connection-Objekte konnte sich so fremde Identitäten bis hin zu Admin-Konten zuweisen [4]. CVE-2026-47201 (GHSA-c3m2-jqmq-pvp3, CVSS 8.5) betraf XML Signature Wrapping im ACS-Endpoint von SAML Sources: Die Signaturprüfung akzeptierte die signierte Original-Assertion, die Identitätsdaten wurden aber aus einer geschmiedeten Assertion gelesen, was die Authentifizierung als beliebiger föderierter Nutzer erlaubte. Als Workaround nennt das Advisory, betroffene SAML Sources zu deaktivieren oder den Zugriff auf deren ACS-Endpoints zu blockieren [3].

Die Juli-Welle vom 15.07.2026 umfasst fünf Advisories, gefixt in 2026.5.5 und 2026.2.6 [5]:

Bereits die Welle vom 12. Mai hatte acht Advisories gebündelt, darunter Reflected XSS im Simplified Flow Executor (CVE-2026-42849, Critical), eine SAML NameID XML Comment Injection (CVE-2026-40165) und einen unauthentifizierten Zugriff über den X-Original-URI-Header im Nginx-Forward-Auth-Modus (GHSA-5wcc-hf24-rf5h) [1].

Das Muster über alle drei Wellen: Die Föderations-Schicht, also SAML-Parsing und externe Sources, ist die größte Angriffsfläche. Wer SAML Sources oder Source Stages produktiv nutzt, sollte Advisories dieser Kategorie mit höchster Priorität behandeln [1].

Versionsmatrix: Welche Authentik-Version ist jetzt sicher?

Stand 1. August 2026 gilt [5][6][9][12]:

Ergänzend zur Version lohnt ein Exposure-Check nach Features, denn er bestimmt, welche Advisories Ihre Instanz konkret treffen [1][5]:

• SAML Sources konfiguriert? (CVE-2026-47201, CVE-2026-57580)
• Source Stage mit exponiertem Login-Button in einem Flow? (CVE-2026-49448)
• RAC im Einsatz? (CVE-2026-61574)
• LDAP Sources angebunden? (CVE-2026-55106)
• Chrome Device Trust aktiv? (CVE-2026-54730)
• Nginx-Forward-Auth-Modus? (GHSA-5wcc-hf24-rf5h)

Wichtig: Der Exposure-Check priorisiert, er ersetzt das Patchen nicht. Mehrere Advisories betreffen Komponenten wie API-Serializer, die in praktisch jeder Installation aktiv sind.

Der neue 3-Monats-Zyklus und was er für den Betrieb bedeutet

In den Release Notes zu 2026.2 kündigte das Team den neuen Takt wörtlich an: „In recent years, a new authentik release was cut roughly every two months. We will be extending this to target a three-month release cycle, with the next release being 2026.5 in May." [7] 2026.5, erschienen am 22. Mai 2026, ist der erste Release in diesem Rhythmus [11]. Ein Termin für 2026.8 ist nicht offiziell angekündigt; aus dem 3-Monats-Takt ergibt sich ein nächster Major-Release im August lediglich als Erwartung.

Beim Supportfenster bleibt es dabei: Security-Fixes erhalten die aktuelle Version und eine Vorversion [8], Stand heute also 2026.5.x und 2026.2.x [8][12]. Mit dem 3-Monats-Takt ergibt sich daraus faktisch ein Fenster von rund sechs Monaten pro Major-Version. Wie hart die Kante am Ende ist, zeigt 2025.12: Das Support-Ende war der 22. Mai 2026 [12], mit 2025.12.6 vom 28. Mai wurde die Linie trotz bereits erreichtem End-of-Life noch einmal gepatcht [9], für die Juli-Welle gab es dann keinen 2025.12-Patch mehr [5].

Für den Betrieb heißt der neue Takt: seltener, dafür größere Major-Upgrades, teils mit Breaking Changes. 2026.5 änderte etwa den Listen-Default von 0.0.0.0 auf [::] und deklarierte AUTHENTIK_POSTGRESQL__CONN_OPTIONS als deprecated [6]. Die Security-Patch-Frequenz bleibt davon unberührt und dicht: Allein die 2026.5-Linie erhielt zwischen dem 28. Mai und dem 22. Juli 2026 fünf Patch-Releases [9]:

Wer im Supportfenster bleiben will, plant damit realistisch alle drei bis sechs Monate einen Major-Sprung plus unterjährig kurzfristige Patch-Fenster, teils mit 24 Stunden Vorlauf [8]. Ehrlicherweise: Das Supportfenster pro Major ist mit dem 3-Monats-Takt sogar etwas länger als früher; die Patch-Last entsteht durch die Advisory-Dichte und die Major-Sprünge, nicht durch den Zyklus allein. Und sie ist die Kehrseite eines Vorteils, den Cloud-IdPs nicht bieten: Beim Selbstbetrieb bestimmen Sie Wartungsfenster und Tempo selbst, während etwa Microsoft seinen Kunden Stichtage schlicht vorgibt, wie das SMS-MFA-Retirement in Entra ID zeigt.

Patch-Strategie für Selbst-Hoster: eine ehrliche Checkliste

1. Security-Announcements abonnieren. Die Mailingliste authentik-security-announcements und der Discord-Server sind die offiziellen Kanäle; Advisories werden mindestens 24 Stunden vor dem Patch-Release angekündigt [8]. Legen Sie fest, wer die Ankündigungen liest und bewertet.
2. Exposure-Profil dokumentieren. Halten Sie fest, welche Features Ihre Instanz nutzt (SAML Sources, Source Stages, RAC, LDAP, Forward-Auth). Damit lässt sich bei jeder neuen Welle in Minuten entscheiden, ob ein Notfall-Fenster nötig ist oder das reguläre reicht.
3. Staging-Umgebung betreiben. Spätestens für Major-Upgrades mit Breaking Changes wie in 2026.5 [6] braucht es einen Testlauf, der Flows, Outposts und Integrationen abdeckt.
4. Wartungsfenster und Rollback vorbereiten. Ein definiertes Patch-Fenster plus getestete Backups entscheidet darüber, ob ein 24-Stunden-Vorlauf [8] Routine oder Stress bedeutet.
5. Versionskalender führen. Tragen Sie Support-Enden nach, etwa über die Release Notes oder endoflife.date [12], und planen Sie den Major-Sprung, bevor die eigene Linie zur zweitältesten wird.

Ein kurzer Compliance-Hinweis gehört zur ehrlichen Betrachtung dazu: Die DSGVO verlangt in Art. 32 Maßnahmen nach dem Stand der Technik, wozu das zeitnahe Einspielen von Sicherheitsupdates zählt, und ein Identity Provider verarbeitet naturgemäß personenbezogene Daten aller Nutzer. Für NIS2-betroffene Unternehmen zahlt ein dokumentierter Patch-Prozess für den IdP direkt auf das geforderte Schwachstellen-Handling ein; wie sich MFA- und Zugriffskontroll-Pflichten mit Authentik umsetzen lassen, zeigt unser Beitrag NIS2: MFA und Zugriffskontrolle mit Authentik. Dieser Beitrag ist eine technische Einordnung und kein Rechtsrat; die Bewertung im Einzelfall gehört zu Ihrem Datenschutz- und Compliance-Team.

Wann Managed Hosting die Patch-Last abnimmt und was es nicht löst

Der Sommer 2026 ist ein guter Realitätstest für die Make-or-Buy-Frage, denn er zeigt konkret, welche Arbeit anfällt: drei Advisory-Wellen, am 28. Mai drei Versionslinien am selben Tag [9], dazu ein Major-Release mit Breaking Changes [6]. Die Aufgabenteilung sieht so aus:

Selbstbetrieb reicht, wenn ein etablierter Patch-Prozess mit Staging und definierten Wartungsfenstern existiert, das Team Security-Announcements aktiv liest, Container-Know-how nicht an einer einzelnen Person hängt und die Organisation maximale Kontrolle über jede Konfigurationsebene will. Authentik liefert dafür alles Nötige kostenlos mit, vom Advisory-Prozess bis zur Doku [8].

Managed lohnt sich, wenn niemand die Kapazität hat, binnen 24 bis 48 Stunden nach einer Ankündigung zu patchen, kein Staging für Major-Upgrades existiert, der IdP-Betrieb nicht Kerngeschäft, ein Ausfall aber geschäftskritisch ist, oder DSGVO-konformes Hosting in Deutschland mit AV-Vertrag eine harte Anforderung darstellt. Bei authhost ist genau dieser Betriebsteil das Produkt: eine dedizierte Authentik-Instanz mit automatischen Backups und Updates, 24/7 Monitoring, Hosting in Deutschland und AV-Vertrag, ab 99,90 € pro Monat zzgl. MwSt. im Starter-Plan (Region Deutschland), Business ab 199,90 € pro Monat, monatlich kündbar. Die Details zeigen die Funktionsübersicht und die Preisübersicht; die Testphase läuft sieben Tage und setzt eine Kreditkarte voraus.

Ehrlich bleibt: Managed Hosting reduziert das Risiko von Patch-Verzug, es macht eine Instanz nicht unangreifbar. Flow- und Policy-Konfiguration, die Sicherheit der angebundenen Anwendungen und die Incident Response bleiben in Ihrer Verantwortung. Und wer noch grundsätzlich in der IdP-Auswahl steckt, sollte zuerst die Produktfrage klären; die Unterschiede der beiden großen Open-Source-Projekte beleuchtet unser Vergleich zur Keycloak-Alternative Authentik.

→ Pläne und Preise ansehen | → Sieben Tage testen

Fazit

Drei Dinge sollten Authentik-Betreiber jetzt erledigen. Erstens die eigene Version gegen die Matrix prüfen: Zielstand 2026.5.6, Minimum 2026.5.5 beziehungsweise 2026.2.6, bei 2025.12.x steht ein Major-Upgrade an [5][9]. Zweitens die Informationswege absichern: Mailingliste abonnieren und das eigene Exposure-Profil dokumentieren, damit die nächste Welle keine Ad-hoc-Recherche auslöst [8]. Drittens die Betriebsfrage ehrlich beantworten: Der neue 3-Monats-Zyklus macht die Planung berechenbarer, aber Advisory-Wellen mit 24 Stunden Vorlauf bleiben Teil des Betriebsmodells [7][8].

Die Sommer-Bilanz spricht dabei nicht gegen Authentik, im Gegenteil: Koordinierte Wellen, CVSS-Bewertungen, Backports auf zwei Linien und ein dokumentierter Disclosure-Prozess sind Zeichen eines gereiften Security-Prozesses [1][8]. Die Frage ist nur, wer diese Taktung in Ihrem Unternehmen trägt: Ihr Team oder ein Managed-Betreiber, der genau dafür bezahlt wird.

Jetzt Managed Authentik testen →

Quellen

1. GitHub Security Advisories, goauthentik/authentik (Übersicht aller Advisory-Wellen 2026): github.com
2. GHSA-xp7f-xjjx-gwm8 / CVE-2026-49448: SourceStage bypass via empty POST (Funktionsweise, betroffene und gepatchte Versionen): github.com
3. GHSA-c3m2-jqmq-pvp3 / CVE-2026-47201: XML Signature Wrapping im SAML Source ACS (inkl. Workaround): github.com
4. GHSA-wr38-7xg8-fqxr / CVE-2026-49443: UserSourceConnection/GroupSourceConnection über API änderbar: github.com
5. Juli-Welle vom 15.07.2026: GHSA-35v6-hv2g-6992 (CVE-2026-57580), GHSA-rv9x-92g6-9cpf (CVE-2026-61574), GHSA-3v9h-3hrm-29cx (CVE-2026-54730), GHSA-h8ff-c3h7-2gf8 (CVE-2026-55106), GHSA-hmrg-vpp4-gj88: github.com
6. Authentik Release Notes 2026.5 (Patch-Inhalte, „2026.5.1: Skipped", Breaking Changes): docs.goauthentik.io
7. Authentik Release Notes 2026.2 (Ankündigung des 3-Monats-Zyklus, wörtliches Zitat): docs.goauthentik.io
8. Authentik Security Policy (Supportfenster, 24h-Vorankündigung, Mailingliste, Discord): docs.goauthentik.io
9. GitHub Releases goauthentik/authentik (Release-Daten, fehlender 2026.5.1-Tag): github.com
10. NVD: CVE-2026-49448 (CVSS 9.8, Vektor, CWE-287): nvd.nist.gov
11. authentik-Blog: „authentik version 2026.5 is here!" (22.05.2026, erster Release im 3-Monats-Takt): goauthentik.io
12. endoflife.date: Authentik (Supportfenster, End-of-Life-Daten): endoflife.date