CVE-2026-55867: Graylog Authentication Bypass Vulnerability

CVE-2026-55867 Overview

CVE-2026-55867 is an authorization bypass vulnerability in Graylog, an open-source log management platform. The flaw resides in the DELETE /users/{userId}/tokens/{idOrToken} endpoint implemented by UsersResource.revokeToken(). The endpoint checks the USERS_TOKENREMOVE permission against the attacker-controlled userId path parameter before resolving the token via idOrToken. An authenticated user can supply their own authorized userId while accessTokenService.loadById() or accessTokenService.load() returns a token belonging to another user, including service accounts or administrators. The token is then destroyed without validating AccessToken.getUserName(). Affected versions include Graylog 6.2.0 through 6.3.11, 7.0.0 through 7.0.6, and 7.1.0 through 7.1.1. The issue is classified as CWE-639 (Authorization Bypass Through User-Controlled Key).

Critical Impact

Any authenticated Graylog user can delete access tokens belonging to other users, including administrators and service accounts, disrupting token-based integrations and logging pipelines.

Affected Products

• Graylog 6.2.0 through 6.3.11
• Graylog 7.0.0 through 7.0.6
• Graylog 7.1.0 through 7.1.1

Discovery Timeline

• 2026-08-28 - CVE-2026-55867 published to NVD
• 2026-08-31 - Last updated in NVD database

Technical Details for CVE-2026-55867

Vulnerability Analysis

The vulnerability lives in graylog2-server/src/main/java/org/graylog2/rest/resources/users/UsersResource.java. The revokeToken() method accepts two path parameters: userId and idOrToken. The original implementation loaded the user identified by userId, extracted the associated username, and checked the USERS_TOKENREMOVE permission against that username. Only after passing the permission check did the code resolve the token through accessTokenService.loadById() or fall back to accessTokenService.load().

The two identifiers were never cross-validated. An attacker with permission to remove their own tokens can pass their own userId to satisfy the authorization gate, then supply a token ID (idOrToken) that belongs to a different account. The service call resolves that token and accessTokenService.destroy() deletes it. The vulnerability does not expose token contents; it only allows unauthorized deletion, which produces an integrity and availability impact on token-dependent integrations.

Root Cause

The root cause is a classic [CWE-639] insecure direct object reference where the authorization decision is based on a user-supplied key that is decoupled from the target object. The permission check uses userId while the destructive operation uses idOrToken. Because the two parameters are independent, an attacker can combine an authorized userId with an unauthorized token identifier.

Attack Vector

An authenticated Graylog user issues a DELETE request to /users/{userId}/tokens/{idOrToken}, setting userId to their own account and idOrToken to the ID of a token owned by an administrator or service account. The server authorizes the request against the attacker's own username, then deletes the victim's token.

     public void revokeToken(
             @Parameter(name = "userId", required = true) @PathParam("userId") String userId,
             @Parameter(name = "idOrToken", required = true) @PathParam("idOrToken") String idOrToken) {
-        final User user = loadUserById(userId);
-        final String username = user.getName();
-        if (!isPermitted(USERS_TOKENREMOVE, username)) {
-            throw new ForbiddenException("Not allowed to remove tokens for user " + username);
-        }
+        // The user must be logged in already, so we check the permission based on that info and the username of the
+        // token to be deleted. That way, the `userId`-parameter is indeed unused. Removing it would be a breaking change.
 
         final AccessToken accessToken = Optional.ofNullable(accessTokenService.loadById(idOrToken))
-                .orElse(accessTokenService.load(idOrToken));
+                .orElseGet(() -> accessTokenService.load(idOrToken));
 
-        if (accessToken != null) {
-            accessTokenService.destroy(accessToken);
-        } else {
-            throw new NotFoundException("Couldn't find access token for user " + username);
+        if (accessToken == null) {
+            throw new NotFoundException("Couldn't find access token for user.");
         }
+
+        if (!isPermitted(USERS_TOKENREMOVE, accessToken.getUserName())) {
+            throw new ForbiddenException("Not allowed to remove token for user " + accessToken.getUserName());
+        }

Source: Graylog2 patch commit 41d3745. The fix moves the permission check to run after the token is resolved and evaluates it against accessToken.getUserName() rather than the attacker-controlled userId.

Detection Methods for CVE-2026-55867

Indicators of Compromise

• Graylog audit or application logs containing DELETE /users/{userId}/tokens/{idOrToken} requests where the deleted token's owner does not match the userId path segment.
• Sudden disappearance of API access tokens belonging to administrative or service accounts, particularly those used by ingestion pipelines or automated integrations.
• Authentication failures from downstream integrations that previously used a now-deleted Graylog access token.

Detection Strategies

• Correlate revokeToken operations in Graylog server logs with the authenticated user identity and the owner of the deleted token; flag mismatches.
• Baseline the normal rate of token revocation events per user and alert on deviations, especially from low-privilege accounts.
• Monitor for successive DELETE /users/*/tokens/* calls from a single session enumerating token IDs.

Monitoring Recommendations

• Forward Graylog server audit logs to a centralized SIEM and build detections for token revocation events issued against administrator or service-account usernames.
• Alert on integration health failures (dropped log ingest, broken API automation) that may indicate silent token deletion.
• Track the Graylog server version across environments to identify hosts still running unpatched 6.2.x, 6.3.x, 7.0.x, or 7.1.x releases.

How to Mitigate CVE-2026-55867

Immediate Actions Required

• Upgrade Graylog to 6.3.12, 7.0.7, or 7.1.2, whichever matches your deployment branch.
• Audit existing access tokens and rotate any tokens used by administrators or service accounts if unauthorized deletions are suspected.
• Review Graylog user roles and revoke USERS_TOKENREMOVE from any account that does not require token management.

Patch Information

The fix is available in Graylog 6.3.12, 7.0.7, and 7.1.2. The patch, tracked in Graylog2 Pull Request #26049, PR #26051, PR #26053, and PR #26055, resolves the token first and then checks USERS_TOKENREMOVE against accessToken.getUserName(). Full details are in GHSA-j769-9gv9-65gr.

Workarounds

• Restrict network access to the Graylog REST API so that only trusted operators can reach /users/*/tokens/* endpoints.
• Reduce assignment of the USERS_TOKENREMOVE permission to the smallest possible set of administrative accounts.
• Prefer short-lived tokens and rotate service-account tokens on a schedule to limit the impact of unauthorized deletion.

# Verify installed Graylog version and upgrade path
curl -s -u admin:PASSWORD http://graylog.example.com:9000/api/system | jq '.version'

# Example Debian/Ubuntu upgrade to a fixed release
sudo apt-get update
sudo apt-get install --only-upgrade graylog-server=7.1.2-*
sudo systemctl restart graylog-server