CVE-2026-73212

If you administer a Coturn TURN server and have configured denied-peer-ip rules with IPv4 CIDR ranges, be aware that those restrictions can be bypassed. The security check in ioa_addr_in_range() compares peer addresses against your deny rules without canonicalizing them first. This means a client presenting the same IPv4 endpoint as an IPv6 address—for instance, ::ffff:192.168.1.1, a 6to4 address in the 2002::/16 range, or a NAT64 address under 64:ff9b::/96—will pass the check even though the IPv4 form would be denied. The practical consequence: administrators who believe 'deny 192.168.0.0/16' blocks all access to RFC 1918 space are protected only against naive IPv4 clients. Any client in a NAT64 environment, or using an IPv4-mapped address, bypasses that control entirely. This isn't a logic bug in the traditional sense—it's a gap between what the deny rule semantically promises and what the implementation actually enforces. Two questions should drive your response. First, confirm you're on Coturn 4.13.1 or later—the patch canonicalizes addresses before the range check. Second, audit what your denied-peer-ip ranges are actually protecting. If they're meant to isolate internal infrastructure from relaying clients, understand that the isolation is incomplete unless clients are provably not using transitional IPv6 forms. The CVSS 5.8 rating doesn't capture the false assurance problem: your security control looks functional but provides coverage only for a subset of the address space you think you're blocking. Treat this as a detection-gap vulnerability: the bypass works silently, leaving no log evidence that access was granted to an address that should have been denied.

Reviewed through automated stages and approved by a human before publication.