CVE-2026-27624: Coturn Auth Bypass Vulnerability

CVE-2026-27624 Overview

CVE-2026-27624 is an Authorization Bypass vulnerability in Coturn, a free open source implementation of TURN and STUN Server. The vulnerability allows attackers to bypass IP address filtering restrictions using IPv4-mapped IPv6 addresses. While Coturn is commonly configured to block loopback and internal IP ranges using denied-peer-ip and default loopback restrictions, this vulnerability enables attackers to circumvent these protections by sending requests with specially crafted IPv4-mapped IPv6 addresses such as ::ffff:127.0.0.1.

This vulnerability is a bypass of the previously addressed CVE-2020-26262, which had fixed bypasses involving 0.0.0.0, [::1], and [::], but failed to account for IPv4-mapped IPv6 address representations.

Critical Impact

Attackers can bypass network security controls to access loopback interfaces and internal IP ranges that should be restricted, potentially enabling Server-Side Request Forgery (SSRF) attacks against internal services.

Affected Products

• Coturn TURN/STUN Server versions prior to 4.9.0

Discovery Timeline

• 2026-02-25 - CVE-2026-27624 published to NVD
• 2026-02-25 - Last updated in NVD database

Technical Details for CVE-2026-27624

Vulnerability Analysis

The vulnerability exists in three functions within src/client/ns_turn_ioaddr.c that fail to properly check for IPv4-mapped IPv6 addresses using IN6_IS_ADDR_V4MAPPED. When an attacker sends a CreatePermission or ChannelBind request with an XOR-PEER-ADDRESS value of ::ffff:127.0.0.1, the server returns a successful response even when 127.0.0.0/8 is explicitly blocked via the denied-peer-ip configuration.

The improper access control (CWE-284) stems from incomplete address normalization, where the server treats IPv4 addresses and their IPv4-mapped IPv6 equivalents as distinct entities rather than recognizing them as representing the same network endpoint.

Root Cause

The root cause lies in the incomplete implementation of address family handling across three critical functions:

1. ioa_addr_is_loopback() - Checks for 127.x.x.x (AF_INET) and ::1 (AF_INET6), but does not recognize ::ffff:127.0.0.1 as a loopback address
2. ioa_addr_is_zero() - Checks for 0.0.0.0 and ::, but does not account for ::ffff:0.0.0.0
3. addr_less_eq() (used by ioa_addr_in_range()) - When the configured range is AF_INET and the peer address is AF_INET6, the comparison returns 0 without extracting the embedded IPv4 address from the IPv4-mapped IPv6 representation

Attack Vector

The attack is network-based with low complexity and requires no authentication or user interaction. An attacker can exploit this vulnerability by:

1. Establishing a connection to the Coturn server
2. Sending a CreatePermission or ChannelBind TURN request
3. Setting the XOR-PEER-ADDRESS attribute to an IPv4-mapped IPv6 address (e.g., ::ffff:127.0.0.1)
4. Successfully bypassing IP filtering restrictions to reach internal or loopback addresses

The security patch in version 4.9.0 addresses this by extracting the embedded IPv4 address from IPv4-mapped IPv6 addresses before performing range comparisons:

int ioa_addr_in_range(const ioa_addr_range *range, const ioa_addr *addr) {

  if (range && addr) {
    /* If the range is AF_INET and addr is an IPv4-mapped IPv6 address
     * (::ffff:x.x.x.x), extract the embedded IPv4 so the comparison works. */
    ioa_addr addr4;
    if (addr->ss.sa_family == AF_INET6) {
      sa_family_t range_family = range->min.ss.sa_family;
      if (range_family == 0)
        range_family = range->max.ss.sa_family;
      if (range_family == AF_INET && IN6_IS_ADDR_V4MAPPED(&addr->s6.sin6_addr)) {
        memset(&addr4, 0, sizeof(addr4));
        addr4.s4.sin_family = AF_INET;
        memcpy(&addr4.s4.sin_addr, addr->s6.sin6_addr.s6_addr + 12, 4);
        addr = &addr4;
      }
    }
    if (addr_any(&(range->min)) || addr_less_eq(&(range->min), addr)) {
      if (addr_any(&(range->max))) {
        return 1;

Source: GitHub Commit Update

Detection Methods for CVE-2026-27624

Indicators of Compromise

• TURN/STUN requests containing IPv4-mapped IPv6 addresses in XOR-PEER-ADDRESS attributes (e.g., ::ffff:127.0.0.1, ::ffff:10.x.x.x, ::ffff:192.168.x.x)
• Successful CreatePermission or ChannelBind responses for addresses that should be blocked by denied-peer-ip configuration
• Unexpected traffic relayed through the TURN server to internal network ranges or loopback interfaces

Detection Strategies

• Monitor TURN server logs for successful permission grants or channel bindings to IPv4-mapped IPv6 addresses
• Implement network-level monitoring for traffic patterns indicating SSRF attempts through the TURN server
• Deploy intrusion detection rules that flag TURN protocol messages containing ::ffff: prefixed addresses targeting internal ranges

Monitoring Recommendations

• Enable verbose logging on Coturn servers to capture all CreatePermission and ChannelBind requests with their associated peer addresses
• Configure alerts for successful relay attempts to RFC 1918 private address ranges or loopback addresses
• Review TURN server access patterns regularly to identify potential exploitation attempts

How to Mitigate CVE-2026-27624

Immediate Actions Required

• Upgrade Coturn to version 4.9.0 or later immediately
• Review TURN server logs for evidence of exploitation attempts using IPv4-mapped IPv6 addresses
• Audit current denied-peer-ip configurations and verify they are being enforced correctly
• Consider implementing additional network-level filtering to block IPv4-mapped IPv6 addresses at the firewall level

Patch Information

The vulnerability has been addressed in Coturn version 4.9.0. The fix ensures that IPv4-mapped IPv6 addresses are properly recognized and the embedded IPv4 address is extracted before performing range comparisons against denied-peer-ip configurations. The patch is available in commit b80eb898ba26552600770162c26a8ae7f3661b0b.

For detailed security information, refer to the GitHub Security Advisory GHSA-6g6j-r9rf-cm7p and the related advisory GHSA-j8mm-mpf8-gvjg for the original CVE-2020-26262.

Workarounds

• Implement network-level firewall rules that explicitly block IPv4-mapped IPv6 address ranges targeting internal networks
• Consider running Coturn in an isolated network segment with strict egress filtering
• Deploy a reverse proxy or application-layer firewall that normalizes IPv6 addresses before they reach the TURN server
• Temporarily disable IPv6 on the TURN server if IPv6 support is not required for your deployment

# Configuration example - Add explicit IPv4-mapped IPv6 blocks to turnserver.conf
# Note: These may not be effective on vulnerable versions; upgrade is recommended
denied-peer-ip=::ffff:127.0.0.0-::ffff:127.255.255.255
denied-peer-ip=::ffff:10.0.0.0-::ffff:10.255.255.255
denied-peer-ip=::ffff:172.16.0.0-::ffff:172.31.255.255
denied-peer-ip=::ffff:192.168.0.0-::ffff:192.168.255.255