CVE-2026-27624: 
NixOS vulnerability analysis and mitigation

CVE-2026-27624 is an access control bypass vulnerability in Coturn, a free open-source TURN/STUN server implementation, caused by improper handling of IPv4-mapped IPv6 addresses (the ::ffff:0:0/96 range). It represents an incomplete fix for CVE-2020-26262, which previously addressed loopback bypasses via 0.0.0.0, [::1], and [::]. All Coturn versions prior to 4.9.0 are affected. The vulnerability was disclosed on February 25, 2026, with a CVSS v3.1 score of 6.5 (Medium) per NVD, or 7.2 (High) per the GitHub Security Advisory using a scope-changed vector (GitHub Advisory).

The root cause lies in three functions within src/client/ns_turn_ioaddr.c that fail to check the IN6_IS_ADDR_V4MAPPED macro before performing address comparisons (CWE-284: Improper Access Control; CWE-441: Unintended Proxy or Intermediary). Specifically: ioa_addr_is_loopback() does not detect ::ffff:127.0.0.1; ioa_addr_is_zero() does not detect ::ffff:0.0.0.0; and addr_less_eq() (used by ioa_addr_in_range() for denied-peer-ip matching) returns 0 without extracting the embedded IPv4 when the range is AF_INET and the peer is AF_INET6. An unauthenticated attacker can send a CreatePermission or ChannelBind TURN request with an XOR-PEER-ADDRESS value such as ::ffff:127.0.0.1, bypassing configured denied-peer-ip rules for any IPv4 range. The fix in version 4.9.0 adds IN6_IS_ADDR_V4MAPPED checks and IPv4 extraction logic to all three affected functions (GitHub Advisory, Patch Commit).

Successful exploitation allows an attacker to bypass denied-peer-ip ACL rules and default loopback protections, enabling unauthorized access to internal network ranges including loopback (::ffff:127.0.0.1), link-local (::ffff:169.254.169.254), and RFC1918 private ranges (::ffff:10.0.0.1, ::ffff:192.168.1.1, etc.). This can expose internal services — such as metadata APIs, administrative interfaces, or other restricted endpoints — that operators intended to be inaccessible via the TURN relay. Actual data relay success depends on whether the relay socket is wildcard-bound (::) versus bound to a specific IPv6 address, but the ACL bypass itself constitutes a policy violation regardless of relay outcome (GitHub Advisory).

A public proof-of-concept Python script (coturn_v4mapped_bypass_poc.py) is referenced in the GitHub Security Advisory, demonstrating the bypass against Coturn 4.8.0. The vulnerability requires no authentication and no user interaction, making it trivially exploitable from the network. There is no evidence of in-the-wild exploitation at this time, and it is not listed in the CISA KEV catalog. The EPSS score is approximately 0.026% (0.000260), indicating low current exploitation probability (GitHub Advisory).

1. Reconnaissance: Identify internet-facing Coturn TURN/STUN servers (default port 3478/UDP or TCP) running versions prior to 4.9.0 using tools like Shodan or Censys.
2. Obtain TURN credentials: Acquire valid TURN credentials (e.g., via a WebRTC application that uses the Coturn server, or through credential brute-forcing if the server uses weak credentials).
3. Allocate an IPv6 relay: Send a TURN ALLOCATE request to obtain an IPv6 relay address on the server.
4. Send bypass request: Issue a CreatePermission or ChannelBind request with the XOR-PEER-ADDRESS attribute set to an IPv4-mapped IPv6 address such as ::ffff:127.0.0.1 (loopback), ::ffff:169.254.169.254 (cloud metadata), or ::ffff:10.0.0.1 (RFC1918 internal).
5. Confirm bypass: Observe a successful 200 OK response instead of the expected 403 Forbidden IP, confirming the denied-peer-ip ACL has been bypassed.
6. Relay traffic: If the relay socket is wildcard-bound (::) on the server, use the established TURN channel to relay traffic to the previously blocked internal address, potentially accessing internal HTTP services, metadata APIs, or other restricted resources (GitHub Advisory).

• Network: TURN CreatePermission or ChannelBind requests containing XOR-PEER-ADDRESS values in the ::ffff:0.0.0.0/96 range (e.g., ::ffff:127.0.0.1, ::ffff:169.254.169.254, ::ffff:10.x.x.x, ::ffff:192.168.x.x, ::ffff:172.16.x.x) on port 3478 (UDP/TCP).
• Logs: Coturn server logs showing CREATE_PERMISSION processed, success or CHANNEL_BIND processed, success for peer addresses matching ::ffff:* patterns that correspond to blocked IPv4 ranges; absence of expected error 403: Forbidden IP log entries for these addresses.
• Logs: Coturn session logs with entries like peer ::ffff:127.0.0.1 lifetime updated or peer ::ffff:169.254.169.254 lifetime updated indicating successful permission grants to internal addresses (GitHub Advisory).

Upgrade Coturn to version 4.9.0 or later, which contains the updated fix addressing the IPv4-mapped IPv6 bypass (Patch Commit). As an immediate workaround prior to patching, add an explicit deny rule for the entire IPv4-mapped IPv6 range to the Coturn configuration: denied-peer-ip=::ffff:0.0.0.0-::ffff:255.255.255.255. Additionally, consider implementing network-level firewall rules to restrict access to the Coturn server and limit relay destinations to only necessary ranges (GitHub Advisory).

The vulnerability was reported by researcher tr1xster-sec and published via GitHub Security Advisory on February 23, 2026. Enable Security, a firm specializing in real-time communications security, published a Coturn security configuration guide and discussed the issue on Mastodon (infosec.exchange). The security community noted this as a recurring pattern of incomplete fixes for TURN server SSRF-style bypasses, referencing the lineage from CVE-2020-26262. Fedora and openSUSE issued package updates for Coturn 4.9.0 shortly after disclosure (GitHub Advisory).