Summary
Netmaker contains an authorization bypass in the external-client update handler that may allow a user authorized for one network to modify clients belonging to another network. Under deployments where network-scoped permissions are not enforced on the requested resource, an attacker could replace public keys, disable external clients, or obtain WireGuard private keys.
Netmaker contains an authorization bypass in the external-client update handler that may allow a user authorized for one network to modify clients belonging to another network. Under deployments where network-scoped permissions are not enforced on the requested resource, an attacker could replace public keys, disable external clients, or obtain WireGuard private keys.
Affected context
The issue occurs in Netmaker deployments using the external-client API and relying on network-scoped authorization. It becomes risky when the update handler accepts a network or client identifier without verifying that the authenticated user is authorized for the specific target network and resource.
The issue occurs in Netmaker deployments using the external-client API and relying on network-scoped authorization. It becomes risky when the update handler accepts a network or client identifier without verifying that the authenticated user is authorized for the specific target network and resource.
Exploit preconditions
- Attack surface: The external-client update API at
/api/extclients/{network}/{clientid} - Required access: Permissions to manage external clients on at least one network
- Trigger point: A PUT request targeting an external client associated with another network
- Why exploitation is possible: The handler may authorize the caller's general external-client capability without binding authorization checks to the requested network and client
- Attack surface: The external-client update API at
/api/extclients/{network}/{clientid} - Required access: Permissions to manage external clients on at least one network
- Trigger point: A PUT request targeting an external client associated with another network
- Why exploitation is possible: The handler may authorize the caller's general external-client capability without binding authorization checks to the requested network and client
Why this happens
The underlying bug is an authorization decision that does not consistently enforce object ownership or network scope. A user with valid permissions in one network can cause the update handler to act on a resource in another network when the requested identifiers are not checked against the caller's authorized scope. This maps to CWE-639: Authorization Bypass Through User-Controlled Key, where user-controlled resource keys influence access decisions without adequate authorization validation.
The underlying bug is an authorization decision that does not consistently enforce object ownership or network scope. A user with valid permissions in one network can cause the update handler to act on a resource in another network when the requested identifiers are not checked against the caller's authorized scope. This maps to CWE-639: Authorization Bypass Through User-Controlled Key, where user-controlled resource keys influence access decisions without adequate authorization validation.
Potential impact
- Attackers may alter external-client public keys
- External clients could be disabled, disrupting network connectivity
- WireGuard private keys may be exposed
- An attacker could impersonate clients or intercept network traffic
- Unauthorized changes may affect multiple network environments
- Attackers may alter external-client public keys
- External clients could be disabled, disrupting network connectivity
- WireGuard private keys may be exposed
- An attacker could impersonate clients or intercept network traffic
- Unauthorized changes may affect multiple network environments
General mitigation guidance
Mitigation generally focuses on enforcing authorization at the resource and network boundary rather than relying on broad endpoint permissions.
Common defensive patterns include:
- Resolve the target client and network server-side, then verify ownership and scope before every update
- Avoid trusting network or client identifiers supplied by the caller as authorization evidence
- Apply deny-by-default, least-privilege policies for network administration
- Separate read, update, disable, and key-management permissions
- Protect private keys through restricted storage, redaction, and narrowly scoped access
- Use consistent authorization middleware and centralized policy decisions across related endpoints
Mitigation generally focuses on enforcing authorization at the resource and network boundary rather than relying on broad endpoint permissions.
Common defensive patterns include:
- Resolve the target client and network server-side, then verify ownership and scope before every update
- Avoid trusting network or client identifiers supplied by the caller as authorization evidence
- Apply deny-by-default, least-privilege policies for network administration
- Separate read, update, disable, and key-management permissions
- Protect private keys through restricted storage, redaction, and narrowly scoped access
- Use consistent authorization middleware and centralized policy decisions across related endpoints
How teams detect issues like this
Organizations can look for:
- Static analysis and code review checks that compare authenticated scope with user-supplied resource identifiers
- API tests attempting cross-network reads, updates, and disable operations using otherwise valid accounts
- Audit-log searches for external-client changes made across network boundaries
- Policy checks requiring explicit resource-level authorization before mutation or key retrieval
- Automated security testing that exercises horizontal privilege escalation scenarios
Organizations can look for:
- Static analysis and code review checks that compare authenticated scope with user-supplied resource identifiers
- API tests attempting cross-network reads, updates, and disable operations using otherwise valid accounts
- Audit-log searches for external-client changes made across network boundaries
- Policy checks requiring explicit resource-level authorization before mutation or key retrieval
- Automated security testing that exercises horizontal privilege escalation scenarios
