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

CVE-2024-52287

CVE-2024-52287 Supply Chain Attack in Authentik
📅 PUBLISHED: 2024-11-21 17:23 UTC 🔄 UPDATED: 2026-09-23 20:27 UTC
[ OFFICIAL PATCH DEPLOYED ↓ ] FIX: LIKELY — 2 independent sources confirm 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.4× above the median CVE
Tier: ELEVATED
30-day exploitation window · FIRST.org · updated daily
Country: Germany License: Open Source
Patch available — upgrade to latest release
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
6.4
THREAT LEVEL
■ tracking this CVE ✓ independent patch confirmation ⧗ same-origin mirror (GHSA) ⚠ active exploitation verification policy →

Executive Summary

CVE-2024-52287 is a vulnerability in authentik, an open-source identity provider. The flaw allows an attacker to obtain OAuth tokens with scopes that were not configured or authorized for the client application when using the client_credentials or device_code OAuth 2.0 grant types. This effectively bypasses the intended scope restrictions, potentially granting elevated privileges or access to resources beyond what the client should have. The vulnerability has been patched in versions 2024.8.5 and 2024.10.3.

⚡ 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

authentik is distributed as a Docker container and via source code on GitHub. The vulnerability affects the core OAuth 2.0 authorization server logic. Users should ensure they are using a patched version of the container image or source code. There are no known supply chain attacks related to this CVE, but the risk of scope escalation could be exploited in a compromised environment.

CVSS Breakdown & Threat Level

The CVSS score is listed as 0.0, which is likely a placeholder. Based on the vulnerability description, a reasonable assessment would be:

  • Attack Vector (AV): Network (N) – The attack is performed over the network.
  • Attack Complexity (AC): Low (L) – No special conditions are required.
  • Privileges Required (PR): Low (L) – The attacker needs to have a valid client ID and secret for a client configured to use client_credentials or device_code grants.
  • User Interaction (UI): None (N) – No user interaction is required.
  • Scope (S): Changed (C) – The attacker can obtain tokens with scopes beyond the client's intended permissions.
  • Confidentiality (C): High (H) – Unauthorized access to sensitive data.
  • Integrity (I): High (H) – Unauthorized modification of data.
  • Availability (A): Low (L) – Potential for denial of service if scopes allow resource exhaustion.

Estimated CVSS Vector: CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:C/C:H/I:H/A:L

Threat Level: High. The vulnerability allows privilege escalation via scope manipulation, which can lead to data breaches and unauthorized actions.

Deep Dive & Mechanics

The vulnerability lies in the OAuth 2.0 authorization server's handling of the client_credentials and device_code grant types. In these flows, the client authenticates directly (using its client ID and secret) and requests a token with specific scopes. The server is supposed to validate that the requested scopes are within the set of scopes configured for that client. However, due to a flaw in the scope validation logic, the server may issue a token with scopes that were not explicitly allowed.

Root Cause: The scope validation function likely fails to properly compare the requested scopes against the allowed scopes for the client. This could be due to:

  • Incorrect string comparison (e.g., case sensitivity issues).
  • Missing validation for certain grant types.
  • Logic errors in the scope intersection algorithm.

Attack Scenario:

  1. An attacker obtains the client ID and secret for a legitimate client application (e.g., via a data breach or misconfiguration).
  2. The attacker initiates a client_credentials or device_code grant request to the authentik token endpoint.
  3. The attacker includes scopes in the request that are not configured for that client (e.g., admin, read_all, write_all).
  4. The vulnerable server processes the request and returns an access token with the requested scopes.
  5. The attacker uses this token to access protected resources with elevated privileges.

Vulnerable vs. Patched Code

The exact code changes are not publicly available, but the fix likely involves correcting the scope validation logic. A typical vulnerable implementation might look like:

# Vulnerable code (pseudocode)
def issue_token(client_id, client_secret, requested_scopes):
    client = get_client(client_id, client_secret)
    # Missing or incorrect scope validation
    token = create_token(client_id, requested_scopes)
    return token

The patched version would include proper scope validation:

# Patched code (pseudocode)
def issue_token(client_id, client_secret, requested_scopes):
    client = get_client(client_id, client_secret)
    allowed_scopes = client.get_allowed_scopes()
    # Validate that requested scopes are a subset of allowed scopes
    if not requested_scopes.issubset(allowed_scopes):
        raise InvalidScopeError("Requested scopes not allowed")
    token = create_token(client_id, requested_scopes)
    return token

Exploitation & Lab Setup

Red Team

Prerequisites:

  • A vulnerable authentik instance (version < 2024.8.5 or < 2024.10.3).
  • A client configured with client_credentials or device_code grant type.
  • The client ID and client secret.

Exploitation Steps:

  1. Obtain the client ID and secret (e.g., from a compromised configuration file).
  2. Send a POST request to the token endpoint with the client_credentials grant type and elevated scopes.
curl -X POST https://authentik.example.com/application/o/token/ \
  -d "grant_type=client_credentials" \
  -d "client_id=YOUR_CLIENT_ID" \
  -d "client_secret=YOUR_CLIENT_SECRET" \
  -d "scope=admin read_all write_all"
  1. The server will return an access token with the requested scopes.
{
  "access_token": "eyJhbGciOiJSUzI1NiIs...",
  "token_type": "Bearer",
  "expires_in": 3600,
  "scope": "admin read_all write_all"
}
  1. Use the token to access protected resources.
curl -H "Authorization: Bearer eyJhbGciOiJSUzI1NiIs..." \
  https://authentik.example.com/api/v3/core/users/

Blue Team

Detection:

  • Monitor for OAuth token requests with unusual or elevated scopes.
  • Alert on client_credentials or device_code grant requests where the requested scopes do not match the client's configured scopes.
  • Review logs for failed scope validation attempts (if logging is enabled).

Hunting:

  • Search for tokens issued with scopes like admin, *, or other high-privilege scopes.
  • Correlate token issuance events with client IDs that should not have those scopes.

Mitigation:

  • Immediately upgrade to authentik 2024.8.5 or 2024.10.3.
  • Review all client configurations and ensure scopes are properly restricted.
  • Rotate client secrets for any potentially affected clients.
  • Audit token usage for signs of abuse.

Indicators of Compromise (IOCs)

  • Network:

    • POST requests to /application/o/token/ with grant_type=client_credentials or grant_type=urn:ietf:params:oauth:grant-type:device_code and unusual scopes.
    • Subsequent API calls using tokens with elevated scopes (e.g., admin, read_all).
  • Logs:

    • authentik audit logs showing token issuance with scopes not matching the client's allowed scopes.
    • Failed scope validation errors (if patched).
  • Tokens:

    • JWT tokens with claims containing scopes like admin, *, or other high-privilege values.

Detection Engineering

YARA Rule

rule Detect_OAuth_Scope_Escalation_Attempt {
    meta:
        description = "Detects OAuth token requests with potentially elevated scopes"
        author = "Valters IT"
        date = "2024-12-01"
        reference = "CVE-2024-52287"
    strings:
        $grant_type_client = "grant_type=client_credentials"
        $grant_type_device = "grant_type=urn:ietf:params:oauth:grant-type:device_code"
        $scope_admin = "scope=admin"
        $scope_all = "scope=*"
        $scope_read_all = "scope=read_all"
        $scope_write_all = "scope=write_all"
    condition:
        ($grant_type_client or $grant_type_device) and
        ($scope_admin or $scope_all or $scope_read_all or $scope_write_all)
}

Sigma Rule

title: OAuth Scope Escalation Attempt
id: 8a9b7c6d-5e4f-3a2b-1c0d-9e8f7a6b5c4d
status: experimental
description: Detects OAuth token requests with elevated scopes for client_credentials or device_code grants
author: Valters IT
date: 2024-12-01
references:
    - https://nvd.nist.gov/vuln/detail/CVE-2024-52287
logsource:
    category: web
    product: authentik
detection:
    selection:
        http.method: POST
        http.url: "/application/o/token/"
        http.body|contains:
            - "grant_type=client_credentials"
            - "grant_type=urn:ietf:params:oauth:grant-type:device_code"
        http.body|contains|any:
            - "scope=admin"
            - "scope=*"
            - "scope=read_all"
            - "scope=write_all"
    condition: selection
falsepositives:
    - Legitimate administrative clients with proper configuration
level: high

Suricata Rule

alert http $HOME_NET any -> $EXTERNAL_NET any (
    msg:"CVE-2024-52287 - OAuth Scope Escalation Attempt";
    flow:to_server;
    http.method;
    content:"POST";
    http.uri;
    content:"/application/o/token/";
    http.client_body;
    content:"grant_type=client_credentials";
    content:"scope=";
    pcre:"/scope=(admin|\*|read_all|write_all)/Ri";
    classtype:attempted-admin;
    sid:1000001;
    rev:1;
)

Remediation & Mitigation

Immediate Actions:

  1. Upgrade authentik to version 2024.8.5 or 2024.10.3.
  2. If upgrade is not possible, disable the client_credentials and device_code grant types for all clients until patched.
  3. Review and restrict client scopes to the minimum necessary.

Long-term Measures:

  • Implement strict scope validation in custom OAuth implementations.
  • Regularly audit OAuth client configurations and token usage.
  • Enable logging for all OAuth token requests and monitor for anomalies.
  • Use automated tools to scan for known vulnerabilities in identity providers.

Valters IT – This report is provided for educational and defensive purposes. Unauthorized exploitation of this vulnerability is illegal. Always ensure you have proper authorization before testing any systems.

◈ SOURCE Analysis & enrichment: valtersit.com/cve/CVE-2024-52287/ · 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.