CVE-2025-30373

Executive Summary

CVE-2025-30373 is a critical authentication bypass vulnerability in Graylog, an open-source log management platform. The flaw affects HTTP Inputs configured with header-based authentication (introduced in version 6.1). Even when a missing or incorrect authentication header triggers a 401 HTTP response, the log message is still ingested and stored. This allows an unauthenticated attacker to inject arbitrary log data into the system, bypassing the intended security controls. The vulnerability has a CVSS score of 6.5 (Medium) and is fixed in Graylog 6.1.9. No public proof-of-concept (PoC) or exploit code is currently available, but the risk is significant for organizations relying on HTTP Inputs for log ingestion.

Supply Chain & Package Security

Graylog is a Java-based application distributed via official packages (DEB, RPM, TAR.GZ) and Docker images. The vulnerability is in the core application code, not in a third-party library. However, organizations using Graylog should verify the integrity of their installation and ensure they are not running a compromised version. The patch is available in the official Graylog repository and Docker Hub.

CVSS Breakdown & Threat Level

• CVSS Score: 6.5 (Medium)
• Vector: CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:L/A:L
• Attack Vector: Network (AV:N) – The vulnerability can be exploited remotely.
• Attack Complexity: Low (AC:L) – No special conditions are required.
• Privileges Required: None (PR:N) – No authentication is needed.
• User Interaction: None (UI:N) – No user action is required.
• Scope: Unchanged (S:U) – The exploit does not affect other components.
• Confidentiality Impact: None (C:N) – No data is exposed.
• Integrity Impact: Low (I:L) – An attacker can inject false log data.
• Availability Impact: Low (A:L) – An attacker could potentially fill storage with junk logs, leading to denial of service.

Threat Level: Medium. While the CVSS score is moderate, the ability to inject arbitrary log data can severely compromise log integrity, hinder forensic investigations, and potentially be used to mask other malicious activities.

Deep Dive & Mechanics

The vulnerability lies in the HTTP Input authentication mechanism introduced in Graylog 6.1. When an HTTP Input is configured to require a specific header (e.g., X-Graylog-Auth-Token) with a specific value, the system performs the following steps:

1. Receive HTTP Request: The HTTP Input receives a POST request with log data.
2. Check Header: The system checks for the presence and correctness of the configured authentication header.
3. Return 401 (if invalid): If the header is missing or incorrect, the system returns a 401 Unauthorized HTTP response.
4. Ingest Message (BUG): Despite returning the 401, the system still processes and stores the log message from the request body.

This means an attacker can send a request without the required header, receive a 401 response, but the log data will still be ingested. The attacker does not need to see the 401 response; they simply need to send the request.

Root Cause: The code that handles the HTTP response (returning 401) is executed after the message has already been accepted and queued for processing. The authentication check does not abort the ingestion pipeline.

Vulnerable vs. Patched Code

The fix in Graylog 6.1.9 ensures that the authentication check occurs before the message is accepted. The vulnerable code path likely looked like this (pseudocode):

// Vulnerable (6.1.0 - 6.1.8)
public void handleRequest(HttpRequest request) {
    if (!isAuthenticated(request)) {
        sendResponse(401, "Unauthorized");
        // BUG: Message is still ingested
    }
    ingestMessage(request.getBody());
}

The patched version reverses the logic:

// Patched (6.1.9)
public void handleRequest(HttpRequest request) {
    if (!isAuthenticated(request)) {
        sendResponse(401, "Unauthorized");
        return; // Stop processing
    }
    ingestMessage(request.getBody());
}

The patch is minimal and only adds a return statement (or equivalent) to prevent the message from being ingested after a failed authentication check.

Exploitation & Lab Setup

Red Team (Attack Simulation)

Prerequisites:

• A Graylog instance (version 6.1.0 to 6.1.8) with an HTTP Input configured for header-based authentication.
• Network access to the Graylog HTTP Input endpoint.

Exploitation Steps:

1. Identify the HTTP Input endpoint. This is typically a URL like http://<graylog-ip>:<port>/gelf or a custom path.

2. Send a malicious log message without the required authentication header. Use curl or any HTTP client.

   curl -X POST http://<graylog-ip>:<port>/gelf \
     -H "Content-Type: application/json" \
     -d '{"version":"1.1","host":"attacker","short_message":"Test injection","_malicious":"true"}'
   

3. Observe the response. The server will return a 401 Unauthorized, but the message will be ingested.

4. Verify in Graylog. Search for the injected message in the Graylog web interface.

Advanced Exploitation:

• Log Injection: Inject false log entries to mislead security teams or cover tracks.
• Storage Exhaustion: Send a large volume of junk logs to fill up disk space, causing a denial of service.
• Data Exfiltration (Indirect): If the log data is forwarded to another system (e.g., SIEM), the attacker can inject data that triggers alerts or corrupts analytics.

Blue Team (Defense & Detection)

Detection Steps:

1. Monitor HTTP Input Logs: Check Graylog's own logs for repeated 401 responses from the same source IP. This is a strong indicator of exploitation attempts.
2. Analyze Ingested Messages: Look for log messages that lack the expected authentication header. This can be done by searching for messages from the HTTP Input source that do not contain the required header field.
3. Network Monitoring: Monitor network traffic to the Graylog HTTP Input port for unusual patterns, such as a high volume of POST requests from a single IP.

Hunting Query (Graylog Search):

{
  "query": "source:http AND NOT _exists_:X-Graylog-Auth-Token",
  "range": {
    "timestamp": {
      "gte": "now-7d"
    }
  }
}

This query searches for messages ingested via the HTTP Input that do not contain the X-Graylog-Auth-Token field (or whatever header is configured).

Indicators of Compromise (IOCs)

• Network IOCs:
  • Repeated HTTP POST requests to the Graylog HTTP Input endpoint returning 401 status codes.
  • Source IP addresses sending a high volume of such requests.
• Host IOCs:
  • Graylog server logs showing repeated 401 Unauthorized responses for HTTP Input requests.
  • Ingested log messages that do not contain the expected authentication header.
• Log IOCs:
  • Log entries with suspicious or unexpected content (e.g., test messages, unusual hostnames, or fields).
  • A sudden increase in log volume from the HTTP Input source.

Detection Engineering

YARA Rule

rule CVE_2025_30373_Graylog_Auth_Bypass {
    meta:
        description = "Detects Graylog HTTP Input authentication bypass attempts"
        author = "Valters IT"
        date = "2025-04-10"
        reference = "CVE-2025-30373"
        severity = "medium"
    strings:
        $http_input = "HTTP Input" nocase
        $unauthorized = "401" nocase
        $gelf = "gelf" nocase
    condition:
        $http_input and $unauthorized and $gelf
}

Sigma Rule

title: Graylog HTTP Input Authentication Bypass
id: 8a9b7c6d-5e4f-3a2b-1c0d-9e8f7a6b5c4d
status: experimental
description: Detects repeated 401 responses from Graylog HTTP Input, indicating potential exploitation of CVE-2025-30373.
author: Valters IT
date: 2025-04-10
references:
    - https://nvd.nist.gov/vuln/detail/CVE-2025-30373
logsource:
    product: graylog
    service: server
detection:
    selection:
        response_code: 401
        source: "HTTP Input"
    condition: selection
falsepositives:
    - Legitimate misconfigured clients
level: medium

Suricata Rule

alert http any any -> any any (msg:"CVE-2025-30373 Graylog HTTP Input Auth Bypass"; flow:to_server; content:"POST"; http_method; content:"/gelf"; http_uri; content:"401"; http_server_body; sid:1000001; rev:1;)

Note: This Suricata rule is a basic example. It may generate false positives. Tune it based on your environment.

Remediation & Mitigation

Immediate Mitigation (if patching is not possible):

1. Disable HTTP-based inputs. Use only authenticated pull-based inputs (e.g., Graylog Sidecar, Beats, Syslog with TLS).
2. Restrict network access. Use a firewall or network ACL to limit access to the HTTP Input endpoint to trusted IP addresses only.
3. Monitor logs. Implement the detection rules above to identify exploitation attempts.

Permanent Fix:

1. Upgrade to Graylog 6.1.9 or later. This is the only complete fix.
2. Verify the upgrade. After upgrading, test that HTTP Inputs with header authentication correctly reject unauthorized requests.

Workaround (Not Recommended):

• Use a reverse proxy (e.g., Nginx) to perform header authentication before forwarding requests to Graylog. This adds complexity and may not cover all attack vectors.

Valters IT
DevSecOps & Cyber Threat Intelligence Expert