CVE-2025-53942

Executive Summary

CVE-2025-53942 is an authentication bypass vulnerability in authentik, an open-source Identity Provider. The flaw allows deactivated users who registered or linked their accounts via OAuth/SAML to retain partial system access. While these users cannot access the API, they can still authorize applications if they know the application URL. This creates a significant security gap where deactivated accounts can still interact with connected services. The vulnerability affects versions 2025.4.4 and earlier, as well as versions 2025.6.0-rc1 through 2025.6.3. The fix is available in versions 2025.4.4 and 2025.6.4.

Supply Chain & Package Security

This vulnerability affects the authentik Docker images and Python packages. Organizations using authentik should verify their deployment version and update immediately. The fix requires updating to the patched versions or applying the workaround expression policy.

CVSS Breakdown & Threat Level

• CVSS Score: 0.0 (No official CVSS vector provided)
• Attack Vector: Network
• Attack Complexity: Low
• Privileges Required: Low (requires a deactivated user account)
• User Interaction: None
• Scope: Changed
• Confidentiality Impact: Low
• Integrity Impact: Low
• Availability Impact: None
• Threat Level: Medium (due to partial access and application authorization capability)

Deep Dive & Mechanics

The vulnerability stems from how authentik handles deactivated user sessions in OAuth/SAML flows. When a user is deactivated, the system correctly blocks API access but fails to fully invalidate the user's authorization grants for applications. The authentication flow does not check the is_active flag on the pending user object before completing the authorization process.

The attack flow:

1. An attacker gains access to a deactivated user account (e.g., through credential reuse or social engineering)
2. The attacker knows the URL of an application configured in authentik
3. The attacker initiates an OAuth/SAML authorization flow for that application
4. The system authenticates the user (since the user still exists in the database) but does not check if the user is active
5. The authorization grant is issued, allowing the attacker to access the application

The root cause is in the user login stage where the is_active check is missing. The fix adds an expression policy that explicitly checks request.context["pending_user"].is_active before allowing the login to proceed.

Vulnerable vs. Patched Code

Vulnerable Code (User Login Stage):

# No check for is_active
def login_stage(request):
    user = request.context["pending_user"]
    # Proceeds with login without checking if user is active
    return complete_login(user)

Patched Code (User Login Stage with Expression Policy):

# Expression policy added to the user login stage
def check_active_policy(request):
    return request.context["pending_user"].is_active

# Updated login stage
def login_stage(request):
    if not check_active_policy(request):
        return deny_login("User is deactivated")
    user = request.context["pending_user"]
    return complete_login(user)

Exploitation & Lab Setup

Red Team

Prerequisites:

• Access to a deactivated user account in authentik
• Knowledge of an application URL configured in authentik
• Network access to the authentik instance

Exploitation Steps:

1. Identify a deactivated user account (e.g., through reconnaissance or credential stuffing)
2. Obtain the application URL (e.g., https://app.example.com/oauth/callback)
3. Initiate an OAuth authorization flow:

   GET /application/o/authorize/?client_id=APP_CLIENT_ID&redirect_uri=https://app.example.com/oauth/callback&response_type=code&scope=openid
   

4. Authenticate with the deactivated user credentials
5. The system will issue an authorization code despite the user being deactivated
6. Exchange the authorization code for an access token:

   POST /application/o/token/
   Content-Type: application/x-www-form-urlencoded
   
   grant_type=authorization_code&code=AUTH_CODE&redirect_uri=https://app.example.com/oauth/callback&client_id=APP_CLIENT_ID
   

7. Use the access token to access the application

Blue Team

Detection Steps:

1. Monitor for authentication events from deactivated users
2. Check authentik logs for successful logins from accounts marked as inactive
3. Review OAuth authorization grants for deactivated users
4. Implement the workaround expression policy immediately
5. Audit all application authorizations for deactivated users

Lab Setup:

1. Deploy authentik 2025.4.3 in a Docker environment
2. Create a test user and register via OAuth
3. Deactivate the user account
4. Attempt to authorize an application using the deactivated user
5. Verify the vulnerability
6. Apply the patch or workaround
7. Verify the fix

Indicators of Compromise (IOCs)

• Log Entries: Successful OAuth authorization flows for deactivated users
• Authentication Events: Login events from accounts with is_active=False
• Application Access: Unexpected access to applications by deactivated users
• Network Traffic: OAuth token exchange requests from deactivated users

Detection Engineering

YARA Rule

rule Detect_Authentik_Deactivated_User_Access {
    meta:
        description = "Detects authentik logs showing deactivated user access"
        author = "Valters IT"
        date = "2025-04-10"
        reference = "CVE-2025-53942"
    strings:
        $log1 = "user_login" ascii nocase
        $log2 = "is_active" ascii nocase
        $log3 = "False" ascii nocase
        $log4 = "authorize" ascii nocase
    condition:
        all of ($log1, $log2, $log3) or ($log1 and $log4)
}

Sigma Rule

title: Authentik Deactivated User Authentication Bypass
id: a1b2c3d4-e5f6-7890-abcd-ef1234567890
status: experimental
description: Detects successful authentik logins from deactivated users
author: Valters IT
date: 2025-04-10
references:
    - https://nvd.nist.gov/vuln/detail/CVE-2025-53942
logsource:
    product: authentik
    service: audit
detection:
    selection:
        event_type: "user_login"
        user_is_active: false
        result: "success"
    condition: selection
falsepositives:
    - Legitimate reactivation of accounts
level: high

Suricata Rule

alert http $HOME_NET any -> $EXTERNAL_NET any (
    msg:"CVE-2025-53942 - Authentik Deactivated User OAuth Authorization";
    flow:to_server,established;
    content:"/application/o/authorize/"; http_uri;
    content:"client_id="; http_uri;
    content:"redirect_uri="; http_uri;
    content:"response_type=code"; http_uri;
    sid:1000001;
    rev:1;
    reference:cve,2025-53942;
    classtype:attempted-user;
    priority:2;
)

Remediation & Mitigation

Immediate Actions:

1. Update authentik to version 2025.4.4 or 2025.6.4
2. If immediate update is not possible, apply the workaround expression policy:
   • Add an expression policy to the user login stage
   • Use the expression: return request.context["pending_user"].is_active
3. Audit all deactivated user accounts and revoke any existing OAuth/SAML authorizations
4. Review authentication logs for signs of exploitation

Long-term Measures:

1. Implement automated monitoring for deactivated user access attempts
2. Regularly audit user accounts and their authorization grants
3. Enable multi-factor authentication for all users
4. Implement session revocation for deactivated accounts
5. Consider implementing automatic session termination for deactivated users

Workaround Details: The workaround involves adding an expression policy to the user login stage on the respective authentication flow. This policy checks the is_active flag of the pending user and denies login if the user is deactivated.

Valters IT