Identity

CVE-2025-29928: authentik Session Revocation Vulnerability

David Wilson

David Wilson

— 8 min read

Executive Summary

CVE-2025-29928 describes a critical vulnerability in authentik, an open-source identity provider. When authentik is configured to use database session storage (a non-default configuration), deleting user sessions through the web interface or API does not effectively revoke those sessions. Consequently, users whose sessions should have been terminated retain unauthorized access to authentik. This issue is resolved in authentik versions 2024.12.4 and 2025.2.3. A temporary workaround involves switching to cache-based session storage, which will force all users to re-authenticate. The vulnerability has a CVSS v3.1 score of 8.0, indicating a High severity.

Technical Details

The vulnerability affects authentik instances configured to use the database for session storage. This is not the default configuration; authentik typically uses a cache-based session store. The affected versions are:

  • Versions prior to 2024.12.4
  • Versions prior to 2025.2.3

The core issue lies in the failure to properly invalidate database-stored session records when a session deletion request is initiated, either through the administrative web interface or via the API. This means that even after a session is "deleted," the corresponding session data remains in the database, allowing the user to continue using the existing session ID to access the application. This also impacts automatic session deletion when a user is deactivated or deleted.

The affected component is the session management system within authentik, specifically the parts responsible for handling session deletion when the database backend is in use.

Root Cause Analysis

The root cause of CVE-2025-29928 is the incorrect implementation of the session deletion mechanism when using the database session store. Instead of directly deleting the session record from the database, the original code was attempting to delete the session from the cache, even when the database was the active session store. This meant that the session remained valid in the database, allowing continued access.

The fix, as seen in the provided patch, involves directly deleting the session from the database using the Django session framework's built-in SessionStore class. This ensures that the session is properly invalidated and cannot be reused.

The original code in authentik/core/api/users.py looked like this:

sessions = AuthenticatedSession.objects.filter(user=instance)
session_ids = sessions.values_list("session_key", flat=True)
cache.delete_many(f"{KEY_PREFIX}{session}" for session in session_ids)
sessions.delete()

This code retrieves all authenticated sessions for a given user, constructs cache keys based on the session IDs, and attempts to delete those keys from the cache. Critically, this only affects the cache and not the database, which is where the session data resides when database session storage is enabled. The sessions.delete() call only deletes the AuthenticatedSession objects, which are separate from the actual session data.

The corrected code in authentik/core/api/users.py is:

sessions = AuthenticatedSession.objects.filter(user=instance)
session_ids = sessions.values_list("session_key", flat=True)
for session in session_ids:
    SessionStore(session).delete()
sessions.delete()

This code iterates through the session IDs and uses the SessionStore class to directly delete each session from the database. This ensures that the session is properly invalidated. The sessions.delete() call still deletes the AuthenticatedSession objects.

A similar issue existed in authentik/core/signals.py, where the authenticated_session_delete signal handler was attempting to delete sessions from the cache instead of the database.

The original code in authentik/core/signals.py looked like this:

@receiver(pre_delete, sender=AuthenticatedSession)
def authenticated_session_delete(sender: type[Model], instance: "AuthenticatedSession", **_):
    """Delete session when authenticated session is deleted"""
    cache_key = f"{KEY_PREFIX}{instance.session_key}"
    cache.delete(cache_key)

The corrected code in authentik/core/signals.py is:

@receiver(pre_delete, sender=AuthenticatedSession)
def authenticated_session_delete(sender: type[Model], instance: "AuthenticatedSession", **_):
    """Delete session when authenticated session is deleted"""
    SessionStore(instance.session_key).delete()

This code directly deletes the session from the database using the SessionStore class.

Patch Analysis

The patch addresses the vulnerability by ensuring that session data is correctly deleted from the database when a session is revoked. The key changes involve using Django's SessionStore class to directly interact with the session backend (in this case, the database) and delete the session record.

The patch consists of changes to two files: authentik/core/api/users.py and authentik/core/signals.py.

File: authentik/core/api/users.py

--- a/authentik/core/api/users.py
+++ b/authentik/core/api/users.py
@@ -1,13 +1,14 @@
 """User API Views"""

 from datetime import timedelta
+from importlib import import_module
 from json import loads
 from typing import Any

+from django.conf import settings
 from django.contrib.auth import update_session_auth_hash
 from django.contrib.auth.models import Permission
-from django.contrib.sessions.backends.cache import KEY_PREFIX
-from django.core.cache import cache
+from django.contrib.sessions.backends.base import SessionBase
 from django.db.models.functions import ExtractHour
 from django.db.transaction import atomic
 from django.db.utils import IntegrityError
@@ -91,6 +92,7 @@
 from authentik.stages.email.utils import TemplateEmailMessage

 LOGGER = get_logger()
+SessionStore: SessionBase = import_module(settings.SESSION_ENGINE).SessionStore


 class UserGroupSerializer(ModelSerializer):
@@ -774,7 +776,8 @@
         if not instance.is_active:
             sessions = AuthenticatedSession.objects.filter(user=instance)
             session_ids = sessions.values_list("session_key", flat=True)
-            cache.delete_many(f"{KEY_PREFIX}{session}" for session in session_ids)
+            for session in session_ids:
+                SessionStore(session).delete()
             sessions.delete()
             LOGGER.debug("Deleted user's sessions", user=instance.username)
         return response
  • +from importlib import import_module: Imports the import_module function, which is used to dynamically load the session engine specified in the Django settings.
  • +from django.conf import settings: Imports the Django settings module, which contains configuration parameters for the application, including the session engine.
  • -from django.contrib.sessions.backends.cache import KEY_PREFIX: Removes the import of KEY_PREFIX from the cache backend, as it's no longer needed.
  • -from django.core.cache import cache: Removes the import of the cache object, as the cache is no longer directly manipulated.
  • +from django.contrib.sessions.backends.base import SessionBase: Imports the SessionBase class, which is the base class for all session stores in Django.
  • +SessionStore: SessionBase = import_module(settings.SESSION_ENGINE).SessionStore: Dynamically imports the session store class specified in the settings.SESSION_ENGINE setting. This allows the code to work with different session backends without requiring hardcoded dependencies. The SessionStore variable is then assigned the imported class.
  • -cache.delete_many(f"{KEY_PREFIX}{session}" for session in session_ids): This line was attempting to delete sessions from the cache, which is incorrect when using database-backed sessions.
  • +for session in session_ids:: This loop iterates through the session IDs.
  • +SessionStore(session).delete(): For each session ID, a SessionStore object is instantiated with the session ID, and the delete() method is called. This directly deletes the session from the database.

File: authentik/core/signals.py

--- a/authentik/core/signals.py
+++ b/authentik/core/signals.py
@@ -1,7 +1,10 @@
 """authentik core signals"""

+from importlib import import_module
+
+from django.conf import settings
 from django.contrib.auth.signals import user_logged_in, user_logged_out
-from django.contrib.sessions.backends.cache import KEY_PREFIX
+from django.contrib.sessions.backends.base import SessionBase
 from django.core.cache import cache
 from django.core.signals import Signal
 from django.db.models import Model
@@ -25,6 +28,7 @@
 login_failed = Signal()

 LOGGER = get_logger()
+SessionStore: SessionBase = import_module(settings.SESSION_ENGINE).SessionStore


 @receiver(post_save, sender=Application)
@@ -60,8 +64,7 @@
 @receiver(pre_delete, sender=AuthenticatedSession)
 def authenticated_session_delete(sender: type[Model], instance: "AuthenticatedSession", **_):
     """Delete session when authenticated session is deleted"""
-    cache_key = f"{KEY_PREFIX}{instance.session_key}"
-    cache.delete(cache_key)
+    SessionStore(instance.session_key).delete()


 @receiver(pre_save)
  • +from importlib import import_module: Imports the import_module function, which is used to dynamically load the session engine specified in the Django settings.
  • +from django.conf import settings: Imports the Django settings module, which contains configuration parameters for the application, including the session engine.
  • -from django.contrib.sessions.backends.cache import KEY_PREFIX: Removes the import of KEY_PREFIX from the cache backend, as it's no longer needed.
  • +from django.contrib.sessions.backends.base import SessionBase: Imports the SessionBase class, which is the base class for all session stores in Django.
  • +SessionStore: SessionBase = import_module(settings.SESSION_ENGINE).SessionStore: Dynamically imports the session store class specified in the settings.SESSION_ENGINE setting. This allows the code to work with different session backends without requiring hardcoded dependencies. The SessionStore variable is then assigned the imported class.
  • -cache_key = f"{KEY_PREFIX}{instance.session_key}": This line was constructing a cache key.
  • -cache.delete(cache_key): This line was attempting to delete the session from the cache, which is incorrect when using database-backed sessions.
  • +SessionStore(instance.session_key).delete(): This line instantiates a SessionStore object with the session ID and calls the delete() method, directly deleting the session from the database.

In summary, the patch replaces the incorrect cache-based session deletion with a direct database-based session deletion using Django's SessionStore class. This ensures that sessions are properly invalidated when they are deleted through the web interface, API, or when a user is deactivated or deleted. The dynamic import of the SessionStore based on the settings.SESSION_ENGINE ensures that the code works correctly regardless of the configured session backend.

Exploitation Techniques

An attacker can exploit this vulnerability if the authentik instance is configured to use database session storage. The attacker would need to obtain a valid session ID, which could be achieved through various means such as:

  1. Session Hijacking: Intercepting the session cookie of a legitimate user.
  2. Brute-forcing: Attempting to guess valid session IDs (though this is less likely to succeed due to the length and complexity of session IDs).
  3. Social Engineering: Tricking a user into revealing their session ID.

Once the attacker has a valid session ID, they can authenticate to the authentik instance. Even if an administrator subsequently deletes the session through the authentik web interface or API, the attacker's session will remain active because the session data is not properly removed from the database. The attacker can then continue to access authentik with the hijacked session.

Attack Scenario:

  1. An attacker observes a legitimate user logging into authentik.
  2. The attacker intercepts the user's session cookie (e.g., using a packet sniffer or a man-in-the-middle attack).
  3. The attacker configures their browser to use the intercepted session cookie.
  4. The attacker successfully authenticates to authentik using the hijacked session.
  5. An administrator notices the unauthorized access and deletes the user's session through the authentik web interface.
  6. However, the attacker's session remains active because the session data is not properly removed from the database.
  7. The attacker continues to access authentik with the hijacked session, potentially gaining access to sensitive information or performing unauthorized actions.

Proof of Concept (Made-up):

This PoC demonstrates how an attacker can maintain a valid session even after it has been "deleted" by an administrator. This PoC assumes you have a running authentik instance configured to use database session storage.

import requests
import time

# Replace with the URL of your authentik instance
AUTHENTIK_URL = "https://your-authentik-instance.com"

# Replace with a valid session ID obtained through hijacking or other means
SESSION_ID = "valid_session_id"

# Create a session object with the hijacked session ID
session = requests.Session()
session.cookies.set("sessionid", SESSION_ID, domain=".your-authentik-instance.com") # Adjust domain as needed

# Verify that the session is initially valid
response = session.get(f"{AUTHENTIK_URL}/api/v3/users/me/")
if response.status_code == 200:
    print("[+] Session is initially valid.")
    user_data = response.json()
    print(f"[+] Logged in as user: {user_data['username']}")
else:
    print("[-] Session is invalid. Check the SESSION_ID.")
    exit()

# Simulate an administrator deleting the session (this would normally be done through the authentik UI or API)
print("[+] Simulating administrator deleting the session...")
# In a real attack, the attacker wouldn't know when the session is deleted.
# We'll just wait for a few seconds to simulate the administrator's action.
time.sleep(5)

# Attempt to access a protected resource again
response = session.get(f"{AUTHENTIK_URL}/api/v3/users/me/")
if response.status_code == 200:
    print("[+] Session is still valid after deletion!")
    user_data = response.json()
    print(f"[+] Still logged in as user: {user_data['username']}")
    print("[+] Vulnerability successfully exploited!")
else:
    print("[-] Session is no longer valid. This should not happen if the vulnerability is present.")

Disclaimer: This PoC is for educational purposes only. Do not use it to attack systems without authorization. This PoC is made-up and may need adjustments to work in a real environment.

Mitigation Strategies

To mitigate CVE-2025-29928, the following steps are recommended:

  1. Upgrade authentik: Upgrade to authentik version 2024.12.4 or 2025.2.3 or later. These versions contain the fix for the vulnerability.

  2. Switch to cache-based session storage (temporary workaround): As a temporary workaround, switch to cache-based session storage. This will force all users to re-authenticate, but it will prevent the vulnerability from being exploited. To switch to cache-based session storage, modify the SESSION_ENGINE setting in your settings.py file:

    SESSION_ENGINE = 'django.contrib.sessions.backends.cache'

    Important: This will delete all existing sessions.

  3. Regularly review and revoke sessions: Regularly review active sessions and revoke any suspicious or unauthorized sessions.

  4. Implement strong session management practices:

    • Use strong, randomly generated session IDs.
    • Implement session timeouts to automatically expire inactive sessions.
    • Rotate session IDs regularly.
    • Use secure cookies (HTTPS only) to protect session IDs from interception.

  5. Monitor for suspicious activity: Monitor authentik logs for suspicious activity, such as multiple login attempts from the same IP address or access to sensitive resources outside of normal business hours.

Timeline of Discovery and Disclosure

  • 2025-03-12: Vulnerability reported.
  • 2025-03-28: Patches released in authentik versions 2024.12.4 and 2025.2.3.
  • 2025-03-28: CVE-2025-29928 publicly disclosed.

References

Read more