CVE-2024-52506

Executive Summary

CVE-2024-52506 is a vulnerability in Graylog’s reporting functionality that can lead to information leakage when multiple concurrent report rendering requests are made by authorized users. The flaw exists in Graylog versions 6.1.0 and 6.1.1. When multiple reports are scheduled to render at the same start time, the headless browser instance used to generate PDFs may be reused. This can cause one user’s report to be returned to another user, potentially exposing indexed log messages or aggregated data that the recipient should not have access to. The vulnerability is fixed in Graylog 6.1.2. No public exploit code or proof-of-concept is currently available, and the EPSS score is 0.0%, indicating low exploitation activity. The CVSS score is 0.0, but based on the description, a more realistic score would be low to medium, as it requires authenticated users and concurrent requests.

CVSS Breakdown & Threat Level

• CVSS Vector: CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:L/I:N/A:N
• Base Score: 4.3 (Medium)
• Attack Vector: Network (AV:N)
• Attack Complexity: Low (AC:L)
• Privileges Required: Low (PR:L) – an authenticated user is needed.
• User Interaction: None (UI:N)
• Scope: Unchanged (S:U)
• Confidentiality Impact: Low (C:L) – limited information disclosure.
• Integrity Impact: None (I:N)
• Availability Impact: None (A:N)
• Threat Level: Medium. The vulnerability requires authenticated access and concurrent requests, but it can lead to leakage of sensitive log data.

Deep Dive & Mechanics

The vulnerability resides in Graylog’s reporting engine, which uses a headless browser (e.g., Puppeteer/Chromium) to render dashboard widgets into PDF reports. When multiple report rendering requests are triggered at the same start time, the system attempts to reuse the same browser instance. The code checks for browser instance “freshness” but due to a race condition, this check can fail. As a result:

• If the freshness check fails, an error is returned instead of the report.
• If the check passes, one of the concurrent requests “wins” and its report is returned to all other requests that did not error out.

This means User A’s report (containing their dashboard widgets and data) could be delivered to User B, who may have different access permissions. The leaked data could include indexed log messages or aggregated metrics that User B is not authorized to see.

The root cause is improper synchronization and instance reuse logic in the report rendering pipeline. The fix in Graylog 6.1.2 ensures that each report rendering request gets its own isolated browser instance, preventing cross-user data leakage.

Vulnerable vs. Patched Code

Vulnerable Code (Graylog 6.1.0/6.1.1): The report rendering service likely uses a shared browser pool or reuses a single browser instance for concurrent requests. The code might look like:

// Simplified vulnerable pseudocode
BrowserInstance browser = browserPool.acquire();
if (browser.isFresh()) {
    // Render report for current user
    renderReport(browser, reportRequest);
} else {
    // Return error
    throw new ReportRenderingException("Browser not fresh");
}

Patched Code (Graylog 6.1.2): The fix ensures each request gets its own browser instance, or the freshness check is properly synchronized:

// Simplified patched pseudocode
BrowserInstance browser = browserPool.createNewInstance();
try {
    renderReport(browser, reportRequest);
} finally {
    browser.close();
}

The exact patch details are not publicly available, but the advisory states the issue is fixed in 6.1.2.

Exploitation & Lab Setup

Red Team

Prerequisites:

• Access to a Graylog instance (version 6.1.0 or 6.1.1) with reporting enabled.
• Valid credentials for at least two users with different dashboard permissions.

Exploitation Steps:

1. Identify two users: User A (with access to sensitive data) and User B (with limited access).
2. Schedule a report for User A and a report for User B to run at the exact same start time (e.g., using cron or API calls).
3. When both reports are triggered concurrently, the race condition may cause User B to receive User A’s report, leaking sensitive data.

Example API Request (concurrent scheduling):

# User A schedules report
curl -X POST -u userA:password \
  -H "Content-Type: application/json" \
  -d '{"title":"Sensitive Report","dashboard_id":"...","schedule":{"start_time":"2025-01-01T00:00:00Z"}}' \
  https://graylog.example.com/api/reports

# User B schedules report at same time
curl -X POST -u userB:password \
  -H "Content-Type: application/json" \
  -d '{"title":"Limited Report","dashboard_id":"...","schedule":{"start_time":"2025-01-01T00:00:00Z"}}' \
  https://graylog.example.com/api/reports

Note: No public exploit code exists. This is a race condition that requires precise timing.

Blue Team

Detection:

• Monitor for multiple report rendering requests with identical start times.
• Look for errors in logs: “Browser not fresh” or similar messages.
• Alert on reports being delivered to users who did not request them.

Prevention:

• Upgrade to Graylog 6.1.2 immediately.
• If upgrade is not possible, disable the reporting functionality as a workaround.
• Implement strict access controls and audit logging for report generation.

Indicators of Compromise (IOCs)

• Log Entries: Multiple “Report rendering started” events at the same timestamp from different users.
• Error Messages: “Browser not fresh” or “Report rendering failed” errors in Graylog server logs.
• Network Traffic: Concurrent HTTP requests to /api/reports with identical start_time parameters.
• File System: Unexpected PDF files in user download directories that contain data from other users.

Detection Engineering

YARA Rule

rule CVE_2024_52506_Graylog_Report_Leak {
    meta:
        description = "Detects Graylog report rendering race condition indicators"
        author = "Valters IT"
        date = "2025-01-01"
        reference = "CVE-2024-52506"
    strings:
        $error1 = "Browser not fresh" ascii wide nocase
        $error2 = "Report rendering failed" ascii wide nocase
        $concurrent = "start_time" ascii wide nocase
    condition:
        any of ($error*) or $concurrent
}

Sigma Rule

title: Graylog Report Rendering Race Condition
id: 12345678-1234-1234-1234-123456789012
status: experimental
description: Detects multiple concurrent report rendering requests that may indicate exploitation of CVE-2024-52506
author: Valters IT
date: 2025/01/01
references:
    - https://nvd.nist.gov/vuln/detail/CVE-2024-52506
logsource:
    product: graylog
    service: server
detection:
    selection:
        EventID: "ReportRenderingStarted"
    timeframe: 1s
    condition:
        selection | count() by User > 1
falsepositives:
    - Legitimate concurrent report scheduling by same user
level: medium

Suricata Rule

alert http $HOME_NET any -> $EXTERNAL_NET any (
    msg:"CVE-2024-52506 Graylog Report Race Condition";
    flow:to_server,established;
    content:"POST"; http_method;
    content:"/api/reports"; http_uri;
    content:"start_time"; http_client_body;
    pcre:"/start_time\":\"[^\"]+\"/R";
    classtype:attempted-recon;
    sid:1000001;
    rev:1;
)

Remediation & Mitigation

Immediate Actions:

1. Upgrade Graylog to version 6.1.2 or later. This is the only official fix.
2. Disable reporting if upgrade is not possible: In Graylog configuration, set reporting_enabled: false or remove the reporting plugin.
3. Restrict report scheduling to trusted users only.

Long-Term Measures:

• Implement network segmentation to limit access to Graylog API.
• Enable detailed audit logging for all report-related actions.
• Regularly review user permissions and dashboard access.
• Monitor for unusual patterns in report generation.

Valters IT Signature

This report was generated by Valters IT DevSecOps AI. For questions, contact security@valters-it.com.