DYNR/netbird
2
0
Fork 0
mirror of https://github.com/netbirdio/netbird.git synced 2026-08-07 02:29:06 -04:00
Code Issues 23.5k Packages Projects Releases 10 Wiki Activity

[GH-ISSUE #4875] Security: Prevent user enumeration by checking authorization before user existence #10304

New Issue
Open
opened 2026-08-05 01:25:20 -04:00 by saavagebueno · 0 comments
saavagebueno commented 2026-08-05 01:25:20 -04:00
Owner
Copy Link

Originally created by @tkloda on GitHub (Nov 29, 2025).
Original GitHub issue: https://github.com/netbirdio/netbird/issues/4875

Summary

The current API endpoints may be vulnerable to user enumeration attacks. The server appears to return different error responses depending on whether a user exists or not, which allows an attacker to discover valid usernames/accounts.

Current Behavior

When an unauthorized request is made to certain endpoints:

  • If the user does not exist → returns one error type (e.g., 404 Not Found)
  • If the user exists but is unauthorized → returns a different error type (e.g., 403 Forbidden)

This difference in responses allows attackers to enumerate valid users by observing the error codes returned.

Expected Behavior

For any unauthorized attempt, the server should:

  1. Perform the authorization check first, before checking if the user/resource exists
  2. Return a consistent error response (e.g., 403 Forbidden or a generic "Access Denied") regardless of whether the user exists

This prevents attackers from learning anything about user existence from the response.

Security Impact

An attacker could use this vulnerability to:

  • Build a list of valid user accounts
  • Target those accounts for credential stuffing or phishing attacks
  • Gain reconnaissance information about the organization

Suggested Fix

In the authentication/authorization middleware, restructure the logic to:

// Pseudocode example
func handleRequest(req Request) Response {
    // 1. Check authorization FIRST
    if !isAuthorized(req) {
        return ForbiddenResponse("Access Denied")  // Generic response
    }
    
    // 2. Only then check if resource/user exists
    user, err := getUser(req.UserID)
    if err != nil {
        return ForbiddenResponse("Access Denied")  // Same generic response
    }
    
    // 3. Process the request
    return processRequest(user, req)
}

Environment

  • NetBird Version: 0.59.13
  • Deployment: Self-hosted
  • Discovered during: Security hardening / penetration testing

Additional Context

This was identified during security hardening of our NetBird deployment. We've already implemented generic error pages at the reverse proxy level (Caddy), but the underlying application logic still reveals user existence through differing response codes.

Originally created by @tkloda on GitHub (Nov 29, 2025). Original GitHub issue: https://github.com/netbirdio/netbird/issues/4875 ## Summary The current API endpoints may be vulnerable to user enumeration attacks. The server appears to return different error responses depending on whether a user exists or not, which allows an attacker to discover valid usernames/accounts. ## Current Behavior When an unauthorized request is made to certain endpoints: - If the user **does not exist** → returns one error type (e.g., 404 Not Found) - If the user **exists but is unauthorized** → returns a different error type (e.g., 403 Forbidden) This difference in responses allows attackers to enumerate valid users by observing the error codes returned. ## Expected Behavior For any unauthorized attempt, the server should: 1. Perform the **authorization check first**, before checking if the user/resource exists 2. Return a **consistent error response** (e.g., `403 Forbidden` or a generic "Access Denied") regardless of whether the user exists This prevents attackers from learning anything about user existence from the response. ## Security Impact - **Attack Type:** User Enumeration - **Severity:** Low to Medium - **OWASP Reference:** [WSTG-IDNT-04 - Testing for Account Enumeration](https://owasp.org/www-project-web-security-testing-guide/latest/4-Web_Application_Security_Testing/03-Identity_Management_Testing/04-Testing_for_Account_Enumeration_and_Guessable_User_Account) An attacker could use this vulnerability to: - Build a list of valid user accounts - Target those accounts for credential stuffing or phishing attacks - Gain reconnaissance information about the organization ## Suggested Fix In the authentication/authorization middleware, restructure the logic to: ``` // Pseudocode example func handleRequest(req Request) Response { // 1. Check authorization FIRST if !isAuthorized(req) { return ForbiddenResponse("Access Denied") // Generic response } // 2. Only then check if resource/user exists user, err := getUser(req.UserID) if err != nil { return ForbiddenResponse("Access Denied") // Same generic response } // 3. Process the request return processRequest(user, req) } ``` ## Environment - NetBird Version: 0.59.13 - Deployment: Self-hosted - Discovered during: Security hardening / penetration testing ## Additional Context This was identified during security hardening of our NetBird deployment. We've already implemented generic error pages at the reverse proxy level (Caddy), but the underlying application logic still reveals user existence through differing response codes.
saavagebueno added the triage-needed label 2026-08-05 01:25:20 -04:00
Sign in to join this conversation.
No Branch/Tag Specified
Branches Tags
Labels
Clear labels
2021 Q4
2021 Q4
2021 Q4
2022 Q1
2022 Q1
2022 Q1
2022 Q1
2022 Q1
2022 Q1
accessibility
accessibility
accessibility
acl
acl
acl
agent
agent
agent
agent
agent
agent
Android
Android
Android
Android
Android
Android
api
api
api
authentik
authentik
authentik
automation
automation
automation
azure
azure
azure
battery-usage
battery-usage
battery-usage
bug
cache
cache
cache
client
client
client
client-ui
client-ui
client-ui
cloud
cloud
cloud
cloud-only
cloud-only
cloud-only
cloudflare
cloudflare
cloudflare
community
community
community
compatibility
compatibility
compatibility
config-idp
config-idp
config-idp
config-issue
config-issue
config-issue
connection
connection
connection
contribution
contribution
contribution
coturn
coturn
coturn
cross-vpn
cross-vpn
cross-vpn
dashboard
dashboard
dashboard
data-usage
data-usage
data-usage
distribution
distribution
distribution
dns
dns
dns
docker
docker
docker
documentation
documentation
documentation
duplicate
duplicate
duplicate
enhancement
enhancement
event-stream
event-stream
event-stream
feature-request
feature-request
feature-request
freebsd
freebsd
freebsd
getting-started
getting-started
getting-started
go
go
go
good first issue
good first issue
good first issue
gui
gui
gui
help wanted
help wanted
help wanted
home-assistant
home-assistant
home-assistant
idp
idp
idp
inconsistency
inconsistency
inconsistency
integration
integration
integration
integrations
integrations
integrations
ios
ios
ios
ipv6
ipv6
ipv6
jwt
jwt
jwt
k8s
k8s
k8s
keycloak
keycloak
keycloak
linux
linux
linux
login
login
login
macos
macos
macos
management-service
management-service
management-service
Medium
Medium
Medium
missing-docs
missing-docs
missing-docs
mobile
mobile
mobile
moved-internal
moved-internal
moved-internal
needs-review
needs-review
needs-review
netbird-ui
netbird-ui
netbird-ui
networking
networking
networking
new-platform
new-platform
new-platform
nginx
nginx
nginx
notification
notification
notification
okta
okta
okta
openwrt
openwrt
openwrt
P2
P2
P2
packaging
packaging
packaging
peer-management
peer-management
peer-management
peer-management
peer-management
peer-management
peer-management
peer-management
peer-management
performance
performance
performance
postgres
postgres
postgres
posture-checks
posture-checks
posture-checks
psk
psk
psk
pull-request
Mirrored from GitHub Pull Request
 question
question
question
refactor
refactor
refactor
relay
relay
relay
release
release
release
rfc
rfc
rfc
routes
routes
routes
security
security
security
security-improvement
security-improvement
security-improvement
security-related
security-related
security-related
self-hosting
self-hosting
self-hosting
server
server
server
signal
signal
signal
sleep-issue
sleep-issue
sleep-issue
ssh
ssh
ssh
ssl
ssl
ssl
status
status
status
store
store
store
synology
synology
synology
system-compatibility-issue
system-compatibility-issue
system-compatibility-issue
test-suite
test-suite
test-suite
third-party-integration
third-party-integration
third-party-integration
triage
triage
triage
triage
triage
triage
triage-needed
triage-needed
triage-needed
troubleshooting
troubleshooting
troubleshooting
UX
UX
UX
waiting-feedback
waiting-feedback
waiting-feedback
windows
windows
windows
wontfix
wontfix
wontfix
zitadel
zitadel
zitadel
No Label triage-needed
Milestone
No items
No Milestone
Projects
Clear projects
No project
Assignees
Clear assignees
dynr-servers saavagebueno
No Assignees
1 Participants
Notifications
Due Date
No due date set.
Dependencies

No dependencies set.

Reference: DYNR/netbird#10304
Delete Branch "%!s()"

Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?