https://vulnerability.circl.lu Contains only the most 10 recent entries. http://www.rssboard.org/rss-specification python-feedgen en Fri, 02 Oct 2026 00:25:32 +0000 https://vulnerability.circl.lu/vuln/cve-2026-27624 <p><strong>Affected:</strong> coturn</p> <p>Coturn is a free open source implementation of TURN and STUN Server. Coturn is commonly configured to block loopback and internal ranges using &#34;denied-peer-ip&#34; and/or default loopback restrictions. CVE-2020-26262 addressed bypasses involving &#34;0.0.0.0&#34;, &#34;[::1]&#34; and &#34;[::]&#34;, but IPv4-mapped IPv6 is not covered. When sending a &#34;CreatePermission&#34; or &#34;ChannelBind&#34; request with the &#34;XOR-PEER-ADDRESS&#34; value of &#34;::ffff:127.0.0.1&#34;, a successful response is received, even though &#34;127.0.0.0/8&#34; is blocked via &#34;denied-peer-ip&#34;. The root cause is that, prior to the updated fix implemented in version 4.9.0, three functions in &#34;src/client/ns_turn_ioaddr.c&#34; do not check &#34;IN6_IS_ADDR_V4MAPPED&#34;. &#34;ioa_addr_is_loopback()&#34; checks &#34;127.x.x.x&#34; (AF_INET) and &#34;::1&#34; (AF_INET6), but not &#34;::ffff:127.0.0.1.&#34; &#34;ioa_addr_is_zero()&#34; checks &#34;0.0.0.0&#34; and &#34;::&#34;, but not &#34;::ffff:0.0.0.0.&#34; &#34;addr_less_eq()&#34; used by &#34;ioa_addr_in_range()&#34; for &#34;denied-peer-ip&#34; matching: when the range is AF_INET and the peer is AF_INET6, the comparison returns 0 without extracting the embedded IPv4. Version 4.9.0 contains an updated fix to address the bypass of the fix for CVE-2020-26262.</p> <p><strong>Affected:</strong> coturn</p> <p>Coturn is a free open source implementation of TURN and STUN Server. Coturn is commonly configured to block loopback and internal ranges using &#34;denied-peer-ip&#34; and/or default loopback restrictions. CVE-2020-26262 addressed bypasses involving &#34;0.0.0.0&#34;, &#34;[::1]&#34; and &#34;[::]&#34;, but IPv4-mapped IPv6 is not covered. When sending a &#34;CreatePermission&#34; or &#34;ChannelBind&#34; request with the &#34;XOR-PEER-ADDRESS&#34; value of &#34;::ffff:127.0.0.1&#34;, a successful response is received, even though &#34;127.0.0.0/8&#34; is blocked via &#34;denied-peer-ip&#34;. The root cause is that, prior to the updated fix implemented in version 4.9.0, three functions in &#34;src/client/ns_turn_ioaddr.c&#34; do not check &#34;IN6_IS_ADDR_V4MAPPED&#34;. &#34;ioa_addr_is_loopback()&#34; checks &#34;127.x.x.x&#34; (AF_INET) and &#34;::1&#34; (AF_INET6), but not &#34;::ffff:127.0.0.1.&#34; &#34;ioa_addr_is_zero()&#34; checks &#34;0.0.0.0&#34; and &#34;::&#34;, but not &#34;::ffff:0.0.0.0.&#34; &#34;addr_less_eq()&#34; used by &#34;ioa_addr_in_range()&#34; for &#34;denied-peer-ip&#34; matching: when the range is AF_INET and the peer is AF_INET6, the comparison returns 0 without extracting the embedded IPv4. Version 4.9.0 contains an updated fix to address the bypass of the fix for CVE-2020-26262.</p> https://vulnerability.circl.lu/vuln/cve-2026-27624