Sandro Gauci , Enable Security TURN Security Threats: A Hacker’s View Published on Feb 12, 2026 in TURN security , webrtc security , server hardening Executive Summary (TL;DR) TURN servers are meant to relay media traffic for WebRTC, but they’re also powerful proxies that hackers have been abusing since at least 2017. Based on years of research and real-world penetration testing, the abuse falls into three categories: relay abuse (think SSRF on steroids), Denial of Service (your server becomes a weapon), and plain old software vulnerabilities. The fix? Isolate your TURN servers, Restrict their capabilities, and Update them without fail. Heads up This article is based on a presentation given at RTCon 2025. Prefer to watch instead? Check out the recording on YouTube . We’ll also be publishing detailed TURN server security configuration guides soon, covering implementation-agnostic best practices and coturn-specific hardening templates. A trip down memory lane Remember those proxy lists from the 90s? Back when script kiddies kept spreadsheets of misconfigured SOCKS and HTTP proxies, using them to relay traffic and anonymize attacks. We’d find an open proxy, configure our tools to route through it, and suddenly we were bouncing attacks through servers halfway around the world. So when I was reviewing RFC 5766 years later, it was easy to make the connection: TURN is described as a “communication relay” that lets hosts “control the operation” of the relay and “exchange packets with its peers”. That’s basically hacker speak for “this is going to be abused”. The proxy abuse problem never went away, it just evolved. TURN servers are the modern equivalent of those misconfigured open proxies. What is TURN and why does it matter? The Wikipedia page for this protocol actually does a decent job of explaining that TURN (Traversal Using Relays around NAT) is a protocol that assists in traversal of network address translators (NAT) or firewalls for multimedia applications. In the WebRTC world, TURN is the fallback mechanism when direct peer-to-peer connections fail due to restrictive NAT or firewalls. With WebRTC, one of the more painful complications has been getting the media stream (i.e., RTP packets carrying audio and video) of two or more parties to reach each other. This tends to be a problem because of NAT. In many cases, this has been solved with STUN, and when that fails, the TURN extension tends to be the last resort before failing to get the media stream working. The ICE protocol (Interactive Connectivity Establishment) is what ties in STUN and TURN. Threat modeling: what can go wrong? So what security does TURN actually provide? The RFC is clear: Authentication is required - credentials never in plain text NOT responsible for : encryption/integrity (handled by WebRTC media itself) Availability matters : TURN’s one job is to relay media. If it goes down, calls break for everyone relying on it. From a security perspective, TURN servers should not be trusted with confidentiality or integrity, only as a transport mechanism, just like UDP and TCP. But since its whole purpose is delivering media, availability is very much a concern. Warning TURN requires authentication, but many WebRTC platforms are open to the public. When anyone can register or join anonymous meetings, TURN credentials are dispensed freely - making authentication ineffective as a security control. According to the Threat Modeling Manifesto , we should answer the question: what can go wrong? For TURN servers, we’ve identified three critical threat categories: TURN relay abuse - Like SSRF, but more powerful Denial of Service - Direct attacks + amplification/reflection Software vulnerabilities - CVEs, memory safety, access control bugs Let’s think like an attacker and explore each of these. Threat #1: TURN relay abuse What is TURN relay abuse? In a WebRTC environment, TURN servers are meant to relay legitimate media traffic. By abuse, we mean that this same feature is used to relay more than just legitimate media traffic. This can be used to bypass firewalls, anonymize traffic, or access internal network resources - activities for which the server was not designed. For the webapp-sort of penetration testers out there, this sounds familiar because that is how SSRF (server-side request forgery) vulnerabilities are usually abused. However, there is an important difference: abuse of this vulnerability is not limited to just HTTP-based protocols. Instead, we see it as closer to abusing an open proxy (e.g., a SOCKS proxy or a web proxy with the CONNECT method). Technical details: TURN relay mechanisms TURN provides multiple mechanisms to relay traffic, all allowing relay to arbitrary destinations: UDP Send Indication method ( 0x0006 ) : Allocate Request ( 0x0003 ) CreatePermission ( 0x0008 ) - authorizes peer IP Send Indication ( 0x0006 ) with XOR-PEER-ADDRESS + DATA UDP ChannelData method : AllocateRequest ( 0x0003 ) CreatePermission ( 0x0008 ) - authorizes...