CVE-2026-55867: 
Java vulnerability analysis and mitigation

CVE-2026-55867 is an Insecure Direct Object Reference (IDOR) vulnerability in Graylog's token revocation endpoint that allows any authenticated user to delete access tokens belonging to other users, including administrator and service account tokens. It affects Graylog versions 6.2.0 through 6.3.11, 7.0.0-alpha.1 through 7.0.6, and 7.1.0-alpha.1 through 7.1.1. The vulnerability was disclosed on August 28, 2026, with patches available in versions 6.3.12, 7.0.7, and 7.1.2. It carries a CVSS v4.0 base score of 5.3 (Medium) (GitHub Advisory).

The root cause is an authorization bypass through a user-controlled key (CWE-639) in UsersResource.revokeToken() within graylog2-server/src/main/java/org/graylog2/rest/resources/users/UsersResource.java. The DELETE /users/{userId}/tokens/{idOrToken} endpoint validates the USERS_TOKENREMOVE permission only against the attacker-supplied userId path parameter, but never verifies that the resolved token (via accessTokenService.loadById() or accessTokenService.load()) actually belongs to that user before calling accessTokenService.destroy(). Since every authenticated user is automatically granted users:tokenremove:{self}, any user can supply their own userId in the URL while providing a token ID belonging to another user — including an administrator — to trigger unauthorized deletion. Additionally, the fallback branch accepts a plaintext token value, meaning tokens leaked via access logs could also be revoked this way (GitHub Advisory, Fix PR #26049).

Successful exploitation allows an authenticated low-privileged user to delete access tokens belonging to any other user, including administrators and service accounts, without exposing the token's contents. This results in an integrity impact (unauthorized data deletion) and an availability impact by disrupting access-token-based integrations, automated pipelines, or API clients that rely on those tokens. While no credential exposure occurs, forced token revocation can effectively lock out legitimate users or break critical monitoring and log-ingestion workflows (GitHub Advisory).

No public proof-of-concept exploit code or in-the-wild exploitation has been reported as of the disclosure date. The vulnerability requires a valid authenticated session (low privilege), making it accessible to any registered Graylog user. The EPSS score is 0.0, and the vulnerability is not listed in the CISA Known Exploited Vulnerabilities catalog (GitHub Advisory). The vulnerability was reported by researchers michaelddickenson and sreelim.

1. Authenticate: Log in to the Graylog instance with any valid low-privileged user account to obtain a session cookie or API token.
2. Obtain own userId: Retrieve the attacker's own user ID (e.g., via the Graylog API at GET /api/users/{username} or from the user profile page).
3. Enumerate or guess target token IDs: Attempt to enumerate token IDs belonging to other users (e.g., administrators or service accounts) by guessing MongoDB ObjectID-format identifiers, or by obtaining a plaintext token value from access logs if available.
4. Craft malicious DELETE request: Send a DELETE request to DELETE /api/users/{attacker_userId}/tokens/{target_token_id_or_value}, substituting the attacker's own userId in the path and the victim's token ID or plaintext token in the idOrToken segment.
5. Token deleted: The server validates only that the caller has users:tokenremove:{attacker_userId} (which is auto-granted), resolves the token by ID without ownership verification, and deletes it — revoking the victim's access token without authorization (GitHub Advisory, Fix PR #26049).

• Logs: Graylog audit log entries beginning with access token deleted from user where the deleting user does not match the token owner — review for mismatches between the acting user and the token's associated account (Graylog Enterprise/Security audit log feature required).
• Logs: Unexpected HTTP 204 (success) or 404 responses to DELETE /api/users/{userId}/tokens/{idOrToken} requests in the Graylog API access logs, particularly where the userId in the path does not correspond to the token being deleted.
• Network: Repeated DELETE requests to the /api/users/*/tokens/* endpoint from a single low-privileged user account, especially targeting multiple different token IDs in rapid succession.
• Application Behavior: Sudden authentication failures or disruptions for service accounts, API integrations, or administrator sessions that rely on access tokens, without those tokens being explicitly revoked by their owners (GitHub Advisory).

Graylog has released patches in versions 6.3.12, 7.0.7, and 7.1.2; users should upgrade to one of these versions immediately. Graylog Cloud has already been patched automatically. There are no feasible configuration-based workarounds for on-premises deployments. Graylog Enterprise and Security customers can review the audit log for suspicious access token deleted from user entries to assess whether exploitation occurred prior to patching (GitHub Advisory).