CVE-2024-24823 is a recently disclosed security vulnerability affecting Graylog, a widely used free and open source log management platform. The issue exists in versions 4.3. and later, but before 5.1.11 and 5.2.4. This vulnerability revolves around improper handling of user session cookies during re-authentication, potentially allowing an attacker to gain unauthorized access or escalate privileges, if they can inject a malicious session cookie into a victim’s browser.

What's the Issue?

Normally, when a user logs in or authenticates with Graylog, their browser receives a unique session cookie that identifies their session. If the user later logs in as someone else, or if a new user logs in from the same browser, a secure system should issue a new session id—not reuse an old one.

However, due to this vulnerability in affected Graylog versions, if one user re-authenticates (logs in again), the existing session id might be re-used—even for different user credentials. That means a previously compromised session cookie is still valid and gets "upgraded" with the new user's access.

If a malicious user manages to inject a session cookie into someone else’s browser—say, using a cross-site scripting (XSS) attack or by tricking users into using a fake login page—they could potentially access privileged areas of Graylog using that session.

The good news: This is a *difficult* attack to pull off, since it relies on cookie injection and session fixation, often requiring XSS on your Graylog instance. But the risk shouldn’t be dismissed, especially for high-value environments.

Victim gets tricked into using this session id, either through

- Visiting a malicious page that sets the cookie via JavaScript/XSS

Interacting with a spoofed login page (phishing)

- Man-in-the-middle/proxying

Graylog accepts the old session id instead of creating a new one.

5. The session now has the victim's authenticated access, but the attacker knows the session id — they can likewise access the Graylog instance as the victim.

Critical Endpoint:
The flaw specifically exists in the /api/system/sessions endpoint of Graylog where the authentication cookie is (mis)handled.

Example Exploit Code

Let’s look at a demonstration in Python using the requests library. (For educational purposes only!):

import requests

# Attacker's prepared session id (must match the vulnerable Graylog deployment)
malicious_session = {'authentication': 'attacker-crafted-session-id'}

# Step 1: Attacker sends phishing link to victim with a crafted auth cookie
phishing_link = 'https://graylog.example.com/login';

# Step 2: Victim logs in using their credentials on the attacker's page

# Step 3: Once victim is authenticated, attacker uses the same session id
sensitive_url = 'https://graylog.example.com/api/system/sessions';

response = requests.get(sensitive_url, cookies=malicious_session)

if response.ok:
    print("Exploit successful! Current user session info:", response.json())
else:
    print("Exploit failed or patched.")

Note: The hardest part is *how* to make the victim's browser use the malicious authentication cookie. Realistically, this requires either XSS, a proxy control, or a phishing login scenario.

Upgrade to Graylog 5.1.11 or 5.2.4 (or any version in the 6.+ development branch)

- These versions include a patch to always create a new session on re-authentication, never re-using old session ids.

> You can see the fix in the official Graylog release notes

> - Graylog v5.1.11 release notes
> - Graylog v5.2.4 release notes
> - CVE record

Defensive Measures if Patch Not Available

- Shorten session expiration times: Lower the amount of time a session remains active. This limits the attack window.

Block third-party scripts: Prevent XSS by using a strong Content Security Policy.

- Use a trusted reverse proxy to strip authentication cookies from incoming requests to /api/system/sessions.

`nginx

location /api/system/sessions {
proxy_pass http://backend;

}

Conclusion

CVE-2024-24823 is a serious, but hard-to-exploit vulnerability in how Graylog handles session ids during re-authentication. While pulling off a real-world attack is complicated (requiring XSS or phishing), anyone running affected Graylog versions should *urgently* upgrade to a patched release. For those who can’t, deploying the mitigation workarounds described above is strongly recommended.

Stay vigilant, patch promptly, and always be cautious of incoming cookies—your logs are only as secure as your session management!

References

- CVE-2024-24823 (NVD)
- Graylog GitHub Security Advisory
- Graylog 5.1.11 Release
- Graylog 5.2.4 Release


*This article is exclusive and crafted for a clear, practical understanding. For maximum security, keep all your software—including log management systems—up to date.*

Timeline

Published on: 02/07/2024 18:15:54 UTC
Last modified on: 02/15/2024 15:41:48 UTC