Authentik Security in Summer 2026: What Operators Need to Patch Now
Authentik Security in Summer 2026: What Operators Need to Patch Now
Auth bypass CVE-2026-49448, three advisory waves, and the new three-month cycle: what Authentik operators need to patch now, with a version matrix.
Content notice: The information in this article was compiled to the best of our knowledge at the time of publication. Technical details, pricing, versions, licensing models and external content are subject to change. Please verify the information independently, especially before making business-critical or security-relevant decisions. This article does not constitute individual professional, legal or tax advice.
Table of Contents
- Three advisory waves in ten weeks: the situation at a glance
- CVE-2026-49448: the critical Source stage bypass in detail
- The other advisories: SAML in focus
- Version matrix: which Authentik version is safe now?
- The new three-month cycle and what it means for operations
- Patch strategy for self-hosters: an honest checklist
- When managed hosting takes over the patch load and what it does not solve
- Conclusion
- Sources
Three advisory waves in ten weeks: the situation at a glance
The raw numbers look alarming: 16 security advisories for Authentik between mid-May and mid-July 2026, two of them rated critical [1]. The right reading is a different one. Authentik now bundles vulnerability disclosures into coordinated waves, announces them at least 24 hours before the patch release via the security mailing list [8], and shipped the fixes on the same day for all supported version lines [9]. The high number mainly reflects targeted security research and a transparent disclosure process, not an insecure product. The advisories contain no indication of active exploitation.
| Wave | Date | Advisories | Fixed in |
|---|---|---|---|
| 1 | May 12, 2026 | 8, including CVE-2026-42849 (reflected XSS, critical) | 2025.12.5, 2026.2.3 [1][9] |
| 2 | May 28, 2026 | 3, including CVE-2026-49448 (auth bypass, critical, CVSS 9.8) | 2025.12.6, 2026.2.4, 2026.5.2 [1][9] |
| 3 | Jul 15, 2026 | 5, including CVE-2026-57580 (account takeover via SAML) | 2026.5.5, 2026.2.6 [5][9] |
The waves still deserve to be taken seriously. The May 28 wave included CVE-2026-49448, an unauthenticated auth bypass of the highest category [2]. The July wave hit operators of the 2025.12 line without a patch, because its support had already ended on May 22, 2026 [12]. And the federation layer is in focus strikingly often: four of the 16 advisories concern SAML processing [1].
CVE-2026-49448: the critical Source stage bypass in detail
How the bypass works
Source stages bind external identity sources such as another SSO or social logins into Authentik flows. The flaw: if a Source stage is bound to a flow, the source exposes a login button, and an attacker can reach the stage, the source authentication could be skipped entirely with an empty POST request [2]. The attacker needs neither an account nor user interaction: the vulnerability is rated CVSS 9.8 (vector AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H) and classified as CWE-287, Improper Authentication [10].
Who is affected and who is not
Affected are installations up to and including 2025.12.5, 2026.2.3, and 2026.5.0 [2]. Fixes shipped in 2025.12.6 and 2026.2.4; for the 2026.5 line, the advisory metadata names 2026.5.1 [2], but that version tag was skipped: the release notes mark the version as skipped, no Git tag exists, and the fix shipped with 2026.5.2 on May 28, 2026 [6][9]. If your flows contain no Source stage with an exposed login button, this specific bypass did not affect you, but you should still patch: the same wave closed two more high-severity vulnerabilities.
On the response side: since 2026.5, Authentik offers Account Lockdown, an enterprise feature for immediate reaction to compromised accounts; details in our article on the Authentik Account Lockdown.
The other advisories: SAML in focus
Besides the bypass, the May 28 wave brought two more high-severity advisories. CVE-2026-49443 (GHSA-wr38-7xg8-fqxr, CVSS 8.8): the fields UserSourceConnection.user and GroupSourceConnection.group could be changed via the API; an attacker with a source account and permissions on source connection objects could thereby assign themselves foreign identities up to admin accounts [4]. CVE-2026-47201 (GHSA-c3m2-jqmq-pvp3, CVSS 8.5) concerned XML signature wrapping in the ACS endpoint of SAML sources: the signature check accepted the signed original assertion, but the identity data was read from a forged assertion, allowing authentication as any federated user. As a workaround, the advisory recommends disabling affected SAML sources or blocking access to their ACS endpoints [3].
The July wave of July 15, 2026, comprises five advisories, fixed in 2026.5.5 and 2026.2.6 [5]:
| CVE / GHSA | Content | Severity |
|---|---|---|
| CVE-2026-57580 | Account takeover via SAML NameID comment truncation | High |
| CVE-2026-61574 | RAC endpoints and stored credentials accessible to any authenticated user, connections can cross app boundaries | High |
| CVE-2026-54730 | Google Chrome Device Trust stages can be bypassed | High |
| CVE-2026-55106 | LDAP source debug endpoint reachable without authorization | Moderate |
| GHSA-hmrg-vpp4-gj88 (no CVE) | Broken access control in Shared Signals Framework stream management | Moderate |
The wave of May 12 had already bundled eight advisories, among them reflected XSS in the Simplified Flow Executor (CVE-2026-42849, critical), a SAML NameID XML comment injection (CVE-2026-40165), and unauthenticated access via the X-Original-URI header in nginx forward-auth mode (GHSA-5wcc-hf24-rf5h) [1].
The pattern across all three waves: the federation layer, meaning SAML parsing and external sources, is the largest attack surface. Anyone using SAML sources or Source stages in production should treat advisories in this category with top priority [1].
Version matrix: which Authentik version is safe now?
As of August 1, 2026, the following applies [5][6][9][12]:
| You are running | Safe target | Urgency |
|---|---|---|
| 2026.5.0 to 2026.5.4 | Update to 2026.5.6 (minimum for the July advisories: 2026.5.5) | High: 2026.5.0 additionally contains the 9.8 bypass CVE-2026-49448 |
| 2026.2.0 to 2026.2.5 | Minimum 2026.2.6, plan an upgrade to 2026.5.x in the medium term | High at 2026.2.3 or older (May 28 wave unfixed), otherwise medium |
| 2025.12.x | Major upgrade to 2026.5.6: the July wave was no longer patched for 2025.12 | Very high: end-of-life plus known high-severity advisories open |
| Older | Major upgrade, plan the upgrade path along the official documentation | Very high |
Beyond the version, run a feature-based exposure check: it determines which advisories concretely affect your instance [1][5]:
- SAML sources configured? (CVE-2026-47201, CVE-2026-57580)
- Source stage with an exposed login button in a flow? (CVE-2026-49448)
- RAC in use? (CVE-2026-61574)
- LDAP sources connected? (CVE-2026-55106)
- Chrome Device Trust active? (CVE-2026-54730)
- Nginx forward-auth mode? (GHSA-5wcc-hf24-rf5h)
Important: the exposure check prioritizes, it does not replace patching. Several advisories affect components such as API serializers that are active in practically every installation.
The new three-month cycle and what it means for operations
In the 2026.2 release notes, the team announced the new cadence verbatim: "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, released on May 22, 2026, is the first release in this rhythm [11]. No date for 2026.8 has been officially announced; a next major release in August follows from the three-month cadence only as an expectation.
The support window stays as it is: security fixes go to the current version and one previous version [8], as of today 2026.5.x and 2026.2.x [8][12]. With the three-month cadence, this effectively means about six months per major version. 2025.12 shows how hard the edge is: support ended on May 22, 2026 [12], the line still received 2025.12.6 on May 28 despite having reached end-of-life [9], and the July wave brought no 2025.12 patch [5].
For operations, the new cadence means: rarer but bigger major upgrades, sometimes with breaking changes. 2026.5, for example, changed the listen default from 0.0.0.0 to [::] and declared AUTHENTIK_POSTGRESQL__CONN_OPTIONS deprecated [6]. The security patch frequency remains unaffected and dense: the 2026.5 line alone received five patch releases between May 28 and July 22, 2026 [9]:
| Release | Date | Content |
|---|---|---|
| 2026.5.2 | May 28, 2026 | Security wave of May 28 plus bug fixes, including OAuth2 session decode when upgrading from 2026.2 [6][9] |
| 2026.5.3 | Jun 10, 2026 | Bug fixes (including blueprints) and Django security update to 5.2.15 [6] |
| 2026.5.4 | Jul 8, 2026 | Performance (DB queries, brand caching), SCIM, web UI [6] |
| 2026.5.5 | Jul 15, 2026 | Security wave of July 15 [5][6] |
| 2026.5.6 | Jul 22, 2026 | Stability: policy engine filtering, SCIM group member handling, rate throttling, storage paths via env var; no new advisories [6][9] |
Staying inside the support window therefore realistically means a major jump every three to six months plus short-notice patch windows in between, sometimes with 24 hours of lead time [8]. To be fair: the window per major is actually slightly longer than before; the patch load comes from the advisory density and the major jumps, not from the cycle alone. And it is the flip side of an advantage cloud IdPs do not offer: with self-hosting you set maintenance windows and pace yourself, whereas Microsoft dictates deadlines to its customers, as the SMS MFA retirement in Entra ID shows.
Patch strategy for self-hosters: an honest checklist
- Subscribe to security announcements. The authentik-security-announcements mailing list and the Discord server are the official channels; advisories are announced at least 24 hours before the patch release [8]. Define who reads and evaluates the announcements.
- Document your exposure profile. Record which features your instance uses (SAML sources, Source stages, RAC, LDAP, forward-auth). With that, each new wave can be triaged in minutes: emergency window or regular one.
- Run a staging environment. At the latest for major upgrades with breaking changes as in 2026.5 [6], you need a test run that covers flows, outposts, and integrations.
- Prepare maintenance windows and rollback. A defined patch window plus tested backups decides whether a 24-hour lead time [8] means routine or stress.
- Keep a version calendar. Track support ends, for example via the release notes or endoflife.date [12], and plan the major jump before your own line becomes the second-oldest.
A short compliance note: GDPR Article 32 requires state-of-the-art measures, which includes applying security updates promptly, and an identity provider by nature processes personal data of all users. For companies in scope of NIS2, a documented patch process for the IdP directly supports the required vulnerability handling; how MFA and access control obligations can be implemented with Authentik is shown in NIS2: MFA and access control with Authentik. This article is a technical assessment, not legal advice.
When managed hosting takes over the patch load and what it does not solve
Summer 2026 is a reality check for the make-or-buy question: three advisory waves, three version lines patched on the same day on May 28 [9], plus a major release with breaking changes [6]. The division of labor looks like this:
| Task | Self-hosted | Managed (e.g. authhost) |
|---|---|---|
| Advisory monitoring | Your obligation (mailing list, Discord, GitHub) | Handled by the provider |
| Patch deployment, sometimes with 24 h lead time | Your own maintenance window | Applied for you, rollback via automatic backups |
| Major upgrades about every 3 months (breaking changes) | Your own planning plus staging test | Handled by the provider |
| Flow, policy, and source configuration | Your responsibility | Stays with the customer |
| Security of the connected applications | Your responsibility | Stays with the customer |
| Incident response for compromised accounts | Your responsibility | Tools available, responsibility stays with the customer |
Self-hosting is enough if an established patch process with staging and defined maintenance windows exists, the team actively reads security announcements, container know-how does not depend on a single person, and the organization wants maximum control over every configuration layer. Authentik ships everything needed for that free of charge, from the advisory process to the documentation [8].
Managed is worthwhile if nobody has the capacity to patch within 24 to 48 hours of an announcement, no staging exists for major upgrades, IdP operations are not your core business but an outage is business-critical, or GDPR-compliant hosting in Germany with a data processing agreement is a hard requirement. At authhost, exactly this operations part is the product: a dedicated Authentik instance with automatic backups and updates, 24/7 monitoring, hosting in Germany, and a data processing agreement, from EUR 99.90 per month plus VAT in the Starter plan (Germany region), Business from EUR 199.90 per month, cancellable monthly. Details are in the feature overview and the pricing overview; the trial runs for seven days and requires a credit card.
To stay honest: managed hosting reduces the risk of patch delay, it does not make an instance unassailable. Flow and policy configuration, the security of connected applications, and incident response remain your responsibility. And anyone still choosing an IdP should settle the product question first; the differences between the two big open-source projects are examined in the Keycloak alternative Authentik.
→ View plans and pricing | → Start a 7-day trial
Conclusion
Three things Authentik operators should do now. First, check your own version against the matrix: target 2026.5.6, minimum 2026.5.5 or 2026.2.6 respectively, and a major upgrade is due for 2025.12.x [5][9]. Second, secure your information channels: subscribe to the mailing list and document your exposure profile so the next wave does not trigger ad-hoc research [8]. Third, answer the operations question honestly: the new three-month cycle makes planning more predictable, but advisory waves with 24 hours of lead time remain part of the operating model [7][8].
The summer record does not speak against Authentik, quite the opposite: coordinated waves, CVSS ratings, backports to two lines, and a documented disclosure process are signs of a matured security process [1][8]. The only question is who carries this cadence in your company: your team, or a managed provider that is paid to do exactly that.
Sources
- GitHub Security Advisories, goauthentik/authentik (overview of all 2026 advisory waves): github.com
- GHSA-xp7f-xjjx-gwm8 / CVE-2026-49448: SourceStage bypass via empty POST (mechanism, affected and patched versions): github.com
- GHSA-c3m2-jqmq-pvp3 / CVE-2026-47201: XML signature wrapping in the SAML Source ACS (incl. workaround): github.com
- GHSA-wr38-7xg8-fqxr / CVE-2026-49443: UserSourceConnection/GroupSourceConnection changeable via API: github.com
- July wave of July 15, 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
- Authentik release notes 2026.5 (patch contents, "2026.5.1: Skipped", breaking changes): docs.goauthentik.io
- Authentik release notes 2026.2 (announcement of the three-month cycle, verbatim quote): docs.goauthentik.io
- Authentik security policy (support window, 24-hour advance notice, mailing list, Discord): docs.goauthentik.io
- GitHub Releases goauthentik/authentik (release dates, missing 2026.5.1 tag): github.com
- NVD: CVE-2026-49448 (CVSS 9.8, vector, CWE-287): nvd.nist.gov
- authentik blog: "authentik version 2026.5 is here!" (May 22, 2026, first release in the three-month cadence): goauthentik.io
- endoflife.date: Authentik (support window, end-of-life dates): endoflife.date
Frequently Asked Questions
What is CVE-2026-49448 in Authentik?▼
Which Authentik versions are still safe in summer 2026?▼
How often are new Authentik versions released?▼
How long does an Authentik version receive security updates?▼
How do I learn about new Authentik security vulnerabilities?▼
Do I have to patch if I use no SAML sources or Source stages?▼
What does the three-month cycle mean for my patching effort?▼
Why is there no Authentik 2026.5.1?▼
Does managed Authentik hosting take all patching work off my hands?▼
What does Managed Authentik at authhost cost?▼
Written by
Timo Wevelsiep
Founder, merkaio
Founder of merkaio. Managed Authentik Identity Hosting. Focus on identity management, SSO and zero trust architecture.
LinkedIn