Miggo Logo

CVE-2025-53106:
Graylog vulnerable to privilege escalation through API tokens

8.8

CVSS Score

Basic Information

EPSS Score
-
Published
6/30/2025
Updated
6/30/2025
KEV Status
No
Technology
TechnologyJava

Technical Details

CVSS Vector
CVSS:4.0/AV:N/AC:L/AT:P/PR:L/UI:A/VC:H/VI:H/VA:H/SC:H/SI:H/SA:H/E:X/CR:X/IR:X/AR:X/MAV:X/MAC:X/MAT:X/MPR:X/MUI:X/MVC:X/MVI:X/MVA:X/MSC:X/MSI:X/MSA:X/S:X/AU:X/R:X/V:X/RE:X/U:X
Package NameEcosystemVulnerable VersionsFirst Patched Version
org.graylog2:graylog2-servermaven>= 6.2.0, < 6.2.46.2.4
org.graylog2:graylog2-servermaven>= 6.3.0-alpha.1, < 6.3.0-rc.26.3.0-rc.2

Vulnerability Intelligence
Miggo AIMiggo AI

Miggo AIRoot Cause Analysis

The vulnerability is a classic case of improper authorization. The system correctly authenticated the user and checked if they had the permission USERS_TOKENCREATE, but it failed to properly authorize the action of creating a token for another user. The flaw was in the generateNewToken function within UsersResource.java. The permission check isPermitted(USERS_TOKENCREATE, currentUser.getName()) only validated that the user making the request could create tokens in general, based on their own identity. It did not validate if they were allowed to create a token for the user specified by userId.

An attacker with a low-privilege account could exploit this by making a request to the /api/users/{user_id}/tokens/{token_name} endpoint, where {user_id} is the ID of a privileged account like 'admin'. Because the permission check was flawed, the system would proceed to generate a new API token for the administrator and return it to the attacker. The attacker could then use this token to perform actions with administrative privileges.

The patch corrects this by changing the permission check to isPermitted(USERS_TOKENCREATE, futureOwner.getName()). This ensures that the permission check is scoped to the user for whom the token is being created (futureOwner), effectively preventing a user from creating a token for another user unless they have been explicitly granted that permission (e.g., users:tokencreate:admin).

Vulnerable functions

org.graylog2.rest.resources.users.UsersResource.generateNewToken
graylog2-server/src/main/java/org/graylog2/rest/resources/users/UsersResource.java
The vulnerability is in the `generateNewToken` function. The original code checked if the currently authenticated user (`currentUser`) had permission to create a token, but it checked this permission against the current user's own name (`currentUser.getName()`). This meant that any user who was permitted to create tokens for themselves could create a token for any other user, including an administrator, by specifying the victim's `userId` in the API request. The patch fixes this by changing the permission check to be against the `futureOwner.getName()`, ensuring the check is made against the user for whom the token is being created.

WAF Protection Rules

WAF Rule

### Imp**t *r*ylo* us*rs **n **in *l*v*t** privil***s *y *r**tin* *n* usin* *PI tok*ns *or t** lo**l **ministr*tor or *ny ot**r us*r *or w*om t** m*li*ious us*r knows t** I*. *or t** *tt**k to su*****, t** *tt**k*r n***s * us*r ***ount in *r*ylo*.

Reasoning

T** vuln*r**ility is * *l*ssi* **s* o* improp*r *ut*oriz*tion. T** syst*m *orr**tly *ut**nti**t** t** us*r *n* ****k** i* t**y *** t** p*rmission `US*RS_TOK*N*R**T*`, *ut it **il** to prop*rly *ut*oriz* t** **tion o* *r**tin* * tok*n *or **not**r* us