CVE-2026-73212: Coturn Auth Bypass Vulnerability

CVE-2026-73212 Overview

CVE-2026-73212 is an access control weakness [CWE-284] in Coturn, the open source TURN and STUN server used to relay WebRTC and real-time media traffic. Versions prior to 4.13.1 fail to canonicalize IPv4-compatible, 6to4, and NAT64 (64:ff9b::/96) address forms before enforcing peer-IP restrictions. An authenticated relay client using an RFC 6062 TCP CONNECT request can encode a denied IPv4 target inside an IPv6 wrapper and reach it when the Coturn host has a working translation route. The issue is corrected in Coturn 4.13.1.

Critical Impact
Authenticated TURN clients can bypass denied-peer-ip policies and relay traffic to internal or metadata endpoints that operators explicitly blocked.

Affected Products

Coturn TURN/STUN server versions prior to 4.13.1
Deployments accepting authenticated RFC 6062 TCP CONNECT allocations
Coturn hosts with IPv6 translation routes to IPv4 targets

Discovery Timeline

2026-08-11 - CVE-2026-73212 published to NVD
2026-08-11 - Last updated in NVD database

Technical Details for CVE-2026-73212

Vulnerability Analysis

Coturn evaluates peer addresses in good_peer_addr() inside src/server/ns_turn_server.c. That function calls ioa_addr_in_range() from src/client/ns_turn_ioaddr.c to test whether a requested peer falls inside a configured denied-peer-ip range. The comparison operates on the raw address family bytes without normalizing IPv4-in-IPv6 embeddings.

An authenticated client that has established a TCP allocation per RFC 6062 can issue a CONNECT request naming an IPv6 form of a blocked IPv4 host. Because the byte-level comparison sees an AF_INET6 address, the denied IPv4 range never matches. If the Coturn host's kernel has a NAT64, 6to4, or ::ffff: translation route, the outbound relay reaches the target regardless of policy.

The attacker impact is scoped to authenticated users, but it defeats a control that operators rely on to keep the relay off internal networks and cloud metadata services such as 169.254.169.254.

Root Cause

The root cause is missing address canonicalization prior to range enforcement. Three encodings must map to their underlying IPv4 form before comparison: IPv4-compatible (::a.b.c.d), 6to4 (2002::/16), and the well-known NAT64 prefix 64:ff9b::/96. Without normalization, the same host reachable through an IPv6 wrapper is treated as a distinct address family for policy purposes.

Attack Vector

Exploitation requires valid TURN credentials and a Coturn deployment that permits TCP allocations. The attacker requests an allocation, then submits a CONNECT for an IPv6-encoded form of an internal IPv4 target. The server evaluates the denied list, sees no match, and completes the relay if the operating system can route the encoded destination.

// Fix from src/client/ns_turn_ioaddr.c - PR #1947
// Canonicalize IPv4-in-IPv6 encodings, then classify internal ranges
int ioa_addr_is_internal_deny_default(ioa_addr *addr) {
  if (!addr) {
    return 0;
  }
  ioa_addr embedded;
  if (ioa_addr_get_embedded_ipv4(addr, &embedded)) {
    addr = &embedded;
  }
  if (addr->ss.sa_family == AF_INET) {
    const uint8_t *u = ((const uint8_t *)&(addr->s4.sin_addr));
    /* IPv4 link-local 169.254.0.0/16 -- includes 169.254.169.254 */
    if (u[0] == 169 && u[1] == 254) {
      return 1;
    }
  } else if (addr->ss.sa_family == AF_INET6) {
    const uint8_t *u = ((const uint8_t *)&(addr->s6.sin6_addr));
    /* IPv6 link-local fe80::/10 */
    if (u[0] == 0xfe && (u[1] & 0xc0) == 0x80) {
      return 1;
    }
    /* IPv6 unique-local address (ULA) fc00::/7 */
    if ((u[0] & 0xfe) == 0xfc) {
      return 1;
    }
  }
  return 0;
}

Source: GitHub Commit d49ee56

Detection Methods for CVE-2026-73212

Indicators of Compromise

TURN allocation logs showing CONNECT requests whose peer addresses use ::ffff:, 2002::, or 64:ff9b:: prefixes wrapping RFC 1918 or link-local IPv4 space.
Outbound connections from the Coturn host to 169.254.169.254 or other cloud metadata endpoints originated by the relay process.
Successful relay sessions to peers that match documented denied-peer-ip ranges when decoded from their IPv6 form.

Detection Strategies

Parse Coturn session logs and flag any peer address that decodes to an internal or denied IPv4 target after canonicalization.
Correlate authenticated TURN user IDs with outbound flow records to internal subnets from the Coturn host.
Alert on RFC 6062 TCP CONNECT volume spikes from a single credential, which often precedes probing of translation routes.

Monitoring Recommendations

Forward Coturn logs and host netflow into a centralized analytics pipeline with IPv6-aware parsing.
Baseline outbound destinations of the Coturn service and alert on new internal or metadata endpoints.
Review authentication logs for unusual credential reuse across geographies that could indicate credential theft against the relay.

How to Mitigate CVE-2026-73212

Immediate Actions Required

Upgrade Coturn to version 4.13.1 or later, which canonicalizes IPv4-in-IPv6 encodings before peer-IP checks.
Rotate long-lived TURN credentials, especially shared secrets used across multiple clients.
Audit denied-peer-ip and allowed-peer-ip configuration and confirm coverage for both IPv4 and IPv6 forms of sensitive ranges.

Patch Information

The fix ships in Coturn 4.13.1. See GitHub Release 4.13.1, GitHub Pull Request #1945, GitHub Pull Request #1947, and the GitHub Security Advisory GHSA-2x4g-wx24-48m4. Patch commits are cf4b4952 and d49ee56a.

Workarounds

Remove NAT64, 6to4, and IPv4-mapped translation routes from the Coturn host so encoded destinations cannot be delivered.
Add explicit IPv6 entries to denied-peer-ip covering ::ffff:0:0/96, 2002::/16, and 64:ff9b::/96 in addition to IPv4 ranges.
Disable TCP relay allocations (no-tcp-relay) when RFC 6062 CONNECT is not required by the application.

bash

# turnserver.conf - defense-in-depth until 4.13.1 is deployed
no-tcp-relay
denied-peer-ip=10.0.0.0-10.255.255.255
denied-peer-ip=169.254.0.0-169.254.255.255
denied-peer-ip=172.16.0.0-172.31.255.255
denied-peer-ip=192.168.0.0-192.168.255.255
denied-peer-ip=::ffff:0.0.0.0-::ffff:255.255.255.255
denied-peer-ip=2002::-2002:ffff:ffff:ffff:ffff:ffff:ffff:ffff
denied-peer-ip=64:ff9b::-64:ff9b::ffff:ffff