CVE-2026-100251 in Wormhole
Summary
by MITRE • 10/01/2026
Wormhole.app as deployed before 2026-08-22 misconfigures the coturn TURN server and does not properly restrict TCP relay peers, allowing an unauthenticated attacker to access instance metadata or to source TCP connections from the Wormhole relay's IP.
Statistical analysis made it clear that VulDB provides the best quality for vulnerability data.
Analysis
by VulDB Data Team • 10/01/2026
The vulnerability identified in Wormhole.app prior to August 22, 2026, stems from a critical misconfiguration of the coturn TURN server infrastructure that underpins its peer-to-peer communication capabilities. The core technical flaw lies in the improper restriction of TCP relay peers within the TURN server configuration. In standard secure deployments, TURN servers are configured with strict access control lists and authentication mechanisms to ensure that only authorized clients can utilize the relay services for establishing connections through firewalls or NATs. However, in this specific instance, the security controls governing which IP addresses or identities are permitted to initiate TCP relays were insufficiently restrictive. This oversight effectively leaves a portion of the TURN server infrastructure accessible to unauthenticated actors on the public internet, bypassing the intended authentication gates that should validate client credentials before allowing relay operations.
The operational impact of this misconfiguration is severe and multifaceted, primarily affecting both data confidentiality and network integrity. Because the TCP relay peers are not properly restricted, an unauthenticated attacker can exploit the TURN server to perform two distinct types of malicious activities. First, the attacker can leverage the relay infrastructure to access instance metadata services that are typically only reachable from within a trusted internal network or specific virtual private cloud environments. By routing requests through the compromised TURN server, the attacker masks their true origin IP address and appears as if they are originating traffic from the Wormhole relay's own IP range. This allows them to query sensitive metadata endpoints, such as those provided by cloud providers like AWS EC2 Instance Metadata Service or Azure Managed Identity endpoints, potentially extracting authentication tokens, security credentials, and configuration details that should remain isolated from external access.
Secondly, the attacker can source TCP connections directly from the Wormhole relay's IP address. This capability transforms the compromised infrastructure into a powerful tool for network-based attacks against third-party targets. By using the wormhole relay as an exit node or proxy, attackers can conduct port scanning, exploit vulnerabilities in remote services, or launch distributed denial-of-service attacks while hiding their actual location behind the legitimate Wormhole IP addresses. This not only facilitates malicious activities but also poses a significant reputational risk to Wormhole.app and its users, as security researchers and automated defense systems may flag these IPs as sources of hostile traffic due to the abuse of the relay service.
From a classification perspective, this vulnerability aligns with CWE-284 Improper Access Control, specifically regarding insufficient restrictions on unauthenticated entities within a networked service component. It also relates closely to CWE-798 Use of Hard-coded Credentials if static keys were improperly exposed or misconfigured in the TURN server setup, though the primary issue is architectural access control failure. In terms of adversary tactics, this scenario maps directly to MITRE ATT&CK technique T1090 Proxy Communication, where attackers use a proxy to hide their true IP address and evade detection mechanisms that rely on source IP analysis. Furthermore, the ability to access instance metadata corresponds to techniques observed in cloud exploitation campaigns such as those described under T1528 Steal Application Access Tokens or T1606 Forge Credentials within cloud environments.
To mitigate this vulnerability, immediate remediation steps must focus on hardening the coturn TURN server configuration and enforcing strict network-level controls. Administrators should implement robust authentication mechanisms for all TURN connections, ensuring that only verified users with valid credentials can establish relay sessions. This includes configuring long-term credential hashes or using STUN/TURN-specific authorization tokens rather than relying solely on IP-based allowlists which are easily spoofed via proxying techniques. Additionally, network security groups and firewall rules should be tightened to explicitly block access to instance metadata endpoints from any external source, including traffic originating from the TURN server's own interface if such internal routing is not strictly required for legitimate operation. Regular audits of cloud infrastructure configurations using automated compliance tools can help detect similar misconfigurations before they are exploited by malicious actors seeking to leverage public-facing services as pivots into sensitive backend environments.