CVE-2023-41041: User session is still usable after logout in graylog2-server

Published Jul 6, 2023
·
Updated

Summary

In a multi-node Graylog cluster, after a user has explicitly logged out, a user session may still be used for API requests until it has reached its original expiry time.

Details

Each node maintains an in-memory cache of user sessions. Upon a cache-miss, the session is loaded from the database. After that, the node operates solely on the cached session. Modifications to sessions will update the cached version as well as the session persisted in the database. However, each node maintains their isolated version of the session.

When the user logs out, the session is removed from the node-local cache and deleted from the database. The other nodes will however still use the cached session.

These nodes will only fail to accept the session id if they intent to update the session in the database. They will then notice that the session is gone. This is true for most API requests originating from user interaction with the Graylog UI because these will lead to an update of the session's "last access" timestamp.

If the session update is however prevented by setting the X-Graylog-No-Session-Extension:true header in the request, the node will consider the (cached) session valid until the session is expired according to its timeout setting.

PoC In a 2-node setup, with both nodes behind a load balancer:

1. Log in 1. Extract the session ID from the cookie 1. Log out and close the browser 1. Perform the following API request repeatedly with curl (with <session-id> replaced with the session id from step 2 and <lb-host> replaced with the hostname of your load balancer): curl -I -H X-Graylog-No-Session-Extension:true https://<session-id>:session@<lb-host>/api/system/cluster/nodes 1. Notice that the request is sometimes rejected, but sometimes succeeds

Impact

No session identifiers are leaked.

After a user has logged out, the UI shows the login screen again, which gives the user the impression that their session is not valid anymore. However, if the session becomes compromised later, it can still be used to perform API requests against the Graylog cluster. The time frame for this is limited to the configured session lifetime, starting from the time when the user logged out.

Other sources

Graylog is a free and open log management platform. In a multi-node Graylog cluster, after a user has explicitly logged out, a user session may still be used for API requests until it has reached its original expiry time. Each node maintains an in-memory cache of user sessions. Upon a cache-miss, the session is loaded from the database. After that, the node operates solely on the cached session. Modifications to sessions will update the cached version as well as the session persisted in the database. However, each node maintains their isolated version of the session. When the user logs out, the session is removed from the node-local cache and deleted from the database. The other nodes will however still use the cached session. These nodes will only fail to accept the session id if they intent to update the session in the database. They will then notice that the session is gone. This is true for most API requests originating from user interaction with the Graylog UI because these will lead to an update of the session's "last access" timestamp. If the session update is however prevented by setting the X-Graylog-No-Session-Extension:true header in the request, the node will consider the (cached) session valid until the session is expired according to its timeout setting. No session identifiers are leaked. After a user has logged out, the UI shows the login screen again, which gives the user the impression that their session is not valid anymore. However, if the session becomes compromised later, it can still be used to perform API requests against the Graylog cluster. The time frame for this is limited to the configured session lifetime, starting from the time when the user logged out. This issue has been addressed in versions 5.0.9 and 5.1.3. Users are advised to upgrade.

MITRE

Affected Software

4 affected componentsFixes available
maven/org.graylog2:graylog2-server>=5.1.0<5.1.3
5.1.3
maven/org.graylog2:graylog2-server>=1.0<5.0.9
5.0.9
Graylog Graylog>=1.0.0<5.0.9
Graylog Graylog>=5.1.0<5.1.3

Event History

Jul 6, 2023
Advisory Published
08:47 PM
Aug 30, 2023
CVE Published
via MITRE·09:03 PM
Data Sourced
via MITRE·09:03 PM
DescriptionSeverityWeakness

Frequently Asked Questions

1

What is CVE-2023-41041?

CVE-2023-41041 is a vulnerability in the Graylog log management platform that allows a user session to still be used for API requests after the user has logged out.

2

What is the severity of CVE-2023-41041?

CVE-2023-41041 has a severity level of low with a CVSS score of 3.1.

3

How does CVE-2023-41041 affect Graylog?

CVE-2023-41041 affects multi-node Graylog clusters by allowing user sessions to remain active for API requests even after the user has logged out.

4

Which versions of Graylog are affected by CVE-2023-41041?

Versions 5.1.0 to 5.1.3 and 1.0.0 to 5.0.9 of Graylog are affected by CVE-2023-41041.

5

How can I fix CVE-2023-41041?

To fix CVE-2023-41041, upgrade to Graylog version 5.1.3 or higher, or version 5.0.9 or higher.

Contact

SecAlerts Pty Ltd.
132 Wickham Terrace
Fortitude Valley,
QLD 4006, Australia
info@secalerts.co
By using SecAlerts services, you agree to our services end-user license agreement. This website is safeguarded by reCAPTCHA and governed by the Google Privacy Policy and Terms of Service. All names, logos, and brands of products are owned by their respective owners, and any usage of these names, logos, and brands for identification purposes only does not imply endorsement. If you possess any content that requires removal, please get in touch with us.
© 2026 SecAlerts Pty Ltd.
ABN: 70 645 966 203, ACN: 645 966 203