CVE-2026-27624
IPv6-Mapped Address Bypass in Coturn TURN Server Access Control
Publication date: 2026-02-25
Last updated on: 2026-02-27
Assigner: GitHub, Inc.
Description
Description
CVSS Scores
EPSS Scores
| Probability: | |
| Percentile: |
Meta Information
Affected Vendors & Products
| Vendor | Product | Version / Range |
|---|---|---|
| coturn_project | coturn | to 4.9.0 (exc) |
Helpful Resources
Exploitability
| CWE ID | Description |
|---|---|
| CWE-284 | The product does not restrict or incorrectly restricts access to a resource from an unauthorized actor. |
| CWE-441 | The product receives a request, message, or directive from an upstream component, but the product does not sufficiently preserve the original source of the request before forwarding the request to an external actor that is outside of the product's control sphere. This causes the product to appear to be the source of the request, leading it to act as a proxy or other intermediary between the upstream component and the external actor. |
Attack-Flow Graph
AI Powered Q&A
Can you explain this vulnerability to me?
[{'type': 'paragraph', 'content': 'CVE-2026-27624 is a high-severity vulnerability in Coturn version 4.8.0 related to improper access control due to inadequate handling of IPv4-mapped IPv6 addresses (::ffff:0.0.0.0/96) in the "denied-peer-ip" access control list (ACL) feature.'}, {'type': 'paragraph', 'content': 'Coturn is a TURN and STUN server that commonly blocks loopback and internal IP ranges using "denied-peer-ip" and default loopback restrictions. While a previous vulnerability (CVE-2020-26262) addressed bypasses involving addresses like "0.0.0.0", "[::1]", and "[::]", it did not cover IPv4-mapped IPv6 addresses.'}, {'type': 'paragraph', 'content': 'The root cause is that three key functions in Coturn\'s source code fail to detect IPv4-mapped IPv6 addresses properly: they do not use the "IN6_IS_ADDR_V4MAPPED" macro to identify these addresses. As a result, when a client sends requests with the "XOR-PEER-ADDRESS" set to an IPv4-mapped IPv6 address (e.g., "::ffff:127.0.0.1"), Coturn incorrectly allows the request even though the corresponding IPv4 range (e.g., 127.0.0.0/8) is blocked.'}, {'type': 'paragraph', 'content': 'This vulnerability allows malicious users to bypass ACL restrictions for any IPv4 range, including loopback, link-local, and private IP ranges, by using IPv4-mapped IPv6 addresses.'}] [1]
How can this vulnerability impact me? :
[{'type': 'paragraph', 'content': "This vulnerability can impact you by allowing unauthorized access through Coturn's access control mechanisms. Specifically, attackers can bypass IP address restrictions intended to block loopback, link-local, and private IPv4 ranges by using IPv4-mapped IPv6 addresses."}, {'type': 'paragraph', 'content': 'As a result, malicious users may relay packets or establish connections that should have been blocked, potentially leading to unauthorized network access or data exposure within internal or restricted IP ranges.'}, {'type': 'paragraph', 'content': "Although on some systems like Linux, data relay to IPv4-mapped destinations may fail due to kernel routing limitations, the ACL bypass itself constitutes a policy violation and undermines trust in Coturn's enforcement of IP restrictions when IPv6 is enabled."}] [1]
How does this vulnerability affect compliance with common standards and regulations (like GDPR, HIPAA)?:
I don't know
How can this vulnerability be detected on my network or system? Can you suggest some commands?
[{'type': 'paragraph', 'content': 'This vulnerability can be detected by monitoring Coturn server logs for successful "CREATE_PERMISSION" and "CHANNEL_BIND" requests that use IPv4-mapped IPv6 addresses (e.g., ::ffff:127.0.0.1) within IP ranges that are supposed to be blocked by the "denied-peer-ip" ACL feature.'}, {'type': 'paragraph', 'content': 'A proof-of-concept script can be used to test if native IPv4 peers are blocked while IPv4-mapped IPv6 peers are accepted, indicating the ACL bypass.'}, {'type': 'paragraph', 'content': 'As for commands, you can use network monitoring or packet capture tools (e.g., tcpdump or Wireshark) to filter and inspect TURN protocol traffic for XOR-PEER-ADDRESS attributes containing IPv4-mapped IPv6 addresses.'}, {'type': 'list_item', 'content': 'Use tcpdump to capture TURN traffic and filter for IPv4-mapped IPv6 addresses: tcpdump -i <interface> -nn -s0 -v udp port <coturn_port> and look for XOR-PEER-ADDRESS values starting with ::ffff:'}, {'type': 'list_item', 'content': 'Check Coturn server logs for entries showing successful permission or channel bind requests from IPv4-mapped IPv6 addresses within blocked ranges.'}, {'type': 'list_item', 'content': 'Run a test client or script that sends CreatePermission or ChannelBind requests with XOR-PEER-ADDRESS set to IPv4-mapped IPv6 addresses (e.g., ::ffff:127.0.0.1) and observe if the server incorrectly allows them.'}] [1]
What immediate steps should I take to mitigate this vulnerability?
[{'type': 'paragraph', 'content': 'Immediate mitigation steps include explicitly denying the entire IPv4-mapped IPv6 address range in the Coturn configuration by adding a "denied-peer-ip" rule for ::ffff:0.0.0.0-::ffff:255.255.255.255.'}, {'type': 'paragraph', 'content': 'This workaround prevents IPv4-mapped IPv6 addresses from bypassing the ACL restrictions on IPv4 ranges such as loopback, link-local, and private RFC1918 addresses.'}, {'type': 'paragraph', 'content': 'Additionally, consider rejecting IPv4-mapped IPv6 peer addresses outright if they are not needed in your TURN server deployment.'}, {'type': 'paragraph', 'content': 'Monitor for updates or patches from Coturn, as no patched versions were available as of the advisory date.'}] [1]