CVE-2026-55867: Graylog token revocation endpoint allows authenticated users to delete other users’ access tokens
Impact
Graylog contains an insecure direct object reference (IDOR) vulnerability in the token revocation endpoint. An authenticated user can delete access tokens belonging to other users, including service account tokens and administrator tokens, if they know or can guess a valid token identifier.
The issue does not expose token contents, but it allows unauthorized token deletion, leading to integrity impact and potential availability impact for access token based integrations.
Patches
The issue has been fixed in the following Graylog versions: 6.3.12, 7.0.7, 7.1.2. Users should upgrade to one of these versions or above to remediate the vulnerability.
Graylog Cloud has already been patched.
Workarounds
There are no feasible workarounds for this issue. Upgrading to a patched version is recommended.
Customers using Graylog Enterprise or Security can review the audit log[^1] for suspicious activity. Audit log lines for successful token deletions begin with access token deleted from user.
Credits
Thanks to michaelddickenson and sreelim for reporting.
[^1]: https://go2docs.graylog.org/current/interactingwithyourlogdata/auditlog.html
Other sources
Graylog is a free and open log management platform. From 6.2.0 until 6.3.12, 7.0.7, and 7.1.2, the DELETE /users/{userId}/tokens/{idOrToken} endpoint implemented by UsersResource.revokeToken() in graylog2-server/src/main/java/org/graylog2/rest/resources/users/UsersResource.java checks USERSTOKENREMOVE permission against the attacker-controlled userId path parameter before resolving the token selected by idOrToken. An authenticated user can provide an authorized userId while accessTokenService.loadById() or accessTokenService.load() resolves a token belonging to another user, including a service account or administrator, after which accessTokenService.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. This issue is fixed in versions 6.3.12, 7.0.7, and 7.1.2.
— MITRE
Affected Software
Remediation
Recommended actions to resolve this vulnerability, in priority order.
- Upgrade
Upgrade
maven/org.graylog2:graylog2-serverto a version that resolves this vulnerability.Fixed in 7.1.2 - Upgrade
Upgrade
maven/org.graylog2:graylog2-serverto a version that resolves this vulnerability.Fixed in 7.0.7 - Upgrade
Upgrade
maven/org.graylog2:graylog2-serverto a version that resolves this vulnerability.Fixed in 6.3.12 - Upgrade
Upgrade to a fixed release to a version that resolves this vulnerability.
Fixed in 6.3.12 - Upgrade
Upgrade to a fixed release to a version that resolves this vulnerability.
Fixed in 7.0.7 - Upgrade
Upgrade to a fixed release to a version that resolves this vulnerability.
Fixed in 7.1.2
Event History
Frequently Asked Questions
Who can exploit this issue, and what do they need?
Any authenticated Graylog user can exploit it if they know or can guess a valid access-token identifier. They can target tokens belonging to other users, including service accounts and administrators, but cannot obtain the token contents.
What is the operational impact of exploitation?
An attacker can revoke another user's access token without authorization. This can disrupt access-token-based integrations and create integrity and availability impact, including by deleting service-account or administrator tokens.
Which deployments are already remediated?
Graylog Cloud has already been patched. Self-managed deployments should upgrade to Graylog 6.3.12, 7.0.7, 7.1.2, or a later version.
What can be done if an immediate upgrade is not possible?
No feasible workaround is available. Upgrading to a patched version is the recommended remediation.
How can Enterprise or Security customers check for suspected exploitation?
Review the audit log for successful token deletions. Relevant entries begin with "access token deleted from user".