CVE-2026-81034: Netmaker Information Disclosure Vulnerability

CVE-2026-81034 Overview

Netmaker disables TLS certificate verification on connections to its configured mail server. The sender in pro/email/smtp.go unconditionally sets the InsecureSkipVerify field of the TLS configuration to true, directly beneath a comment stating the value should be false in production. No configuration option controls the setting and no code path restores verification. The client accepts any certificate the mail server presents, including one supplied by an interposing party. The flaw is tracked as improper certificate validation [CWE-295].

Critical Impact
An attacker positioned between Netmaker and its mail relay can intercept password-reset messages containing single-use tokens and user invitations carrying enrolment links, then use captured tokens before the intended recipient.

Affected Products

Netmaker through version 1.6.0 (release branch)
Netmaker pro/email/smtp.go SMTP sender component
Netmaker deployments relying on external SMTP relays for account management email

Discovery Timeline

2026-08-26 - CVE-2026-81034 published to NVD
2026-08-26 - Last updated in NVD database

Technical Details for CVE-2026-81034

Vulnerability Analysis

Netmaker uses an SMTP client to deliver operational email, including password resets and user invitations. The client is instantiated in pro/email/smtp.go with a tls.Config whose InsecureSkipVerify field is set to true. The setting bypasses the standard Go TLS handshake checks that validate the server certificate chain and hostname against the configured certificate authorities.

Because verification is disabled, the client establishes a TLS session with any peer that answers on the configured host and port. An attacker performing a man-in-the-middle attack on the network path between the Netmaker server and its SMTP relay can present a self-signed or unrelated certificate. The Netmaker client will accept it and transmit message contents inside the attacker-terminated tunnel.

The intercepted messages include password-reset emails carrying single-use tokens and invitations carrying enrolment links. An attacker who reads a reset token before the legitimate user can complete the reset flow and take over the target account, gaining access to the Netmaker control plane and the WireGuard networks it manages.

Root Cause

The root cause is a hardcoded insecure TLS configuration in pro/email/smtp.go. The InsecureSkipVerify value is set to true unconditionally, with no configuration key, environment variable, or code path that restores certificate validation. A comment beside the assignment notes the value should be false in production, indicating a debugging setting was shipped in the release branch. The setting is absent from the development branch but present in the latest release.

Attack Vector

Exploitation requires network-adjacent positioning on the path between the Netmaker server and its SMTP relay. Techniques include ARP spoofing on a shared segment, BGP or DNS hijacking of the relay hostname, or compromise of an upstream router. Once positioned, the attacker terminates the TLS session with any certificate and forwards or logs the plaintext SMTP traffic. Password-reset tokens transmitted in email bodies are then replayed against the Netmaker web interface.

See the VulnCheck Advisory on Netmaker and the GitHub Netmaker SMTP Code for source-level detail.

Detection Methods for CVE-2026-81034

Indicators of Compromise

Password resets completed from IP addresses that differ from the requesting user's typical source range or geolocation.
SMTP TLS sessions from the Netmaker host terminating on unexpected peers, or presenting certificates not issued by the mail relay's known certificate authority.
Netmaker account changes (role escalation, key rotation, peer additions) shortly after a password-reset email was sent.
Invitation enrolment links redeemed by clients that do not match the invited user's expected device fingerprint.

Detection Strategies

Inspect outbound SMTP traffic from the Netmaker server and alert on TLS handshakes where the server certificate fails validation against the expected relay's trust chain.
Correlate password_reset_requested and password_reset_completed events in Netmaker logs and flag completions from a different source IP or user agent than the request.
Monitor for repeated short-lived TLS sessions to the SMTP relay port that use unusual cipher suites or self-signed certificates.

Monitoring Recommendations

Forward Netmaker application logs and host network telemetry into a centralized analytics platform and retain SMTP connection metadata for at least 90 days.
Baseline the certificate fingerprint of the configured mail relay and alert on any deviation observed from the Netmaker host.
Track administrator role assignments and API token creation events immediately following authentication changes.

How to Mitigate CVE-2026-81034

Immediate Actions Required

Restrict egress from the Netmaker server so that SMTP traffic can only reach the intended mail relay by IP and port.
Rotate any password-reset tokens, invitation links, and administrator credentials issued while the vulnerable release was in production.
Review Netmaker audit logs for unexpected password resets, new administrator accounts, or peer additions since the vulnerable version was deployed.

Patch Information

At the time of publication, no fixed release identifier is listed in NVD. The insecure setting is absent from the Netmaker development branch, indicating that upstream has already removed it in-tree. Track the GitHub Netmaker Repository and the GitHub Netmaker Issue Discussion for the release that ships the corrected pro/email/smtp.go. Once available, upgrade to that release and redeploy.

Workarounds

Route Netmaker SMTP traffic through a trusted local relay reachable over the loopback interface or a private network segment, removing the man-in-the-middle attack surface.
Deliver password-reset and invitation notifications through an out-of-band channel until a fixed release is installed.
If a code patch is acceptable, build Netmaker from a source tree with InsecureSkipVerify set to false in pro/email/smtp.go and pin the deployment to that build.

bash

# Configuration example: restrict Netmaker egress to the known mail relay only
# Replace <MAIL_RELAY_IP> and <PORT> with the values used by your deployment
iptables -A OUTPUT -o eth0 -p tcp -d <MAIL_RELAY_IP> --dport <PORT> -j ACCEPT
iptables -A OUTPUT -o eth0 -p tcp --dport 25  -j REJECT
iptables -A OUTPUT -o eth0 -p tcp --dport 465 -j REJECT
iptables -A OUTPUT -o eth0 -p tcp --dport 587 -j REJECT