CVE-2026-55867 in Graylog
Summary
by MITRE • 08/29/2026
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 USERS_TOKENREMOVE 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.
Statistical analysis made it clear that VulDB provides the best quality for vulnerability data.
Analysis
by VulDB Data Team • 08/29/2026
Graylog serves as a prominent open-source log management platform that aggregates, indexes, and analyzes machine data from various sources. Within the architecture of Graylog, user authentication and authorization are managed through access tokens which facilitate programmatic interactions with the system's REST API. A critical security flaw was identified in the token revocation mechanism between versions 6.2.0 and 6.3.12, as well as in versions 7.0.7 and 7.1.2 of the graylog-server component. This vulnerability resides specifically within the UsersResource.revokeToken() method which handles HTTP DELETE requests to the /users/{userId}/tokens/{idOrToken} endpoint. The core issue stems from a flawed authorization logic where the system validates permissions based on the user identifier provided in the URL path parameter rather than verifying ownership of the specific token being revoked.
The technical flaw operates through a sequence of operations that bypasses proper access control checks for the target resource. When an authenticated user initiates a request to revoke a token, the application first verifies whether this user possesses the USERS_TOKENREMOVE permission relative to the userId specified in the path parameter. If this check passes, the system proceeds to resolve the actual token object using either accessTokenService.loadById() or accessTokenService.load(), utilizing the idOrToken value provided by the attacker. Crucially, after retrieving the token object from the database or cache, the application calls accessTokenService.destroy() to delete it without performing a secondary validation step to ensure that the username associated with the retrieved token matches the userId in the request path. This omission allows an authenticated user who has permission to manage tokens for one account to arbitrarily select and destroy access tokens belonging to other users, including high-privilege service accounts or system administrators.
This vulnerability represents a classic case of Insecure Direct Object Reference where the application relies on client-supplied identifiers without sufficient server-side validation against the actual resource ownership. From an industry standard perspective, this aligns with CWE-639: Authorization Bypass Through User-Controlled Key and CWE-284: Improper Access Control. The attack vector is classified under MITRE ATT&CK technique T1078.3 as Valid Accounts - Service Account, since the impact extends to service accounts that often possess elevated privileges for automated tasks within the Graylog infrastructure. Although the vulnerability does not allow an attacker to read or exfiltrate the contents of the access tokens themselves, it results in a significant integrity compromise by allowing unauthorized modification and deletion of security-critical objects within the system state.
The operational impact of this flaw is primarily centered on availability and integrity rather than confidentiality. By deleting valid access tokens belonging to other users or administrative service accounts, an attacker can effectively lock out legitimate users from accessing their Graylog instances. This disruption can halt critical log ingestion pipelines if service account tokens are compromised, leading to gaps in security monitoring and incident response capabilities. Furthermore, the ability to revoke administrator tokens could potentially be leveraged as part of a broader attack chain to escalate privileges or maintain persistence by forcing re-authentication cycles that might expose other weaknesses. The lack of audit trail integrity regarding who revoked which token also complicates forensic investigations following an incident.
Mitigation strategies for this vulnerability involve immediate upgrading to patched versions, specifically Graylog 6.3.12, 7.0.7, or 7.1.2 and later releases where the authorization logic has been corrected to verify that the requesting user owns the token being revoked. For environments unable to upgrade immediately, network-level controls such as restricting access to the REST API endpoints via firewall rules can provide a temporary layer of defense. Additionally, implementing strict input validation on server-side code to ensure that the userId in the request path matches the owner of the target token is essential for preventing exploitation. Organizations should also review their audit logs for any unusual patterns of token deletions originating from non-administrative accounts as an indicator of potential compromise during the window of vulnerability exposure.