TURN Security Threats: A Hacker’s View

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.

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.

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:

1. TURN relay abuse - Like SSRF, but more powerful
2. Denial of Service - Direct attacks + amplification/reflection
3. 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):

1. Allocate Request (0x0003)
2. CreatePermission (0x0008) - authorizes peer IP
3. Send Indication (0x0006) with XOR-PEER-ADDRESS + DATA

UDP ChannelData method:

1. AllocateRequest (0x0003)
2. CreatePermission (0x0008) - authorizes peer IP
3. ChannelBind Request (0x0009) with channel number + peer
4. ChannelData frames with data

TCP Connect method (RFC 6062, 0x000A):

1. AllocateRequest (0x0003) with REQUESTED-TRANSPORT=TCP
2. ConnectRequest (0x000A) with XOR-PEER-ADDRESS
3. ConnectionBind Request (0x000B) with CONNECTION-ID
4. Native TCP data flow

The point is that TURN can relay both UDP and TCP traffic to arbitrary destinations. That’s a powerful capability in the wrong hands.

The problem: peer addresses can be anything

The peer address could be anything, including:

• Internal addresses (RFC1918 ranges like 10.0.0.0/8, 192.168.0.0/16)
• Local addresses (127.0.0.1, ::1)
• Link-local addresses (169.254.0.0/16 - hello AWS metadata service!)
• Any third-party external address

The natural solution is to restrict which peer addresses are allowed. The TURN spec explicitly permits servers to reject disallowed peers with a 403 Forbidden, and TURN server implementations expose this via configuration (e.g. allowed/denied peer IP lists). But here’s where it gets interesting.

Real attack #1: hacking Slack’s TURN servers

We got bored of finding TURN relay abuse only in private client engagements, so we turned to bug bounties. Slack was the most interesting one and the one we could actually publish. And we were awarded $3,500 for our bug-bounty report on HackerOne.

Our methodology:

1. Get TURN credentials as a legitimate user (simulate making a call in Slack)
2. Use our internal tool to abuse the relay functionality
3. Connect to any IP and port reachable through Slack’s TURN servers

What could we do by abusing Slack’s TURN servers?

• Connect to the AWS meta-data services at http://169.254.169.254 and obtain IAM temporary credentials
• Connect to open ports on localhost that are usually not exposed to the Internet (e.g., node exporter): 22, 25, 53, 443, 515, 5666, 8500, 8888, 9090 and 9100
• Port-scan the Slack AWS infrastructure on 10.41.0.0/16 and find server management applications

And the rest, as they say, is a historic video:

The video shows:

1. How to obtain the TURN credentials
2. Testing relaying to the Internet through the TURN server by checking our IP address
3. Connecting to internal network and meta-data services on Slack’s AWS infrastructure

For more details, check out our full blog post about the Slack TURN compromise.

Real attack #2: running C2 operations over TURN servers

At Black Hat/DEF CON 2025, Adam Crosser presented research on abusing TURN servers from trusted services such as Zoom and MS Teams to pass C2 (Command and Control) traffic without triggering any security alarms. The idea is brilliant: your security monitoring sees legitimate Zoom or Teams traffic, not malicious command and control.

Zoom’s solution: They prevented peer-to-peer connections and configured their TURN servers to only relay to/from their own media servers. This is one of the most effective mitigations against TURN relay abuse, and we’ll discuss it more in the best practices section.

Real attack #3: PBX/SIP trunk abuse

Sometimes TURN servers fall under IP ranges that are trusted by other systems. For example, a PBX system might authenticate a SIP trunk by IP (i.e., no actual authentication). If that IP has a TURN server behind it, this could mean attackers calling your PBX. Sometimes this leads to toll fraud, making calls off the PBX system or SIP trunk at your expense.

The attack scenario:

1. PBX uses IP-based authentication for SIP trunk
2. TURN server is in the trusted IP range
3. Attacker uses TURN relay to connect to PBX from “trusted” IP
4. Result: Toll fraud, unauthorized calls, SIP trunk abuse

We’ve demonstrated this in lab environments and found it during penetration testing engagements.

Threat #2: Denial of Service

So how bad does DoS actually get for TURN? First, it helps to understand how much media traffic actually passes through TURN servers. Data shows that TURN usage varies quite a bit:

• US: ~10% of WebRTC traffic
• Global: ~20% of WebRTC traffic
• Range: 5-30% depending on network infrastructure and NAT types

If your exposure is as low as these numbers suggest, you’re probably better off protecting your SFU and media servers first, since those often handle 100% of media traffic. That said, 5-30% of your users relying on TURN is not nothing, and that’s still the TURN server’s direct DoS attack surface. But as we’ll see, the indirect attack surface is what really keeps us up at night.

Like any public service, TURN servers face typical DoS risks. But the real kicker is when your TURN server becomes an unwilling participant in attacks against others.

Direct DoS attacks

These are the standard resource exhaustion attacks:

• Connection flooding (exhaust server memory)
• Allocation flooding (create thousands of allocations)
• Log flooding (trigger excessive logging)
• Bandwidth exhaustion (consume all available bandwidth)

These can be surprisingly effective against TURN servers that lack rate limiting or allocation quotas, and we’ve seen them take down production TURN infrastructure during our DDoS testing engagements. But the direct attacks are only half the story.

TURN reflection/amplification attacks

This is the indirect attack surface we mentioned. Attackers abuse TURN servers for DDoS attacks against others by exploiting reflection and amplification properties:

How it works:

1. Attacker sends requests with spoofed source IP (the victim’s IP)
2. TURN server sends larger responses to the victim
3. Victim receives amplified traffic from many TURN servers

Amplification factors comparison:

• DNS: 28-54x amplification
• NTP: 200-500x+ amplification
• TURN: only ~4x amplification

Despite the low amplification factor, attackers still abuse TURN servers for DDoS because they’re widely deployed, publicly accessible, and many are misconfigured without rate limiting. Go figure.

What messages are abused?

Unauthenticated Allocate Requests: the server responds with error messages that are larger than the request. STUN Binding Requests also don’t require authentication in many implementations and can be used for reflection.

Threat #3: TURN software vulnerabilities

Beyond relay abuse and DoS, TURN servers have their own share of software vulnerabilities. Like any network-facing service, they need to be patched regularly.

We’ll focus on coturn here since it’s the most widely deployed TURN server, but do keep in mind that other implementations are not immune to similar issues.

Vulnerability history: coturn

Critical vulnerability categories found in coturn over the years:

Memory Safety - Buffer overflows, use-after-free (30+ fixes)

• Multiple heap/stack buffer overflows
• Use-after-free vulnerabilities
• Memory corruption issues

SQL Injection - CVE-2018-4056 (Critical 9.8 CVSS)

• Allowed attackers to execute arbitrary SQL queries
• Could lead to complete database compromise

Protocol Attacks - STUN/TURN amplification mitigations

• Various protocol-level vulnerabilities
• Amplification abuse vectors

Information Disclosure - CVE-2020-4067, buffer exposure

• Memory disclosure vulnerabilities
• Credential leakage risks

Access Control - CVE-2020-26262, IPv6 loopback bypass

• This one is ours - more on this below

DoS & TLS Issues - Infinite loops, log flooding, certificate handling

• Various Denial of Service vectors
• TLS/DTLS implementation issues

Dependencies - 15+ OpenSSL and library vulnerabilities

• Vulnerable to underlying library bugs
• OpenSSL CVEs affecting coturn

CVE-2020-26262: our discovery

During testing of our internal STUN and TURN security testing tool, we noticed that the default protection mechanism to protect against connections to 127.0.0.1 worked fine, but the same effect could be achieved by specifying 0.0.0.0 as IP instead of 127.0.0.1. On Linux systems (and possibly other operating systems), socket connections to 0.0.0.0 get connected to the local machine, which, for our purposes, has exactly the same effect as connecting to 127.0.0.1. Therefore, we had found a way to bypass the default block on IPv4.

We then implemented IPv6 support for TURN in our tool and noticed that even if coturn is supposed to also block loopback IPv6 addresses, it did not actually work. In fact, although coturn contained code that appeared to block IPv6 loopback addresses, strangely we could still specify [::1] as peer address and get connected to local services. On top of that, there was no code to protect against [::], which is the IPv6 equivalent of 0.0.0.0.

The fixes (in coturn 4.5.2):

• Block 0.0.0.0/8 by default
• Block [::] by default
• Correctly parse IPv6 loopback address [::1]

For complete details, check out our full blog post about CVE-2020-26262.

Security best practices: Isolate, Restrict, Update

We’ve seen how TURN servers can be abused for relay attacks, used in DoS amplification, and are themselves vulnerable software. So, this begs the question: how do we defend against all of this?

Three words: Isolate, Restrict, Update.

Isolate your TURN servers on dedicated networks with no special access to internal systems. If the TURN server is compromised or access controls are bypassed, isolation means there’s nothing else for the attacker to reach.

Restrict the TURN server’s capabilities at every layer:

1. Isolate TURN server on dedicated network/security group - deploy in a DMZ or dedicated security group with no access to internal services
2. Block internal/local IP ranges - deny all RFC1918, loopback, link-local, and other special-purpose address ranges as peer addresses
3. Restrict relay destinations to known media servers - if peer-to-peer isn’t needed, allow-list only your media server IPs (this is what Zoom did)
4. Disable unnecessary protocol features - turn off RFC5780 NAT discovery, RFC3489 legacy STUN, and DTLS if not needed
5. Disable UDP listening - if you have a TCP-only architecture (rare but effective against amplification)
6. Disable TCP relay - if you only need UDP media relay (typical for WebRTC)
7. Implement rate limiting - at both network level (iptables/nftables) and application level (allocation quotas, bandwidth caps)
8. Protect TURN credential APIs - authenticate and authorize the endpoints that dispense TURN credentials
9. Keep servers updated - as we saw with coturn, TURN servers can have serious vulnerabilities that need patching
10. Monitor traffic patterns and security events - watch for unusual allocation rates, access control violations, and bandwidth spikes

Updating and configuring your TURN server is an important step, but how do you know it all actually works? At Enable Security, we test TURN servers for relay abuse, access control bypasses, protocol vulnerabilities, and DoS resistance during our WebRTC penetration tests. If you’re running TURN in production, get in touch.

Conclusion

If there’s one thing to take away from this article, it’s this: stop thinking of TURN as “just a media relay”. It’s a proxy. And proxies get abused.

If you’ve made it this far and haven’t checked your TURN server configuration yet, perhaps now is a good time.

Key takeaways

1. A TURN server is a media relay, but to an attacker it’s a proxy. That’s the root of relay abuse threats.
2. Authentication alone won’t save you. TURN credentials are often handed out to browsers freely, so treat every authenticated user as a potential attacker.
3. Isolate, Restrict, Update. No single control is enough. You need all three working together.

Stay informed

TURN security is evolving. We cover the latest vulnerabilities, attack techniques, and defenses in our monthly RTCSec newsletter. Subscribe to stay ahead of the threats.