# CVE-2026-55867: Graylog token revocation endpoint allows authenticated users to delete other users’ access tokens

> Authenticated users can delete other users' access tokens due to missing ownership checks, disrupting integrations and causing denial of service.

- **Severity:** Medium 5.3 (`CVSS:4.0/AV:N/AC:L/AT:N/PR:L/UI:N/VC:N/VI:L/VA:L/SC:N/SI:N/SA:N`)
- **Exploited in the wild:** Not known
- **Login needed:** Any signed-in user
- **Attackable:** Over the internet
- **Victim action needed:** Not needed
- **Fix available:** Yes
- **Published:** 28 Aug 2026
- **Updated:** 31 Aug 2026
- **Also known as:** GHSA-j769-9gv9-65gr

## What is CVE-2026-55867?

CVE-2026-55867 is a medium-severity missing authorization vulnerability in graylog2-server, published on 28 Aug 2026. Any signed-in user can exploit it over the network, with no action from the victim.

### Official description

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.

Weakness: CWE-639 (Authorization Bypass Through User-Controlled Key)

## Which versions are affected by CVE-2026-55867?

6 open source packages ship an affected version, including org.graylog2:graylog2-server.


| Package | Ecosystem | Affected | Fixed in |
| --- | --- | --- | --- |
| `org.graylog2:graylog2-server` | Maven | From 6.2.0 | 6.3.12 |
| `org.graylog2:graylog2-server` | Maven | From 6.2.0 | 6.3.12 |
| `org.graylog2:graylog2-server` | Maven | From 7.0.0 | 7.0.7 |
| `org.graylog2:graylog2-server` | Maven | From 7.0.0 | 7.0.7 |
| `org.graylog2:graylog2-server` | Maven | From 7.1.0 | 7.1.2 |
| `org.graylog2:graylog2-server` | Maven | From 7.1.0 | 7.1.2 |

## How do I fix CVE-2026-55867?

Upgrade org.graylog2:graylog2-server to a fixed version for your release line: 6.3.12, 7.0.7 or 7.1.2.

## Is CVE-2026-55867 being exploited?

There is no known exploitation of CVE-2026-55867 in the wild and no public exploit code.

## Fix prompt for AI coding agents

```text
Check this codebase for CVE-2026-55867 and fix it if it is affected.

What it is: CVE-2026-55867 is a medium-severity missing authorization vulnerability in graylog2-server, published on 28 Aug 2026. Any signed-in user can exploit it over the network, with no action from the victim.
Exploitation: There is no known exploitation of CVE-2026-55867 in the wild and no public exploit code.

Affected packages and fixed versions:
- org.graylog2:graylog2-server (Maven): affected from 6.2.0; fixed in 6.3.12
- org.graylog2:graylog2-server (Maven): affected from 6.2.0; fixed in 6.3.12
- org.graylog2:graylog2-server (Maven): affected from 7.0.0; fixed in 7.0.7
- org.graylog2:graylog2-server (Maven): affected from 7.0.0; fixed in 7.0.7
- org.graylog2:graylog2-server (Maven): affected from 7.1.0; fixed in 7.1.2
- org.graylog2:graylog2-server (Maven): affected from 7.1.0; fixed in 7.1.2

Task:
1. Search the dependency manifests and lockfiles (for example package.json, package-lock.json, requirements.txt, poetry.lock, uv.lock, pom.xml, build.gradle, go.mod, Cargo.lock, Gemfile.lock) and any Dockerfiles for the affected packages, including transitive dependencies.
2. If an affected version is in use, upgrade it to the fixed version for its release line with the project's package manager, so the lockfile is regenerated. Prefer the smallest upgrade that fixes it.
3. If there is no fix, or the upgrade would break the build, do not guess: explain the risk and the safest workaround instead.
4. Run the tests and summarise what changed and why.
5. If nothing in the project is affected, say so and change nothing.

Reference: https://insights.sbomify.com/CVE-2026-55867/ (Markdown: https://insights.sbomify.com/CVE-2026-55867/index.md)
```

## Sources

- CVE record: https://www.cve.org/CVERecord?id=CVE-2026-55867
- NVD: https://nvd.nist.gov/vuln/detail/CVE-2026-55867
- OSV: https://osv.dev/vulnerability/CVE-2026-55867

---
From sbomify Insights: https://insights.sbomify.com/CVE-2026-55867/
Summaries are generated and may contain mistakes; the official description above is the record.