CVE-2026-38651: Netmaker Auth Bypass Vulnerability

CVE-2026-38651 Overview

An Authentication Bypass vulnerability exists in Netmaker versions prior to 1.5.0. The VerifyHostToken function in logic/jwts.go fails to validate the JWT signature when verifying host tokens. An attacker can forge a JWT signed with any arbitrary key and use it to impersonate any host in the network, gaining access to sensitive information.

Critical Impact

This vulnerability allows remote attackers to forge JWT tokens and impersonate any host on the network without authentication, potentially compromising the entire network infrastructure managed by Netmaker.

Affected Products

• Netmaker versions prior to 1.5.0
• Netmaker deployments using JWT-based host authentication
• Network environments relying on Netmaker for mesh networking

Discovery Timeline

• 2026-04-28 - CVE CVE-2026-38651 published to NVD
• 2026-04-28 - Last updated in NVD database

Technical Details for CVE-2026-38651

Vulnerability Analysis

This vulnerability falls under CWE-347 (Improper Verification of Cryptographic Signature). The core issue lies in the VerifyHostToken function within logic/jwts.go, which parses JWT tokens but fails to verify whether the token's signature is actually valid before trusting its claims.

When the JWT library parses a token, it returns a token object regardless of signature validity—the signature validation result is stored in the token.Valid boolean field. The vulnerable code only checked if the token object was non-nil (token != nil) before extracting and returning the claims, completely bypassing the cryptographic signature verification that should protect against token forgery.

This architectural flaw means an attacker can craft a JWT with arbitrary claims (including spoofed host identity information) signed with any key of their choosing, and the server will accept it as legitimate.

Root Cause

The root cause is the missing validation check for token.Valid in the JWT verification logic. The original code in logic/jwts.go contained the following conditional:

if token != nil {
    return claims.ID, claims.MacAddress, claims.Network, nil
}

This check only verifies that the token was successfully parsed, not that its cryptographic signature was validated against the server's secret key. The JWT library's ParseWithClaims function sets token.Valid to true only when the signature verification succeeds, but this field was never checked.

Attack Vector

This vulnerability is exploitable over the network without any authentication or user interaction. An attacker can exploit this vulnerability through the following attack flow:

1. Craft a malicious JWT containing claims for any target host identity
2. Sign the JWT with any arbitrary key (the signature will not be validated)
3. Send API requests to the Netmaker server using the forged token
4. Successfully impersonate the target host and access sensitive network configuration data

The patched code properly validates the JWT signature:

// Patched version from logic/jwts.go
// Source: https://github.com/gravitl/netmaker/commit/5309aa70d464ef565911369714d661a61481a79b

 	// this may be a stupid way of serving up a master key
 	// TODO: look into a different method. Encryption?
 	if tokenString == servercfg.GetMasterKey() && servercfg.GetMasterKey() != "" {
-		return "mastermac", "", "", nil
+		return MasterUser, "", "", nil
 	}

 	token, err := jwt.ParseWithClaims(tokenString, claims, func(token *jwt.Token) (interface{}, error) {
 		return jwtSecretKey, nil
 	})

-	if token != nil {
+	if token != nil && token.Valid {
 		return claims.ID, claims.MacAddress, claims.Network, nil
 	}
 	return "", "", "", err

Additionally, the host authorization middleware was updated in controllers/hosts.go:

// Patched version from controllers/hosts.go
// Source: https://github.com/gravitl/netmaker/commit/5309aa70d464ef565911369714d661a61481a79b

 	r.HandleFunc("/api/hosts/{hostid}", logic.SecurityCheck(true, http.HandlerFunc(updateHost))).
 		Methods(http.MethodPut)
-	r.HandleFunc("/api/hosts/{hostid}", Authorize(true, false, "all", http.HandlerFunc(deleteHost))).
+	r.HandleFunc("/api/hosts/{hostid}", AuthorizeHost(http.HandlerFunc(deleteHost))).
 		Methods(http.MethodDelete)
 	r.HandleFunc("/api/hosts/{hostid}/upgrade", logic.SecurityCheck(true, http.HandlerFunc(upgradeHost))).
 		Methods(http.MethodPut)

Detection Methods for CVE-2026-38651

Indicators of Compromise

• Unexpected host registrations or modifications in Netmaker network configurations
• API requests containing JWT tokens with invalid or anomalous signatures in server logs
• Multiple hosts attempting to use the same identity credentials
• Unusual network configuration changes or access patterns from hosts

Detection Strategies

• Implement JWT signature validation logging to detect tokens that fail signature verification
• Monitor Netmaker API endpoints for authentication anomalies, particularly the /api/hosts/{hostid} endpoints
• Analyze server logs for requests with malformed or suspicious JWT structures
• Deploy network intrusion detection rules to identify JWT authentication bypass attempts

Monitoring Recommendations

• Enable verbose logging on Netmaker API servers to capture all authentication events
• Set up alerts for failed JWT signature verifications or authentication anomalies
• Monitor for unusual host activity patterns that may indicate impersonation
• Implement regular audits of registered hosts against expected network inventory

How to Mitigate CVE-2026-38651

Immediate Actions Required

• Upgrade Netmaker to version 1.5.0 or later immediately
• Review Netmaker server logs for any suspicious authentication activity
• Audit all registered hosts in your Netmaker deployment for unauthorized entries
• Rotate JWT secret keys after applying the patch to invalidate any potentially forged tokens

Patch Information

The vulnerability has been addressed in Netmaker version 1.5.0. The fix adds proper JWT signature validation by checking the token.Valid field before trusting token claims. The patch is available in commit 5309aa70d464ef565911369714d661a61481a79b. Additional details are available in the Zyenra Security Advisory and Zyenra Blog Post.

Workarounds

• Restrict network access to Netmaker API endpoints using firewall rules or network segmentation
• Implement additional authentication layers (VPN, IP allowlisting) in front of Netmaker services
• Monitor and alert on all host registration and modification activities until patching is complete
• Consider temporarily disabling external API access if immediate patching is not possible

# Configuration example - Restrict API access via iptables
# Only allow trusted IP ranges to access Netmaker API
iptables -A INPUT -p tcp --dport 8081 -s 10.0.0.0/8 -j ACCEPT
iptables -A INPUT -p tcp --dport 8081 -j DROP

# Verify current Netmaker version
docker exec netmaker cat /root/netmaker.version