CVE-2026-55867

Executive Summary

CVE-2026-55867 is an authorization bypass vulnerability in Graylog's user token management REST API, affecting versions 6.2.0 through 6.3.11, 7.0.0 through 7.0.6, and 7.1.0 through 7.1.1. An authenticated user with token-removal permissions can delete API tokens belonging to other users — including service accounts and administrators — by exploiting an authorization check that validates permissions against the attacker-controlled userId path parameter rather than the token owner. The vulnerability does not expose token contents but enables unauthorized token destruction, causing integrity impact and potentially disrupting access-token-based integrations that rely on Graylog's API. Patches are available in versions 6.3.12, 7.0.7, and 7.1.2.

Technical Analysis

The vulnerability resides in the DELETE /users/{userId}/tokens/{idOrToken} endpoint implemented by UsersResource.revokeToken() in graylog2-server/src/main/java/org/graylog2/rest/resources/users/UsersResource.java.

The root cause is an authorization check ordering flaw. The endpoint validates that the authenticated user holds the USERS_TOKENREMOVE permission against the userId path parameter before resolving the token selected by the idOrToken parameter. The flow proceeds as follows:

1. Authorization check against attacker-controlled parameter: The server checks whether the authenticated user has USERS_TOKENREMOVE permission for the userId provided in the URL path. Since this parameter is attacker-controlled, the user can supply a userId for which they legitimately hold that permission (e.g., their own user ID or another account they administer).

2. Token resolution without ownership verification: Following the authorization check, accessTokenService.loadById() or accessTokenService.load() resolves the token identified by idOrToken. Critically, the token resolution process does not verify that the token actually belongs to the userId supplied in the path parameter. The token can belong to any user — including a service account or administrator.

3. Deletion without cross-check: accessTokenService.destroy() deletes the resolved token without verifying AccessToken.getUserName() matches the userId from the path. This final step completes the privilege escalation, resulting in the deletion of a token owned by a different principal.

The authorization check and the resource resolution operate on independent identifiers that are never cross-validated. This is a classic Insecure Direct Object Reference (IDOR) flaw categorized as CWE-639 (Authorization Bypass Through User-Controlled Key).

The attack surface is the Graylog REST API, which is typically exposed to authenticated users through the web interface and programmatic API clients. The endpoint in question is reachable by any authenticated user holding the USERS_TOKENREMOVE permission, which is typically granted to users with administrative or user-management roles.

The vulnerability does not leak token contents (no confidentiality impact), but the destruction of tokens creates an integrity impact. For token-based integrations — such as system monitoring, log shipping, CI/CD pipelines, and third-party tools that authenticate to Graylog via API tokens — token deletion causes immediate authentication failures and service disruption.

No patch evidence was available from tracked sources at the time of this writing; however, the NVD description confirms fix versions 6.3.12, 7.0.7, and 7.1.2. Insufficient technical detail is available to confirm whether the fix addresses the authorization check ordering, introduces a token-ownership cross-check, or both.

Exploitation Scenarios

No public PoC is available; the attack chain below is inferred from the vulnerability class and the NVD description.

Step 1 — Reconnaissance / Target Identification: An attacker with valid Graylog credentials first identifies the target environment. Graylog deployments are frequently exposed via web interfaces on default ports (9000 for the web UI, 12201 for GELF input). The attacker determines their own user ID and confirms they hold the USERS_TOKENREMOVE permission. They would also enumerate or guess the user IDs of service accounts or administrators whose tokens they wish to delete. HTTP responses from the token management API reveal user existence and permission state.

Step 2 — Flaw Class Triggering: The attacker constructs a DELETE request to the /users/{userId}/tokens/{idOrToken} endpoint, supplying:

• {userId}: their own user ID (or another ID for which they hold USERS_TOKENREMOVE permission) — this passes the initial authorization check.
• {idOrToken}: the token ID or token string belonging to the targeted victim user (service account or administrator).

Because the server validates the permission against the attacker-supplied userId but resolves and deletes the token without verifying ownership, the authorization check is bypassed. The attacker does not need any permission on the victim's account.

Step 3 — Payload/Execution Method: The attack is performed by merely sending a crafted HTTP DELETE request. No injected payload or exploit code is required. The "payload" is the pair of parameters designed to decouple the authorization identity from the resource identity. The attacker may need to obtain the target token ID — this could be done through session replay, log inspection, or by guessing predictable token IDs if token generation is not sufficiently random (though insufficient detail is available to confirm token ID predictability).

Step 4 — Post-Exploitation Impact: Once the victim's token is deleted, any integration authenticating with that token loses access to the Graylog API. Typical impacts include:

• Disruption of log ingestion from external systems authenticating via token.
• Failure of automated search, alerting, or reporting jobs.
• Inability of administrative tooling to manage Graylog configuration.
• Repetition of the attack to delete all tokens belonging to critical service accounts, causing prolonged operational disruption.

An attacker could systematically delete tokens of all service accounts and administrators, severely degrading the Graylog environment's functionality and potentially masking other malicious activity due to the disruption of monitoring pipelines.

Proof of Concept Intelligence

No public proof-of-concept is currently available for this vulnerability. However, exploitation may still be possible for the following reasons:

1. The vulnerability is a logic/authorization flaw, not a memory corruption bug. Such flaws are typically trivial to exploit once understood — the attack requires only a crafted HTTP DELETE request — making it a low-complexity issue that could be weaponized by any security researcher or attacker with access to the vulnerable versions.

2. The affected endpoint is part of the standard REST API, which is well-documented in Graylog's official API documentation. The request structure is derivable from public documentation, reducing reverse-engineering effort.

3. Graylog has a sizeable user base among enterprises for log management, meaning the vulnerable versions are likely deployed in numerous production environments where validating exploitation is feasible.

Defenders should monitor the following resources for future PoC disclosure:

• Graylog's official security advisories and GitHub repository (github.com/Graylog2/graylog2-server) for issue disclosures or fix commits.
• Exploit-db (exploit-db.com) and the Rapid7 vulnerability database.
• Researcher blogs and Twitter/X security communities (e.g., under the #Graylog or #CVE-2026-55867 hashtags).
• GitHub code search for proof-of-concept scripts or Metasploit modules referencing this CVE.
• Nuclei template repositories (the current status is "NO" for Nuclei, but templates may be published later).

Impact Assessment

Business Impact: The vulnerability enables an authenticated user with minimal privileges (any user with USERS_TOKENREMOVE permission) to delete API tokens belonging to other principals. The primary business impact is integrity loss and availability degradation of token-based integrations. Since Graylog is a centralized log management platform, disrupting its API integrations can blind security operations teams — the very function Graylog serves — creating a cascading impact on the organization's overall security monitoring posture.

Affected Systems: All Graylog instances running versions 6.2.0 through 6.3.11, 7.0.0 through 7.0.6, and 7.1.0 through 7.1.1 are affected. The vulnerability is exploitable via the REST API, which is enabled by default.

Blast Radius:

• Attack complexity: Low — requires only authenticated access and the crafting of a specific HTTP request.
• Privileges required: Low — only USERS_TOKENREMOVE on the attacker's own user ID (or any ID they manage).
• User interaction: None required.
• Confidentiality impact: None (token contents are not exposed).
• Integrity impact: High — unauthorized token deletion corrupts the API authentication state.
• Availability impact: High — deletion of tokens disrupts all integrations relying on those tokens.

CVSS Note: The official CVSS score is N/A (not yet assigned). Without an official score, severity should be judged against the qualitative factors above. In a risk assessment context, this vulnerability should be treated as High severity given its low attack complexity, network reachability, and its ability to disrupt API access for critical service accounts.

Detection Guidance

Sigma Rule

title: Graylog Token Deletion - Potential Authorization Bypass (CVE-2026-55867)
id: 12a4d5a6-3c2b-4e7a-9f1c-2d5b8e7c9a1f
status: experimental
description: Detects DELETE requests to Graylog user token endpoints where the userId in the path does not match the authenticated user performing the request.
references:
    - https://nvd.nist.gov/vuln/detail/CVE-2026-55867
author: Valtersit Threat Intelligence
date: 2026/03/10
tags:
    - attack.initial-access
    - attack.t1190
logsource:
    category: webserver
    product: graylog
    definition: Requires Graylog web/API access logs or a reverse proxy that logs HTTP method, URI, and authenticated username.
detection:
    selection:
        cs-method: 'DELETE'
        cs-uri-path: '/users/*/tokens/*'
    filter_valid:
        cs-username: '*'
    condition: selection and not filter_valid
fields:
    - cs-uri-path
    - cs-username
    - src_ip
falsepositives:
    - Legitimate admin deleting tokens of users they manage (where the admin has explicit permission on the target user).
level: high

YARA Rule

rule Graylog_CVE_2026_55867_Token_Deletion_ABUSE {
    meta:
        author = "Valtersit Threat Intelligence"
        date = "2026-03-10"
        description = "Detects HTTP DELETE request patterns targeting Graylog user token revocation endpoints - used in CVE-2026-55867 exploitation"
        reference = "https://nvd.nist.gov/vuln/detail/CVE-2026-55867"
        cve = "CVE-2026-55867"
        severity = "high"
    strings:
        $method = "DELETE" ascii wide nocase
        $path_part1 = "/users/" ascii wide nocase
        $path_part2 = "/tokens/" ascii wide nocase
    condition:
        $method at 0 and $path_part1 and $path_part2
}

Suricata IDS Rule

alert http any any -> $GRAYLOG_SERVERS any (msg:"ET EXPLOIT Graylog CVE-2026-55867 Token Deletion Authorization Bypass Attempt"; flow:established,to_server; http.method; content:"DELETE"; http.uri; content:"/users/"; http.uri; content:"/tokens/"; distance:0; classtype:attempted-admin; sid:202658867; rev:1; metadata:created_at 2026_03_10, updated_at 2026_03_10, cve CVE-2026-55867;)

Elastic Detection

sequence by source.ip with maxspan=1m
  [http where http.request.method == "DELETE" and http.request.uri like "/users/*/tokens/*"]

Splunk SPL Query

index=proxy OR index=web
| where method="DELETE" AND match(uri, "^/users/.+/tokens/.+$")
| table _time, src_ip, user, uri, status
| sort _time desc

Wazuh OSSEC Rule

<group name="graylog,">
  <rule id="625842" level="12">
    <decoded_as>web</decoded_as>
    <match>DELETE /users/</match>
    <regex>/tokens/</regex>
    <description>Graylog CVE-2026-55867: DELETE request to token revocation endpoint (potential authorization bypass)</description>
    <group>graylog,web_application_attack,</group>
    <mitre>
      <id>T1190</id>
    </mitre>
  </rule>
</group>

Mitigation & Patch Guidance

Patch Confidence: 0/4 (UNPATCHED — no patch evidence from any tracked source). While the NVD description states fixes exist in versions 6.3.12, 7.0.7, and 7.1.2, no patch evidence was found from any tracked source at the time of analysis.

1) Immediate Mitigations (apply now)

• Upgrade Graylog to a fixed version (6.3.12, 7.0.7, or 7.1.2) if available in your environment's update channel. Verify the vendor advisory through official Graylog channels before deploying.
• Restrict the USERS_TOKENREMOVE permission to only administrative accounts that absolutely require it. Reduce the number of principals holding this permission to minimize the attack surface.
• Implement network-level access control on the Graylog REST API to restrict access to trusted hosts/IP ranges only. Use a reverse proxy or firewall rules to limit who can reach the API endpoint.
• Monitor token usage patterns. If token deletion events spike, treat it as a potential exploitation indicator.
• Enable audit logging on Graylog and integrate those logs into a SIEM with alerts for DELETE requests to the token endpoint.

2) Patch / Upgrade Steps

• Plan a maintenance window to upgrade to the latest patched version (6.3.12, 7.0.7, or 7.1.2) as soon as the vendor releases official packages or advisories confirm these builds.
• Before upgrade, back up the Graylog configuration, Elasticsearch/OpenSearch indices, and MongoDB database.
• Verify all installed Graylog plugins and integrations are compatible with the target version before upgrading.
• After upgrade, validate that token revocation functionality behaves correctly — specifically that a user cannot delete tokens belonging to other users.

3) Long-Term Hardening

• Adopt least-privilege principles for all Graylog roles and permissions. Regularly audit role assignments.
• Implement segregation of duties — separate the user-management role from other administrative functions.
• Use dedicated service accounts for integrations, with narrowly scoped roles, and rotate tokens on a defined schedule.
• Ensure Graylog API endpoints are not directly exposed to the internet; place them behind a VPN, bastion host, or zero-trust access proxy.
• Establish a vulnerability management process that tracks Graylog security advisories and applies patches within established SLAs.
• Retain the ability to rapidly re-provision tokens for integrations so that token loss incidents can be remediated quickly.

References

1. NVD Entry: https://nvd.nist.gov/vuln/detail/CVE-2026-55867
2. Graylog Official Site: https://www.graylog.org/
3. Graylog GitHub Repository: https://github.com/Graylog2/graylog2-server
4. MITRE ATT&CK T1190: https://attack.mitre.org/techniques/T1190/
5. CWE-639 (Authorization Bypass Through User-Controlled Key): https://cwe.mitre.org/data/definitions/639.html

Threat Actor Campaigns / Exploit-in-the-Wild: As of this report, no threat actor campaigns or exploit-in-the-wild evidence have been identified for CVE-2026-55867. The vulnerability is not listed in CISA's Known Exploited Vulnerabilities (KEV) catalog. However, given the low exploitation complexity and the broad deployment footprint of Graylog, security teams should treat this as a high-priority patching item and monitor for active exploitation.