GHSA-3fqm-frhg-7c85 is a low-severity (CVSS 2.6) CWE-613 vulnerability in org.graylog2:graylog2-server. 1 public exploit reference exists, so weaponization risk is real. O3 Security confirms whether GHSA-3fqm-frhg-7c85 is actually reachable in your code before you act, and blocks exploitation at runtime until you patch.
Graylog user session is still usable after logout
Real-World Exposure
org.graylog2:graylog2-server☕org.graylog2:graylog2-serverReal-time download stats are indexed for npm and PyPI packages. This vulnerability affects Maven packages — download data is not available via public APIs for these ecosystems.
Description
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:
- Log in
- Extract the session ID from the cookie
- Log out and close the browser
- 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 - 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.
Affected Packages
| Ecosystem | Package | Vulnerable range | Fix |
|---|---|---|---|
| ☕Maven | org.graylog2:graylog2-server | ≥ 1.0&&< 5.0.9 | 5.0.9 |
| ☕Maven | org.graylog2:graylog2-server | ≥ 5.1.0&&< 5.1.3 | 5.1.3 |
Research use only. For defensive security, authorized penetration testing, and academic research only. Never execute exploit code against systems without explicit written authorization.
Detection & mitigation playbook
Open-source dependencyDetect
Scan your dependency tree (package-lock.json, pnpm-lock.yaml, requirements.txt, go.sum, etc.) for org.graylog2:graylog2-server. O3's reachability analysis confirms whether the vulnerable code path is actually invoked in your application, so you act on real exposure instead of every transitive match.
Fix
Update org.graylog2:graylog2-server to 5.0.9 or later, then make sure no transitive (indirect) dependency still pins the vulnerable range — O3 confirms GHSA-3fqm-frhg-7c85 is resolved across your whole dependency graph.
Workarounds
If you can't upgrade right away: gate or disable the affected feature, validate untrusted input at the boundary, and avoid passing attacker-controlled data into the vulnerable path. O3's runtime protection blocks exploitation in production as an interim safeguard until the upgrade lands.
How O3 protects you
O3 pinpoints whether GHSA-3fqm-frhg-7c85 is reachable in your code and exactly where to fix it, then blocks exploitation in production at runtime until the patched version is deployed.
Tailored to GHSA-3fqm-frhg-7c85. Runtime protection reduces exposure until a permanent patch is applied and verified — it complements patching, it doesn't replace it.
Frequently Asked Questions
Is GHSA-3fqm-frhg-7c85 in your dependencies?
O3 detects GHSA-3fqm-frhg-7c85 across Maven dependencies and uses function-level reachability to confirm whether the vulnerable code path is actually reachable — not just present. No false positives.