CVE-2026-27624
Coturn Project Coturn ≤ 4.9.0
Raw vector
CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:C/C:L/I:L/A:NSummary
CVE-2026-27624 is a high-severity Improper Access Control (CWE-284) vulnerability in Coturn Project Coturn. Its CVSS base score is 7.2 (High).
Operationally, exploitation aligns with the MITRE ATT&CK technique Exploit Public-Facing Application (T1190); ranked at the 17th percentile by exploit likelihood (below the median); it is not currently listed in the CISA KEV catalog; a public proof-of-concept is referenced.
The strongest mitigations our analysis identified map to AC-16 (Security and Privacy Attributes) and AC-3 (Access Enforcement) — see the control section below for these in your framework.
Deeper analysis AI-assisted summary
Synthesised by an AI model from the NVD description and linked references — a reading aid, not an authoritative source.
CVE-2026-27624 is a vulnerability in Coturn, a free open source implementation of TURN and STUN servers, affecting versions prior to 4.9.0. It enables a bypass of loopback and internal IP range restrictions configured via "denied-peer-ip" or default settings. Specifically, an attacker can send a CreatePermission or ChannelBind request with the XOR-PEER-ADDRESS set to the IPv4-mapped IPv6 address "::ffff:127.0.0.1", receiving a successful response despite blocks on 127.0.0.0/8. This stems from three functions in src/client/ns_turn_ioaddr.c—ioa_addr_is_loopback(), ioa_addr_is_zero(), and addr_less_eq()—failing to check for IN6_IS_ADDR_V4MAPPED addresses, allowing evasion of checks for 127.x.x.x, ::1, 0.0.0.0, and :: as previously addressed in CVE-2020-26262. The issue is rated CVSS 7.2 (AV:N/AC:L/PR:N/UI:N/S:C/C:L/I:L/A:N) and maps to CWE-284 and CWE-441.
The vulnerability can be exploited by any unauthenticated network attacker (PR:N) with access to the Coturn server. By crafting requests with IPv4-mapped IPv6 peer addresses, they bypass denied-peer-ip restrictions and loopback checks, potentially permitting unauthorized permission creation or channel binding to internal or loopback addresses. This leads to low-level confidentiality and integrity impacts (C:L/I:L) with changed scope (S:C), such as limited data exposure or modification in TURN/STUN relay contexts.
Mitigation requires updating to Coturn version 4.9.0, which includes an updated fix in src/client/ns_turn_ioaddr.c to properly handle IN6_IS_ADDR_V4MAPPED checks and address the bypass of CVE-2020-26262. Relevant advisories and the fixing commit are detailed in GitHub security advisories GHSA-6g6j-r9rf-cm7p and GHSA-j8mm-mpf8-gvjg, along with commit b80eb898ba26552600770162c26a8ae7f3661b0b.
OWASP Top 10 for Web (2025)
EU & UK References
- 🇪🇺 ENISA EUVD: EUVD-2026-8620
Vulnerability Data
Coturn is a free open source implementation of TURN and STUN Server. Coturn is commonly configured to block loopback and internal ranges using "denied-peer-ip" and/or default loopback restrictions. CVE-2020-26262 addressed bypasses involving "0.0.0.0", "[::1]" and "[::]", but IPv4-mapped IPv6 is…
more
not covered. When sending a "CreatePermission" or "ChannelBind" request with the "XOR-PEER-ADDRESS" value of "::ffff:127.0.0.1", a successful response is received, even though "127.0.0.0/8" is blocked via "denied-peer-ip". The root cause is that, prior to the updated fix implemented in version 4.9.0, three functions in "src/client/ns_turn_ioaddr.c" do not check "IN6_IS_ADDR_V4MAPPED". "ioa_addr_is_loopback()" checks "127.x.x.x" (AF_INET) and "::1" (AF_INET6), but not "::ffff:127.0.0.1." "ioa_addr_is_zero()" checks "0.0.0.0" and "::", but not "::ffff:0.0.0.0." "addr_less_eq()" used by "ioa_addr_in_range()" for "denied-peer-ip" 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.
- CWE(s)
Related Threats
MITRE ATT&CK Enterprise Techniques
CVEs Like This One
Affected Assets
Mitigating Controls
Control response
—
—
- 8 hardening rules · 4 OS baselines
V10.3.5V3.2.1V3.5.1V3.5.3
Mitigating Controls (NIST 800-53 r5) AI
Directly enforces approved authorizations for logical access, stopping unauthorized actors from reaching resources.
Associating and preserving security attributes such as original source identity prevents the loss of provenance that creates the confused deputy.
Enforces flow-control policies that restrict information movement between subjects and objects.
Documents duties and assigns access so that no single account can bypass intended restrictions.
Limits each account to the minimum privileges needed, reducing the chance of unauthorized access.
Defines account types, assigns/removes access, and reviews accounts to ensure only authorized actors can reach resources.
Mitigating Controls (NIST CSF 2.0) AI
Derived directly from the weakness types (CWEs) cited in the NVD entry via our AI-authored CWE→CSF cross-walk (authority under review) — links open the control.
Proper conveyance and verification of original identity assertions directly prevents loss of request source when forwarding.
PR.AA-05 directly enforces policy-based access management and least privilege, eliminating most improper-access-control defects, yet CWE-284 also covers implementation flaws and design gaps outside a single management control.
Hardened baselines and deviation monitoring directly eliminate most configuration-induced access-control defects, yet CWE-284 also encompasses code-level and design flaws outside the scope of configuration management alone.
Secure SDLC practices catch most access-control defects during design/coding/testing (mostly), yet leave residual risk from runtime configuration, architecture, and operational controls (partial).
PR.AA-01 supplies managed identities/credentials that support but do not implement access-control decisions, so it only partially prevents CWE-284 in either direction.
Authentication directly blocks unauthenticated actors (partial prevention of CWE-284) but leaves authorization logic, policy enforcement, and role checks untouched, so the control neither eliminates nor fully mitigates the broader weakness.
Mitigating Controls (ISO/IEC 27001:2022 Annex A) AI
Derived directly from the weakness types (CWEs) cited in the NVD entry via our AI-authored CWE→ISO cross-walk (authority under review) — links open the control.
Defining and enforcing explicit access rights and restrictions for each entity directly stops the assignment of permissions that exceed what is required, eliminating the root condition that allows improper access control.
Formal authorization, role-based provisioning, and timely revocation of access rights directly stop the creation of accounts or permissions that exceed what the business actually needs.
By enforcing explicit rules on which identities or groups may perform read, write, delete or execute operations and by denying anonymous access to sensitive data, the control directly stops the creation of overly permissive or missing access-control checks.
Requiring one-to-one mapping of identities to entities and timely removal of unused identities directly stops attackers from leveraging stale or shared accounts to bypass access restrictions.
By explicitly transferring security roles and responsibilities when personnel change jobs or leave, the control reduces the chance that former employees retain access rights they no longer need, thereby limiting improper access control.
Physical entry controls enforce explicit authorization and authentication at every access point, directly stopping unauthorized actors from reaching information-processing assets.
Hardening callouts derived
Configuration rules from DISA STIG baselines that bear on weaknesses of the type cited by this CVE. Each rule is shown with the relationship its mapping actually records, against the CWE it was authored against. Derived via CVE→CWE over `controls_xwalks` (authoritative rows only; rows rated `none` are excluded).
Oracle Linux 8 (2 rules)
- V-248597 There must be no "shosts.equiv" files on the OL 8 operating system. prevents CWE-284
- V-248598 There must be no ".shosts" files on the OL 8 operating system. prevents CWE-284
Oracle Linux 9 (2 rules)
- V-271758 OL 9 file systems must not contain .shosts files. prevents CWE-284
- V-271757 OL 9 file systems must not contain shosts.equiv files. prevents CWE-284
RHEL 7 (2 rules)
- V-204606 The Red Hat Enterprise Linux operating system must not contain .shosts files. prevents CWE-284
- V-204607 The Red Hat Enterprise Linux operating system must not contain shosts.equiv files. prevents CWE-284
RHEL 8 (2 rules)
- V-230283 There must be no shosts.equiv files on the RHEL 8 operating system. prevents CWE-284
- V-230284 There must be no .shosts files on the RHEL 8 operating system. prevents CWE-284