RTC security
Newsletter

Curated RTC news research, news and occasional updates by Enable Security.

Hello there,

Welcome to the June edition of the RTCSec newsletter, the one that covers VoIP and WebRTC security. This one has an unusual number of stories about TURN, the NAT-traversal protocol used in WebRTC, which has been causing a lot of security headaches: a ransomware crew tunneling its command-and-control through Microsoft Teams TURN relays, a new TURN attack toolkit from SySS, and another batch of coturn CVEs.

In this edition, we also cover:

SIP open relay and toll fraud attacks detected by FRAFOS
Vulnerabilities in coturn, FreeSWITCH, FreePBX, Asterisk and various other projects
Our news: a new DVRTC WebRTC scenario, plus a refresh of our coturn secure configuration guide

The RTCSec newsletter is a free periodic newsletter bringing you commentary and news around VoIP and WebRTC security. We cover both defensive and offensive security as they relate to Real-time Communications.

What is RTC security anyway? Real-time communications security determines if you can safely communicate in real time - whether it be with other humans or machines.

You may sign up to receive the RTCSec newsletter here. If you like what we’re doing, you’re most welcome to:

Forward it to those who may find this newsletter particularly fruitful.
Let us know if there are any RTC security news items we should cover.

To view past issues, please visit our website at https://www.enablesecurity.com/newsletter/.

Our news

CommCon 2026: attacking WebRTC conferencing with DVRTC

Earlier this month, I gave a short talk at CommCon 2026 in Düsseldorf called “Attacking WebRTC Conferencing: A New Scenario for Damn Vulnerable Real-Time Communications”, introducing conferencing1, the first WebRTC-native scenario for DVRTC. It pairs a custom-built Meet-lookalike frontend (“BluePill Meetings”) with Janus as the media server and WebSocket signaling, so the lab finally covers conferencing rather than just the SIP stacks in pbx1 and pbx2.

The demo makes one point: a signaling connection is not authorization. The attacker is a normal user. They create a meeting, the frontend hands them a secret URL onto the Janus signaling channel, and from that one legitimate connection they can list every room on the server, eavesdrop on calls already in progress, join rooms they were never invited to, and kick participants. Janus ships the controls to prevent exactly this; the scenario deliberately leaves them off and the application does nothing to make up for it, so it’s a deployment problem, not a Janus flaw. And it mirrors almost exactly what we saw in a recent pentest.

This scenario is still work in progress. The signaling abuse above is the part that works today; other attack surfaces (XSS leading to media-permission abuse, and signaling-channel hijacking) are still being developed. conferencing1 is already in the public repo, so if you want to play with it and shape where it goes, grab it and tell me what conferencing attacks you’d want to see in there.

Updated our coturn security configuration guide for coturn’s new amplification defenses

We refreshed our coturn security configuration guide for two sets of changes in recent coturn releases, one of which retires advice we have been repeating for a while.

coturn 4.14.0 finally ships a native answer to the reflection and amplification problem. When we wrote about TURN reflection attacks in June 2025 and in our best practices post, coturn had no good knob for it: an unauthenticated request produces a larger 401 response than the trigger, so a spoofed source IP turns the server into a UDP reflector. 4.14.0 adds an opt-in unauthorized-ratelimit parameter (disabled by default) which, when enabled, caps 401 Unauthorized responses per source IP (default 10 per second); past the cap coturn goes silent for that source.

coturn 4.13.1 adds secure-by-default hardening. Link-local, ULA and site-local relay peers are now denied by default, and coturn auto-denies its own database backend endpoints as relay peers, so an attacker cannot point a relay at the Redis or PostgreSQL instance behind the server. It also canonicalizes all IPv4-in-IPv6 encodings before peer-IP checks, covering IPv4-compatible (::a.b.c.d) and NAT64 formats. That is the systematic fix for the IPv4-mapped IPv6 ACL bypasses CVE-2026-27624 (which we covered in February) and the newly assigned CVE-2026-53450, a ::ffff:127.0.0.1 bypass of the default loopback protection: rather than patching the handful of functions that missed the v4-mapped case, coturn now normalizes the address once up front so the whole class of encoding tricks stops working.

We also bumped the guide’s version-specific gotchas and the three config templates (minimal, recommended, high-security) to match the new defaults, so it is a good moment to revisit your config.

What’s happening?

coturn assigns three more CVEs: a default loopback bypass, admin-panel SQL injection and a CLI file write

coturn published another batch of GHSA advisories on June 26, assigning CVE numbers to three fixes that already shipped in 4.12.0 and 4.13.0. This follows the May 24 batch we covered last month and continues the pattern of Pavel Punsky working through both self-found and externally reported issues.

The one that matters in a default deployment is CVE-2026-53450 (CVSS 7.4), yet another IPv4-mapped IPv6 loopback bypass in the same vein as CVE-2026-27624 that we covered in February. An authenticated client can request a permission or channel binding for 127.0.0.1 by encoding it as ::ffff:127.0.0.1, which slips past coturn’s default loopback protection and can reach services bound only to localhost on the TURN host. This one hits the default configuration, so it is the reason to upgrade. It is fixed in 4.13.0, and 4.13.1 follows up by canonicalizing all IPv4-in-IPv6 encodings before the peer-IP checks, so the whole class of bypasses stops working.

The other two need the admin interfaces exposed, which they are not by default. CVE-2026-53448 (CVSS 7.2) is a SQL injection in the HTTPS admin panel’s delete operations. It needs --web-admin enabled and is fixed in 4.12.0. CVE-2026-53449 (CVSS 6.5) is a path traversal in the CLI psd (print sessions dump) command and is fixed in 4.13.0.

As we said about the web-admin XSS in the May batch, if you are exposing coturn’s web-admin or CLI interfaces to anyone untrusted, these bugs are the least of your problems. The loopback bypass is the one to act on for everyone else. Upgrade to 4.13.0 or later, and if amplification is a concern, 4.14.0 adds a native rate limit for that too.

DragonForce hides its C2 inside Microsoft Teams TURN relays

DragonForce has a custom backdoor that tunnels its command-and-control traffic through Microsoft Teams TURN relays, according to Symantec’s Carbon Black threat hunters (also presented at Area41 2026 by Thibaut Passilly). Symantec calls it the first publicly documented case of a threat actor abusing TURN relay infrastructure for C2.

The backdoor, Backdoor.Turn, grabs an anonymous Teams visitor token from Microsoft’s Skype-backed identity services, connects through a legitimate Microsoft Teams TURN relay, then upgrades to a QUIC session carrying encrypted C2 to the attacker’s server. On the wire it looks like an ordinary Teams call, and since most networks safelist Microsoft and Teams ranges for call quality and skip TLS inspection on them, it rides straight through perimeter controls. A second variant swaps QUIC for KCP with custom AES.

The rest of the intrusion is standard ransomware tradecraft (suspected MSSQL initial access, DLL sideloading, Active Directory reconnaissance, credential theft, lateral movement); the TURN abuse is what makes the C2 hard to spot.

We covered the technique behind this last year: Praetorian’s “Ghost Calls” research showed how Zoom and Teams TURN servers can be turned into covert C2 tunnels, building on our own 2018 Slack TURN work. DragonForce takes that idea out of the lab and into a live ransomware intrusion, abusing the same blind spot: networks that safelist conferencing infrastructure wholesale. Symantec published indicators of compromise.

Watch the presentation on YouTube.

TURNado, a TURN attack toolkit from SySS

Moritz Abrell of SySS released TURNado, an open-source toolkit for testing and exploiting TURN servers, with a writeup of the attacks it automates. It targets UDP relays (TCP allocations are mostly disabled in practice) and covers the TURN abuse categories that recur in real deployments.

An info mode reads the XOR-MAPPED-ADDRESS attribute to disclose the internal IP of a TURN server behind NAT. UDP forwarding relays arbitrary traffic (QUIC/HTTP/3, SMB, even SSH3) to destinations the relay should not reach, and where peer permissions are too loose that includes loopback (127.0.0.1, ::1) and private ranges, turning the relay into a path to internal services. It can also stand up a SOCKS proxy or a full layer-3 IP tunnel (Linux) to punch outbound through a firewall, plus a DoS mode that exhausts the server through mass allocations. Abrell demonstrates it against Microsoft Teams TURN as well as generic deployments.

Incidentally these are all features we had in our internal tooling, but we never released our tools publicly so this is a very useful addition to the awesome-rtc-hacking OpenSource tools list!

The class of problem is not new, but having it in one tool makes it easy to check your own servers. It lines up with the threat model in our three-part TURN security series from February: relay abuse to reach internal services, denial of service, and implementation bugs. If you run a TURN server, point TURNado at it before someone else does.

FRAFOS catches a toll-fraud campaign laundered through 231 misconfigured Cisco Expressways

Jiri Kuthan of FRAFOS described on LinkedIn how their traffic analysis caught a single toll-fraud actor laundering calls through other people’s phone systems. Instead of dialing the fraud destination directly, the attacker bounces call attempts through 231 corporate Cisco gateways (Expressway, VCS and UC Edge) configured to accept and forward calls from anyone on the internet, so each call reaches the destination looking like it came from a reputable enterprise (a defense contractor, a hospital, a national army) while the real source stays hidden. Same toll fraud as ever, just distributed through reputable IP addresses.

The numbers from a single 7-day window: 231 relay devices, 28 confirmed as Cisco Expressway/VCS/UC Edge by reverse DNS alone, across 30+ countries and sectors from defense and healthcare to banking, government and telecom.

Jiri is clear that this is a configuration problem, not a Cisco bug: the recurring pattern is externally reachable test and staging Expressways that never got production hardening. The open-relay conditions he calls out are familiar SIP edge mistakes, namely traversal zones that accept anonymous INVITEs from * and route by Request-URI, and overly broad search rules (.*) that send traffic to a default outbound zone even when authentication is enforced elsewhere. His advice: keep test and staging off the public internet or harden it like production, allowlist source IPs where the peer is fixed, and alert on forwarding to Request-URIs outside your known peering set.

This is the scaled-up version of an earlier observation from the same actor, where FRAFOS saw toll-fraud routing reconnaissance alongside bash reverse-shell payloads stuffed into SIP User-Agent headers, aimed at tools that pass header values to a shell unsanitised.

FRAFOS shared the full report with CISA for coordinated notification and put up a free self-check service at sip-check.frafos.com so operators can test whether their own SIP edge is an open relay. Open relays abused this way are nothing new, but it echoes Ivan Nyarko’s June 2023 honeypot research, where legitimate SIP servers got APIBAN-blocked for relaying attacker traffic and he too shipped a relay tester. The difference is the payload: scanning then, toll fraud now.

FreeSWITCH security advisories (June 2026 batch)

SignalWire shipped a large batch of FreeSWITCH security advisories fixed in the 1.11.0 and 1.11.1 releases, with mod_verto (the WebRTC/WebSocket signalling module on ports 8081/8082) taking the brunt of it. Worst first:

Pre-auth heap buffer overflow in the mod_verto HTTP POST body handler (CVE-2026-49841, CVSS 9.8): a POST Content-Length up to 10 MiB overflows a 2 MiB buffer before basic auth, so an unauthenticated attacker can aim for RCE. The one that matters most on an internet-facing Verto.
Unauthenticated SIP PUBLISH DoS via XML entity expansion (CVE-2026-45771, CVSS 7.5): a billion-laughs PIDF body parsed before any auth or ACL check pins a Sofia worker thread and, with enough entity nesting, exhausts CPU/memory until the process is OOM-killed. Reachable on any SIP profile with presence management enabled, which the default internal profile has.
Pre-auth heap overflow in libesl’s esl_recv_event() (CVE-2026-49840, CVSS 9.1): Content-Length: -1 underflows into malloc() for an attacker-controlled heap write. Affects fs_cli, mod_esl, mod_hash and other libesl apps, so it sits on the internal event-socket side, not Verto.
cJSON parser stack overflow (CVE-2026-49847, CVSS 7.5): deeply nested JSON in one unauthenticated WebSocket frame exhausts the thread stack and crashes the process.
STUN parser out-of-bounds read/write (CVE-2026-49475, CVSS 7.5): a crafted datagram to an in-progress call’s media port corrupts memory and takes the process down.
mod_verto WebSocket bandwidth amplification (CVE-2026-49842, CVSS 7.5): unauthenticated speed-test #SPU frames make a ~1 KB request pull back ~20 GB over the same TCP connection.
mod_verto pre-auth forced disconnect (CVE-2026-49843, CVSS 5.3): connections bind to a client-supplied session UUID before auth, so knowing a target’s UUID lets an attacker drop that client’s calls.
Stale bundled libexpat XML parser (CVE-2026-49472, CVSS 5.3) in the xmlrpc-c tree.
mod_verto userVariables state pollution (CVE-2026-49848, CVSS 4.3): channel variables stored before the password check let values from failed logins carry into a later authenticated session. Needs valid credentials.

So be sure to upgrade to 1.11.1, especially if you run Verto or expose SIP with presence enabled (which the default internal profile has).

Short news

Cisco Unified CM SSRF-to-RCE now exploited in the wild (CVE-2026-20230)

Cisco’s unauthenticated SSRF in the WebDialer component of Unified CM (CVE-2026-20230, CVSS 8.6) is now exploited in the wild and on CISA’s KEV list. WebDialer is off by default, but where it’s on, SSD Secure Disclosure chained the SSRF to root RCE. Fix: 14SU6 or 15SU5, or disable WebDialer.

RTC securityNewsletter