CVE-2023-41041
LowCVSS 2.6Exploitation Probability (EPSS)
Low risk33th percentile - higher than 33% of all known CVEs
Summary
In the Graylog platform, in multi-node clusters, a user session may still be used for API requests after logout until it reaches its original expiry time. Each node maintains a local cache of user sessions, leading to situations where other nodes may still accept the session after it has been removed from the local cache.
Risk Assessment
The organization may be exposed to the risk of unauthorized access to the API even after a user has logged out, potentially leading to data security breaches.
Recommendation
It is recommended to upgrade to versions 5.0.9 or 5.1.3 to mitigate this vulnerability. Additionally, consider implementing further security measures to reduce the risk associated with session usage after logout.
Other vulnerabilities in Graylog
See all- CVE-2026-69190Medium
Graylog is a free and open log management platform. From 6.3.0 until 6.3.14, 7.0.9, and 7.1.4, the view update API for saved searches and dashboards permits a user with edit permission but without entity ownership to include a shareRequest that grants owner permissions to an arbitrary account. The selected account can then delete the saved search or dashboard or remove the original owner's access. Graylog Cloud was patched before the advisory was published. This issue is fixed in versions 6.3.14, 7.0.9, and 7.1.4.
- CVE-2026-92789Medium
Graylog through 7.1.4 validates outbound URLs against an allowlist before making requests but fails to re-validate after following HTTP redirects. Attackers with lookup table or event notification permissions can craft allowlisted endpoints that redirect to internal services, enabling the server to fetch and return internal responses.
- CVE-2026-55867Medium
Graylog from 6.2.0 to 6.3.12, 7.0.7, and 7.1.2 has a vulnerability in the DELETE /users/{userId}/tokens/{idOrToken} endpoint where USERS_TOKENREMOVE permission is checked against the attacker-controlled userId path parameter before resolving the token selected by idOrToken. An authenticated user can provide an authorized userId while loadById() or load() resolves a token belonging to another user, including a service account or administrator, after which destroy() deletes that token without checking AccessToken.getUserName(). The issue does not expose token contents, but unauthorized deletion causes integrity impact and can disrupt access-token-based integrations.
- CVE-2026-55841High
Vulnerability in Graylog Server before versions 6.3.12, 7.0.7, and 7.1.2 and Graylog Forwarder before 7.3. The FortiGate syslog parser mishandles fields inside quoted values, allowing an unauthenticated sender to manipulate security-log fields or evade logging to obscure malicious activity.
- CVE-2026-55425Medium
Graylog from 7.1.0 until 7.1.4 and 7.2.0-alpha.2 allows an authenticated user to request composite display fields in the System Catalog entity titles endpoint without verifying that every selected field is readable. A user can retrieve protected values, including password hashes on readable user records; ordinary users are limited to their own records, while administrators can retrieve hashes for all users.
- CVE-2023-41045Low
Graylog, a log management platform, uses a single source port for DNS queries, which goes against recommended security practices. This could allow DNS cache poisoning attacks, where an external attacker can inject forged DNS responses into Graylog's cache.
- CVE-2023-41044Low
Graylog has a partial path traversal vulnerability in the `Support Bundle` feature that allows an attacker with valid Admin role credentials to download or delete files in sibling directories. The issue is caused by improper input validation in an HTTP API resource.
Original NVD description (English source)
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.
Vulnerability data from NVD (NIST) · CISA KEV · EPSS