CSRF Failed: "X-Authentik-Csrf HTTP header has incorrect length" recurring across versions and flows (password change, token creation, WebAuthn setup)

Describe the bug

This is a recurrence of the class of bug described in #8704 and #10479: the X-Authentik-Csrf header sent by the frontend does not match what Django's CSRF middleware expects, even though a valid authentik_csrf cookie is present. Unlike those closed issues, I've reproduced it consistently across three different flows on a current version (2026.2.7), and ruled out the most common cause (Origin/Host header misconfiguration) documented in the troubleshooting guide.

Environment

• authentik version: 2026.2.7 (also reproduced on 2026.2.2 before upgrading, specifically to test whether a newer release fixed it - it did not)
• Deployment: docker-compose (server + worker + postgresql + redis)
• Reverse proxy: nginx-based (BunkerWeb), terminating TLS and forwarding to the embedded outpost

What I ruled out

Per the CSRF troubleshooting guide, the usual cause is an incorrect Origin or Host header from the reverse proxy. I checked this via GET /api/v3/admin/system/, which reports:

"http_headers": { "HTTP_HOST": "authentik.example.com", ... },
"http_host": "authentik.example.com"

No port, matches the configured domain exactly. The proxy config also does not rewrite Origin and correctly forwards Host/X-Forwarded-* headers. So this doesn't look like the Origin/Host mismatch the docs describe - the error text is also different in nature ("incorrect length" is a token-value check, not an origin check).

Actual behavior

Server log for each failing request shows:

{"event": "PermissionDenied(\"CSRF Failed: CSRF token from the 'X-Authentik-Csrf' HTTP header has incorrect length.\")", "flow_slug": "default-password-change", "logger": "authentik.flows.views.executor", "level": "warning", "auth_via": "session"}

Expected behavior

The frontend should send a correctly-formatted X-Authentik-Csrf header (mirroring the authentik_csrf cookie), and these standard account-management actions should succeed.

Workaround

Using a Bearer-token-authenticated API request (not cookie/session-based) to the same underlying endpoints (e.g. POST /api/v3/core/users/{id}/set_password/) works fine and is unaffected, since token auth doesn't go through the CSRF-cookie code path. This is what we're using as a workaround, but it requires bypassing the web UI entirely for these actions.

Related

• #8704 - same symptom ("X-Authentik-Csrf header is empty"), 2023.10/2024.2, closed as bug
• #10479 - same exact error text, 2024.6.1, different flow (WebAuthn setup), closed as wontfix

Given this keeps recurring across ~3 years of releases and multiple unrelated flows, it seems like a persistent fragility in how the frontend reads/mirrors the CSRF cookie into that header, rather than an environment-specific misconfiguration. Happy to provide more diagnostics if useful (HAR capture, etc.).

How to reproduce

Reproduced with a completely fresh browser session (ruling out stale cookies/session) on all of the following, each performed while authenticated via a normal cookie/session (not API token):

1. Self-service password change: /if/user/ -> Update your password -> Change password -> submit new password. Flow executor POST to /api/v3/flows/executor/default-password-change/ returns HTTP 200 with {"component": "ak-stage-flow-error", "request_id": "..."}.
2. Admin "Set password" on another user's detail page in /if/admin/.
3. Creating a new API token via /if/user/#/settings;{"page":"page-tokens"} -> New Token -> fill in identifier -> Create Token -> "There was an error submitting the form. Response returned an error code."

All three fail the same way, in the same session, for the same user.

Expected behavior

The frontend should send a correctly-formatted X-Authentik-Csrf header (mirroring the authentik_csrf cookie), and these standard account-management actions (changing your own password, an admin setting another user's password, creating an API token) should succeed instead of failing with a CSRF error.

Screenshots

No response

Additional context

No response

Deployment Method

Docker

Version

2026.2.7 (also reproduced on 2026.2.2)

Relevant log output

{"event": "PermissionDenied(\"CSRF Failed: CSRF token from the 'X-Authentik-Csrf' HTTP header has incorrect length.\")", "flow_slug": "default-password-change", "logger": "authentik.flows.views.executor", "level": "warning", "auth_via": "session"}