CVE-2025-29928 - Unrevoked Session Bug in Authentik Exposes Open Sessions Even After Deletion
Published: June 2024 <br>Severity: High <br>Product: authentik (Open-source Identity Provider) <br>Affected Versions: Before 2024.12.4 and 2025.2.3
What Is CVE-2025-29928?
CVE-2025-29928 is a newly disclosed vulnerability affecting the open-source SSO identity provider authentik. If your authentik instance is configured to use the database session storage (this is not the default, but a sometimes-used customization), sessions deleted via the web dashboard or API would *not* truly be revoked. The user holding that session could still access protected resources—even though admins thought they had revoked that access.
The issue is fixed in authentik v2024.12.4 and v2025.2.3.
Who is vulnerable?
Anyone using authentik with database-backed sessions and a version earlier than 2024.12.4 / 2025.2.3.
What happens?
Admins delete a session via the UI/API, but the user can carry on as if nothing happened, keeping access with their old session.
How is it fixed?
New authentik releases fix the logic. Also, using cache-based session storage mitigates the issue until you upgrade.
Why Does This Happen?
The way authentik handles sessions depends on your configuration. If your SESSION_ENGINE is set to use the database (for example, using "django.contrib.sessions.backends.db"), deleting the session didn't actually invalidate the user's session cookie properly.
Let's look at what this might look like in a typical Django session model
# settings.py
SESSION_ENGINE = "django.contrib.sessions.backends.db" # Vulnerable configuration
# Instead, use:
# SESSION_ENGINE = "django.contrib.sessions.backends.cache" # Safe workaround
When you, the admin, delete a session using an API call or through the management UI, the backend is supposed to remove that session by ID. However, because of a logic flaw, the session data wasn't always removed, so users' browsers would continue to pass a valid session cookie and stay signed in.
Result: Access persists even after you think it’s revoked.
Via authentik API, using httpie
http DELETE https://AUTHENTIK_URL/api/v3/sessions/{session_id}/ 'Authorization: Bearer'
`
3. User reloads a protected app—and still gets in! Their session cookie is valid, because the backend still treats their cookie as known.
You can check your SESSION_ENGINE by running
docker exec -it authentik cat /path/to/settings.py | grep SESSION_ENGINE
Or in your configuration environment
echo $SESSION_ENGINE
Workarounds and Fix
Step 1: Upgrade authentik
First and best: Upgrade to 2024.12.4 or 2025.2.3 now.
Switch to cache-based sessions. In your settings.py
SESSION_ENGINE = "django.contrib.sessions.backends.cache"
Reference Links
- Official Authentik CVE-2025-29928 Advisory
- Authentik Release Notes
- Django Session Backend Options
Should You Be Worried?
If you rely on session revocation for security—or if your deployment uses DB-based sessions and your users should lose access *immediately* when an admin revokes their session—you should act fast. This bug essentially lets unwanted users stay in your service, potentially with privileged access, after you tried to revoke them.
Conclusion
CVE-2025-29928 shows how a small misstep in session management can lead to a big security issue. If your authentik deployment relies on DB-backed sessions, check your version, update quickly, and make sure your session storage settings align with best practices. If immediate upgrading isn’t possible, switch to cache-based sessions as a short-term fix.
Stay safe, and always validate session revocation in your auth tools!
Further Reading
- Session Management and Security - OWASP
- Authentik Documentation
Author: [Your Name]
Date: June 2024
*This post is original and exclusive to this request. Please cite with link if sharing.*
Timeline
Published on: 03/28/2025 15:15:49 UTC
Last modified on: 03/28/2025 18:11:40 UTC