Securing coturn: Configuration Guide

TL;DR

coturn is the most widely deployed TURN server, and also the one we’ve found the most vulnerabilities in. This guide gives you copy-paste configuration blocks to lock it down: access control rules, protocol hardening, rate limiting, authentication, and three complete templates from minimal to high-security. All examples target coturn 4.6.x and later, with version-specific notes where the configuration changed (particularly 4.7.0 which flipped TLS defaults).

About this guide

This is the coturn-specific companion to our TURN Server Security Best Practices. That guide covers the why behind each security control. This guide covers the how for coturn specifically: copy-paste configuration blocks, complete templates, and version-specific notes.

If you’re running a version older than 4.6.x, some parameters may differ or not be available.

Quick start: a minimal secure config

All configuration templates in this guide are available in our coturn-secure-config repository, which includes a Docker environment for testing them against a live coturn instance.

If you just want a working secure config to get started, save the following as /etc/turnserver.conf:

# Minimal Secure coturn Configuration (4.6.0+)
# Save as: /etc/turnserver.conf

# Listening configuration
listening-port=3478
tls-listening-port=5349

# Authentication
lt-cred-mech
use-auth-secret
static-auth-secret=CHANGE_THIS_SECRET
realm=turn.example.com

# Access control - block internal ranges
no-multicast-peers
denied-peer-ip=0.0.0.0-0.255.255.255
denied-peer-ip=10.0.0.0-10.255.255.255
denied-peer-ip=127.0.0.0-127.255.255.255
denied-peer-ip=169.254.0.0-169.254.255.255
denied-peer-ip=172.16.0.0-172.31.255.255
denied-peer-ip=192.168.0.0-192.168.255.255
denied-peer-ip=::1
denied-peer-ip=::ffff:0.0.0.0-::ffff:255.255.255.255
denied-peer-ip=fc00::-fdff:ffff:ffff:ffff:ffff:ffff:ffff:ffff
denied-peer-ip=fe80::-febf:ffff:ffff:ffff:ffff:ffff:ffff:ffff

# Rate limiting - tune these to your expected usage
user-quota=100
total-quota=10000
max-allocate-lifetime=3600

# Logging
log-file=/var/log/coturn/turnserver.log
syslog

For production, set external-ip to your server’s public IP (required for NAT traversal) and listening-ip/relay-ip to bind to a specific interface.

This covers the basics. Read on for the complete access control configuration, protocol hardening, and high-security templates.

Access control: blocking internal IP ranges

Relay abuse is the #1 threat to TURN servers. Without access controls, an attacker with valid credentials can use your TURN server to reach internal networks, localhost services, and cloud metadata endpoints. For the full rationale, see the access control section of our best practices guide.

Deny-listing non-public peer addresses

# Block multicast addresses
no-multicast-peers

# IPv4: Block special-purpose address ranges
# Current network - prevents 0.0.0.0 bypass (CVE-2020-26262)
denied-peer-ip=0.0.0.0-0.255.255.255

# Private networks (RFC1918)
denied-peer-ip=10.0.0.0-10.255.255.255
denied-peer-ip=172.16.0.0-172.31.255.255
denied-peer-ip=192.168.0.0-192.168.255.255

# Loopback - prevents localhost access
denied-peer-ip=127.0.0.0-127.255.255.255

# Link-local - prevents AWS metadata and similar services
denied-peer-ip=169.254.0.0-169.254.255.255

# Shared address space (RFC6598)
denied-peer-ip=100.64.0.0-100.127.255.255

# IETF Protocol Assignments
denied-peer-ip=192.0.0.0-192.0.0.255

# Documentation/TEST-NET ranges
denied-peer-ip=192.0.2.0-192.0.2.255
denied-peer-ip=198.51.100.0-198.51.100.255
denied-peer-ip=203.0.113.0-203.0.113.255

# IPv6 to IPv4 relay (deprecated)
denied-peer-ip=192.88.99.0-192.88.99.255

# AS112-v4 DNS infrastructure anycast (RFC7535)
denied-peer-ip=192.31.196.0-192.31.196.255

# AMT multicast tunneling anycast (RFC7450)
denied-peer-ip=192.52.193.0-192.52.193.255

# AS112 DNS infrastructure anycast (RFC7534)
denied-peer-ip=192.175.48.0-192.175.48.255

# Benchmark testing
denied-peer-ip=198.18.0.0-198.19.255.255

# Multicast (RFC5771) - also covered by no-multicast-peers above
denied-peer-ip=224.0.0.0-239.255.255.255

# Reserved/future use (includes broadcast)
denied-peer-ip=240.0.0.0-255.255.255.255

# IPv6: Block special-purpose address ranges
# Loopback
denied-peer-ip=::1

# IPv4-mapped IPv6 addresses (prevents CVE-2026-27624 bypass)
denied-peer-ip=::ffff:0.0.0.0-::ffff:255.255.255.255

# NAT64 well-known prefix (RFC6052)
denied-peer-ip=64:ff9b::-64:ff9b::ffff:ffff

# Local-use NAT64 (RFC8215)
denied-peer-ip=64:ff9b:1::-64:ff9b:1:ffff:ffff:ffff:ffff:ffff

# Discard prefix (RFC6666)
denied-peer-ip=100::-100::ffff:ffff:ffff:ffff

# Dummy IPv6 prefix (RFC9780)
denied-peer-ip=100::1:0:0:0:0-100::1:ffff:ffff:ffff:ffff

# IETF Protocol Assignments (includes Teredo)
denied-peer-ip=2001::-2001:1ff:ffff:ffff:ffff:ffff:ffff:ffff

# Documentation range (RFC3849)
denied-peer-ip=2001:db8::-2001:db8:ffff:ffff:ffff:ffff:ffff:ffff

# 6to4 (deprecated)
denied-peer-ip=2002::-2002:ffff:ffff:ffff:ffff:ffff:ffff:ffff

# AS112 DNS infrastructure anycast (RFC7534)
denied-peer-ip=2620:4f:8000::-2620:4f:8000:ffff:ffff:ffff:ffff:ffff

# Documentation range (RFC9637)
denied-peer-ip=3fff::-3fff:fff:ffff:ffff:ffff:ffff:ffff:ffff

# SRv6 SID block (RFC9602)
denied-peer-ip=5f00::-5f00:ffff:ffff:ffff:ffff:ffff:ffff:ffff

# Unique local addresses (ULA)
denied-peer-ip=fc00::-fdff:ffff:ffff:ffff:ffff:ffff:ffff:ffff

# Link-local
denied-peer-ip=fe80::-febf:ffff:ffff:ffff:ffff:ffff:ffff:ffff

Allow-listing specific media servers

If peer-to-peer media is not needed, the most restrictive approach is to allow-list only your media server IPs. This is what Zoom did to address C2 operation abuse through their TURN servers.

# Allow relay only to specific media server IPs
allowed-peer-ip=203.0.113.10
allowed-peer-ip=203.0.113.11
allowed-peer-ip=2001:db8::1

# Deny everything else (required - allowed-peer-ip doesn't implicitly deny)
denied-peer-ip=0.0.0.0-255.255.255.255
denied-peer-ip=::-ffff:ffff:ffff:ffff:ffff:ffff:ffff:ffff

Protocol hardening

Disabling unnecessary features

Each protocol feature you leave enabled expands your attack surface. For the security rationale, see the protocol hardening section of our best practices guide.

# Disable STUN CHANGE_REQUEST (RFC5780 NAT behavior discovery)
# This feature is rarely needed and expands attack surface
no-rfc5780

# Disable TURN relay entirely - only serve STUN
# Use this if you don't need relay functionality at all
# stun-only

# Disable STUN, keep only TURN relay
# no-stun

# Disable DTLS if not using encrypted TURN connections
# Only disable if your deployment uses TLS or doesn't need encryption
# no-dtls

Disabling UDP listening

Disabling UDP listening forces clients to connect to the TURN server over TCP or TLS. The server still relays media over UDP to peers, so the relay leg is unaffected. However, the client-to-server leg over TCP can introduce latency under lossy network conditions due to retransmissions and head-of-line blocking. This eliminates the primary DDoS amplification vector since TCP’s three-way handshake makes source IP spoofing impractical.

# Disable UDP listening - clients must connect via TCP/TLS
# Media is still relayed over UDP between TURN server and peers
no-udp

# Listen on TCP only
listening-port=3478
tls-listening-port=5349

Disabling TCP relay

TCP relay (RFC 6062) allows establishing raw TCP connections through the TURN server. If you only support UDP media (typical for WebRTC), disabling it reduces the attack surface for relay abuse.

# Disable TCP relay functionality (RFC 6062)
# Clients can still connect to TURN server over TCP,
# but cannot relay TCP connections to peers
no-tcp-relay

Requiring authentication for STUN Binding

By default, coturn allows unauthenticated STUN Binding requests. This is needed for ICE connectivity checks in standard WebRTC, but in closed deployments where all clients use TURN allocations, you can require authentication for STUN too:

# Require authentication for STUN Binding requests
# WARNING: Breaks standard ICE connectivity checks
secure-stun

Mitigating amplification and reflection attacks

As we cover in our threats analysis, attackers abuse TURN servers for DDoS amplification by sending unauthenticated requests (Allocate Requests, STUN Binding Requests) with spoofed source IPs. The server responds with larger error messages, giving roughly 4x amplification directed at the victim.

The honest answer is that coturn doesn’t have great configuration knobs for this. You can’t tell it “don’t respond to unauthenticated requests” because ICE connectivity checks rely on unauthenticated STUN. Disabling UDP listening entirely (no-udp, covered above) eliminates the vector but adds latency on the client-to-server leg (media relay to peers still uses UDP).

What actually helps at the coturn level:

# Disable RFC5780 - reduces unauthenticated response surface
# This is the default since coturn 4.7.0, but set it explicitly
# if you're running an older version
no-rfc5780

# Don't advertise server version in responses
# (marginally reduces response size)
# On coturn 4.7.0+, the software attribute is already off by default.
# On 4.6.x, use no-software-attribute to disable it.
no-software-attribute

You can also reduce amplification by using a short realm value. The realm is included in every 401 Unauthorized response, so a shorter realm means smaller responses. For WebRTC use cases, the realm value doesn’t serve a functional purpose beyond credential scoping, so something short like t works fine:

# Short realm reduces 401 response size (amplification mitigation)
realm=t

The real mitigations for amplification are at the network level, not in coturn config. See the rate limiting section of our best practices guide for UDP rate limiting with iptables/nftables, BCP38, and DDoS mitigation services.

Dangerous options: never enable in production

coturn has a few configuration options that are outright dangerous for production use. If you see any of these in your config, remove them.

# DANGEROUS: Disables all authentication. Anyone can use your TURN server.
# no-auth

# DANGEROUS: Allows relay to loopback addresses (127.x.x.x, ::1).
# allow-loopback-peers

# DANGEROUS: NON-STANDARD server relay mode.
# coturn's own source code warns: "NON-STANDARD AND DANGEROUS OPTION"
# server-relay

Web admin and CLI interfaces

coturn ships with a CLI telnet interface and an HTTPS web admin panel. Both have had security issues and should be handled with care.

CLI interface

The CLI is a telnet-based management interface. We recommend disabling it entirely unless you have a specific need for it:

# Disable CLI (recommended)
no-cli

If you do need the CLI, at minimum bind it to localhost and set a strong password:

# If CLI is required, restrict access
cli-ip=127.0.0.1
cli-port=5766
cli-password=YOUR_STRONG_CLI_PASSWORD

Web admin panel

The web admin panel has had a serious authentication bypass bug: from around 2019 until the fix in coturn 4.9.0, the password check was inverted so that any wrong password was accepted. We recommend not enabling it at all. If you need it, make sure you’re on 4.9.0+ and bind it to a management network:

# Only enable on 4.9.0+ and bind to management network
# web-admin
# web-admin-ip=127.0.0.1
# web-admin-port=8080

Rate limiting

Rate limiting protects against resource exhaustion, log flooding, and abuse. For the full rationale, see the rate limiting section of our best practices guide.

coturn’s rate limiting parameters all default to 0 (unlimited). The right values depend entirely on your deployment: how many concurrent users you expect, what bandwidth your server has, and what your media profiles look like. There’s no universal “secure” number we can give you here.

What we can tell you is what knobs are available:

# Per-user allocation limit (default: 0 = unlimited)
# How many simultaneous TURN allocations a single user can hold
user-quota=0

# Total server-wide allocation limit (default: 0 = unlimited)
total-quota=0

# Limit allocation lifetime (default: 3600s)
# Shorter lifetimes mean abandoned allocations get cleaned up faster
max-allocate-lifetime=3600

# Per-session bandwidth limit in bytes/sec (default: 0 = unlimited)
# Prevents a single session from consuming all server bandwidth
max-bps=0

# Total server-wide bandwidth capacity in bytes/sec (default: 0 = unlimited)
bps-capacity=0

# Channel and permission lifetimes (defaults: 600s and 300s)
# These are RFC defaults. Shorter values reduce the abuse window
# for established sessions but increase refresh traffic.
# channel-lifetime=600
# permission-lifetime=300

# Enable logging for security monitoring
log-file=/var/log/coturn/turnserver.log
syslog

The important thing is to set something rather than leaving everything unlimited. Start with values that match your expected peak usage with some headroom, monitor, and tighten from there. For a small deployment with a few hundred concurrent users, user-quota=100 and total-quota=10000 are reasonable starting points, but your mileage will vary.

Authentication

We recommend time-limited credentials with a shared secret for dynamic credential generation.

# Use time-limited credentials (recommended)
lt-cred-mech
use-auth-secret
static-auth-secret=YOUR_SECRET_KEY_HERE

# Credential lifetime (matches your API token expiry)
max-allocate-lifetime=3600

Do keep in mind that authentication provides limited protection for public conferencing systems where anyone can register or join anonymous meetings. In those cases, you must rely on the other controls: network isolation, access control rules, and rate limiting.

Logging and monitoring

Monitoring helps you catch relay abuse, DoS attacks, and unusual behavior before they cause real damage.

# Enable detailed logging
verbose
log-file=/var/log/coturn/turnserver.log

# Log to syslog for centralized monitoring
syslog

# Optionally disable log colors for parsing
simple-log

What to alert on

• Sustained high allocation rates (potential DoS)
• Repeated access control violations from the same IP (someone is probing)
• Unusual bandwidth spikes
• High error rates or authentication failures

Use SIEM systems or custom scripts to parse coturn logs and alert on suspicious patterns.

Process isolation

Running coturn as a dedicated unprivileged user limits the damage if the process is compromised. This is basic defense in depth.

# Run as dedicated user/group (create with: useradd -r -s /bin/false turnserver)
proc-user=turnserver
proc-group=turnserver

Of course, if you’re running coturn in a container, the container’s user namespace handles this. But for bare-metal or VM deployments, proc-user and proc-group are essential.

Complete configuration templates

What follows are three complete templates at different security levels. Pick the one that fits your deployment and adjust from there.

Minimal secure config

This is the bare minimum for production. Use it as a starting point, then add hardening based on your requirements. (View on GitHub)

# Minimal Secure coturn Configuration (4.6.0+)
# Save as: /etc/turnserver.conf

# Listening configuration
listening-port=3478
tls-listening-port=5349
listening-ip=YOUR_PUBLIC_IP

# Relay configuration
relay-ip=YOUR_PUBLIC_IP
external-ip=YOUR_PUBLIC_IP

# Authentication
lt-cred-mech
use-auth-secret
static-auth-secret=CHANGE_THIS_SECRET
realm=turn.example.com

# Access control - block internal ranges
no-multicast-peers
denied-peer-ip=0.0.0.0-0.255.255.255
denied-peer-ip=10.0.0.0-10.255.255.255
denied-peer-ip=127.0.0.0-127.255.255.255
denied-peer-ip=169.254.0.0-169.254.255.255
denied-peer-ip=172.16.0.0-172.31.255.255
denied-peer-ip=192.168.0.0-192.168.255.255
denied-peer-ip=::1
denied-peer-ip=::ffff:0.0.0.0-::ffff:255.255.255.255
denied-peer-ip=fc00::-fdff:ffff:ffff:ffff:ffff:ffff:ffff:ffff
denied-peer-ip=fe80::-febf:ffff:ffff:ffff:ffff:ffff:ffff:ffff

# Rate limiting - tune these to your expected usage
user-quota=100
total-quota=10000
max-allocate-lifetime=3600

# Logging
log-file=/var/log/coturn/turnserver.log
syslog

Recommended secure config

This is what we recommend for most production deployments. It adds TLS, comprehensive IP blocking, protocol hardening, and monitoring on top of the minimal config. (View on GitHub)

# Recommended Secure coturn Configuration (4.6.0+)
# Save as: /etc/turnserver.conf

# Listening configuration
listening-port=3478
tls-listening-port=5349
listening-ip=YOUR_PUBLIC_IP

# Relay configuration
relay-ip=YOUR_PUBLIC_IP
external-ip=YOUR_PUBLIC_IP
min-port=49152
max-port=65535

# Authentication
lt-cred-mech
use-auth-secret
static-auth-secret=CHANGE_THIS_SECRET
realm=turn.example.com

# TLS/DTLS (recommended for encrypted TURN)
cert=/etc/coturn/cert.pem
pkey=/etc/coturn/privkey.pem
cipher-list="HIGH"
# TLS 1.0 and 1.1 are disabled by default since coturn 4.7.0
# On coturn <= 4.6.x, uncomment the following two lines:
# no-tlsv1
# no-tlsv1_1

# Access control - comprehensive IP blocking (based on IANA special-purpose registries)
no-multicast-peers
denied-peer-ip=0.0.0.0-0.255.255.255
denied-peer-ip=10.0.0.0-10.255.255.255
denied-peer-ip=100.64.0.0-100.127.255.255
denied-peer-ip=127.0.0.0-127.255.255.255
denied-peer-ip=169.254.0.0-169.254.255.255
denied-peer-ip=172.16.0.0-172.31.255.255
denied-peer-ip=192.0.0.0-192.0.0.255
denied-peer-ip=192.0.2.0-192.0.2.255
denied-peer-ip=192.31.196.0-192.31.196.255
denied-peer-ip=192.52.193.0-192.52.193.255
denied-peer-ip=192.88.99.0-192.88.99.255
denied-peer-ip=192.168.0.0-192.168.255.255
denied-peer-ip=192.175.48.0-192.175.48.255
denied-peer-ip=198.18.0.0-198.19.255.255
denied-peer-ip=198.51.100.0-198.51.100.255
denied-peer-ip=203.0.113.0-203.0.113.255
denied-peer-ip=224.0.0.0-239.255.255.255
denied-peer-ip=240.0.0.0-255.255.255.255
denied-peer-ip=::1
denied-peer-ip=::ffff:0.0.0.0-::ffff:255.255.255.255
denied-peer-ip=64:ff9b::-64:ff9b::ffff:ffff
denied-peer-ip=64:ff9b:1::-64:ff9b:1:ffff:ffff:ffff:ffff:ffff
denied-peer-ip=100::-100::ffff:ffff:ffff:ffff
denied-peer-ip=100::1:0:0:0:0-100::1:ffff:ffff:ffff:ffff
denied-peer-ip=2001::-2001:1ff:ffff:ffff:ffff:ffff:ffff:ffff
denied-peer-ip=2001:db8::-2001:db8:ffff:ffff:ffff:ffff:ffff:ffff
denied-peer-ip=2002::-2002:ffff:ffff:ffff:ffff:ffff:ffff:ffff
denied-peer-ip=2620:4f:8000::-2620:4f:8000:ffff:ffff:ffff:ffff:ffff
denied-peer-ip=3fff::-3fff:fff:ffff:ffff:ffff:ffff:ffff:ffff
denied-peer-ip=5f00::-5f00:ffff:ffff:ffff:ffff:ffff:ffff:ffff
denied-peer-ip=fc00::-fdff:ffff:ffff:ffff:ffff:ffff:ffff:ffff
denied-peer-ip=fe80::-febf:ffff:ffff:ffff:ffff:ffff:ffff:ffff

# Protocol hardening
no-rfc5780
no-tcp-relay

# Rate limiting - tune these to your expected usage
user-quota=100
total-quota=10000
max-allocate-lifetime=3600
max-bps=0               # set based on your server bandwidth
bps-capacity=0          # set based on your server bandwidth

# Logging and monitoring
log-file=/var/log/coturn/turnserver.log
syslog
verbose

# Security options
no-cli
no-software-attribute
stale-nonce=600
proc-user=turnserver
proc-group=turnserver

High-security config

Maximum restrictions for sensitive deployments: government, healthcare, financial services. This uses an allow-list approach for peer IPs, disables plain (unencrypted) listeners so clients must connect via TLS/DTLS, enforces TLS 1.3 only, and applies tighter rate limits. (View on GitHub)

# High-Security coturn Configuration (4.6.0+)
# Save as: /etc/turnserver.conf

# Listening configuration
listening-port=3478
tls-listening-port=5349
listening-ip=YOUR_PUBLIC_IP

# Relay configuration
relay-ip=YOUR_PUBLIC_IP
external-ip=YOUR_PUBLIC_IP
min-port=49152
max-port=65535

# Authentication - require encrypted connections
lt-cred-mech
use-auth-secret
static-auth-secret=CHANGE_THIS_SECRET
realm=turn.example.com

# TLS/DTLS - enforce strong encryption
cert=/etc/coturn/cert.pem
pkey=/etc/coturn/privkey.pem
cipher-list="ECDHE-RSA-AES256-GCM-SHA384:ECDHE-RSA-AES128-GCM-SHA256"
# TLS 1.0 and 1.1 are disabled by default since coturn 4.7.0
# On coturn <= 4.6.x, uncomment the following two lines:
# no-tlsv1
# no-tlsv1_1
no-tlsv1_2  # TLS 1.3 only

# Access control - whitelist approach for maximum restriction
# Only allow relay to specific media server IPs
allowed-peer-ip=203.0.113.10
allowed-peer-ip=203.0.113.11
denied-peer-ip=0.0.0.0-255.255.255.255
denied-peer-ip=::-ffff:ffff:ffff:ffff:ffff:ffff:ffff:ffff

# Protocol hardening - disable everything optional
no-udp    # Disable plain UDP listeners (clients must use DTLS/TLS)
no-tcp    # Disable plain TCP listeners (clients must use TLS)
no-rfc5780
no-tcp-relay
no-multicast-peers
no-cli
secure-stun  # Require auth for STUN Binding (breaks standard ICE)

# Rate limiting - tighter values for restricted deployments
user-quota=50
total-quota=5000
max-allocate-lifetime=1800   # 30 minutes
max-bps=0                    # set based on your server bandwidth
bps-capacity=0               # set based on your server bandwidth
channel-lifetime=300         # 5 minutes (default: 600)
permission-lifetime=180      # 3 minutes (default: 300)

# Logging
log-file=/var/log/coturn/turnserver.log
syslog
verbose
log-binding

# Security hardening
no-software-attribute   # Don't advertise server version
stale-nonce=300         # Short nonce lifetime
proc-user=turnserver
proc-group=turnserver

Version-specific gotchas

Configuration parameters change between coturn versions, and some of these changes can trip you up. Here’s what to watch out for.

coturn 4.9.0

• Fixes CVE-2026-27624: IPv4-mapped IPv6 addresses (::ffff:x.x.x.x) could bypass all denied-peer-ip rules for IPv4 ranges. This is a bypass of the earlier CVE-2020-26262 fix.
• Fixes inverted password check in the web admin interface (any wrong password was accepted since ~2019)
• Multiple buffer overflow and null termination fixes across DB drivers, HTTP server, and STUN message handling
• Migrated deprecated OpenSSL APIs to modern EVP interface

coturn 4.8.x

• Socket buffer size now configurable: sock-buf-size
• Improved random number generation (CVE-2025-69217)
• Default configurations are more secure out of the box

coturn 4.7.0

• TLS version defaults flipped: no-tlsv1 and no-tlsv1_1 were removed. TLS 1.0 and 1.1 are now disabled by default (secure-by-default). To re-enable them (not recommended), use tlsv1 or tlsv1_1. The no-tlsv1_2 option still exists to force TLS 1.3 minimum.
• Software attribute default flipped: no-software-attribute is deprecated. The software version attribute is now hidden by default. Use software-attribute to opt in (for debugging). The deprecated no-software-attribute still works but is unnecessary on 4.7.0+.
• RFC5780 default flipped: no-rfc5780 is deprecated. RFC5780 (NAT behavior discovery) is now disabled by default, reducing the unauthenticated response surface. Use rfc5780 to opt in if needed. On older versions, set no-rfc5780 explicitly.
• If you’re upgrading from 4.6.x, remove no-tlsv1 and no-tlsv1_1 from your config (they are removed and produce Bad configuration format warnings on 4.7.0+). You can also remove no-rfc5780 and no-software-attribute since their behavior is now the default on 4.7.0+ (these are deprecated but silently accepted).

coturn 4.6.x

• no-rfc5780 option added (disables NAT behavior discovery, reducing unauthenticated response surface)
• allocation-default-address-family option added (replaces deprecated keep-address-family)
• Improved IPv6 handling
• Better default access controls

coturn 4.5.2

• Fixes CVE-2020-26262 (0.0.0.0 and IPv6 loopback bypass)
• Default blocks for loopback addresses
• Minimum recommended version for production

Vulnerability history: why updating matters

Keeping coturn updated is the single most critical security control. coturn has had its share of serious vulnerabilities over the years:

• CVE-2026-27624 (fixed in 4.9.0, CVSS 7.2 High): IPv4-mapped IPv6 bypass of denied-peer-ip ACL, a bypass of the CVE-2020-26262 fix
• Web admin auth bypass (fixed in 4.9.0): Inverted password check let any wrong password log in
• Multiple buffer overflows (fixed in 4.9.0): In AES decryption, MySQL driver, HTTP server, and STUN method handling
• CVE-2025-69217 (fixed in 4.8.0): Improved random number usage
• CVE-2020-26262 (fixed in 4.5.2): Access control bypass via 0.0.0.0 and IPv6 loopback
• CVE-2020-4067: Information disclosure, buffer exposure
• CVE-2018-4056 (CVSS 9.8 Critical): SQL injection allowing arbitrary SQL execution
• Inherited OpenSSL vulnerabilities: coturn links OpenSSL for TLS/DTLS, so any OpenSSL CVEs in your distribution’s library version also affect coturn

# Check current version
turnserver --version

# Update via package manager (Debian/Ubuntu)
apt update && apt upgrade coturn

# Or Docker (check https://github.com/coturn/coturn/releases for current version)
docker pull coturn/coturn:latest

Further reading

• TURN Server Security Best Practices - Implementation-agnostic security principles
• TURN Security Threats: A Hacker’s View - Threat analysis and real-world attacks
• How we abused Slack’s TURN servers - $3,500 bug bounty writeup
• CVE-2020-26262: coturn access control bypass
• coturn-secure-config - All templates from this guide with Docker test environment
• coturn GitHub
• coturn Releases