---
title: DragonForce hides C2 in Teams TURN relays, FreeSWITCH and coturn advisory batches
date: 2026-06-30
url: /newsletter/2026-06-rtcsec-news.md
---

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](https://www.enablesecurity.com/subscribe.md). 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](https://commcon.xyz/) in Düsseldorf called ["Attacking WebRTC Conferencing: A New Scenario for Damn Vulnerable Real-Time Communications"](https://www.youtube.com/watch?v=ZYB7GqOTKEI&t=5635s), introducing `conferencing1`, the first WebRTC-native scenario for [DVRTC](https://github.com/EnableSecurity/DVRTC/). It pairs a custom-built Meet-lookalike frontend ("BluePill Meetings") with [Janus](https://janus.conf.meetecho.com/) 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](https://github.com/EnableSecurity/DVRTC/) 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](https://www.enablesecurity.com/blog/coturn-security-configuration-guide.md) 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](https://github.com/coturn/coturn/releases/tag/4.14.0) finally ships a native answer to the reflection and amplification problem. When we [wrote about TURN reflection attacks in June 2025](https://www.enablesecurity.com/newsletter/2025-06-rtcsec-news/#turn-server-reflection-attacks-trigger-cloud-provider-blocking) and in our [best practices post](https://www.enablesecurity.com/blog/turn-security-best-practices.md), 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](https://github.com/coturn/coturn/releases/tag/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](https://github.com/coturn/coturn/security/advisories/GHSA-j8mm-mpf8-gvjg) (which we [covered in February](https://www.enablesecurity.com/newsletter/2026-02-rtcsec-news.md)) and the newly assigned [CVE-2026-53450](https://github.com/coturn/coturn/security/advisories/GHSA-w4hf-cr3w-6h79), 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](https://github.com/coturn/coturn/security/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](https://www.enablesecurity.com/newsletter/2026-05-rtcsec-news.md) 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](https://github.com/coturn/coturn/security/advisories/GHSA-w4hf-cr3w-6h79) (CVSS 7.4), yet another IPv4-mapped IPv6 loopback bypass in the same vein as [CVE-2026-27624](https://github.com/coturn/coturn/security/advisories/GHSA-j8mm-mpf8-gvjg) that we [covered in February](https://www.enablesecurity.com/newsletter/2026-02-rtcsec-news.md). 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](https://github.com/coturn/coturn/security/advisories/GHSA-v8hj-2xx7-xmp5) (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](https://github.com/coturn/coturn/security/advisories/GHSA-jj76-vwjw-w34r) (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](https://www.enablesecurity.com/newsletter/2026-05-rtcsec-news.md), 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](https://www.enablesecurity.com/blog/coturn-security-configuration-guide.md) 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](https://www.bleepingcomputer.com/news/security/ransomware-gang-abuses-microsoft-teams-relays-to-hide-malicious-traffic/) (also [presented at Area41 2026](https://area41-2026.txt.stfn.ch/talks/dragonforce-the-cartel-makes-a-turn-in-ransomware-capabiliti.html) 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](https://www.enablesecurity.com/newsletter/2025-08-rtcsec-news/#turn-server-abuse-ghost-calls-c2-evasion-technique) 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](https://www.youtube.com/watch?v=rBbgMN_JlHU).

### TURNado, a TURN attack toolkit from SySS

Moritz Abrell of SySS released [TURNado](https://github.com/SySS-Research/TURNado), an open-source toolkit for testing and exploiting TURN servers, with a [writeup](https://blog.syss.com/posts/turnado/) 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](https://github.com/EnableSecurity/awesome-rtc-hacking#open-source-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](https://www.enablesecurity.com/blog/turn-server-security-threats.md) 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](https://www.linkedin.com/posts/jirikuthan_telecomsecurity-voipsecurity-threatintel-activity-7469863109508390912-s-ya) 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](https://www.linkedin.com/posts/jirikuthan_telecomsecurity-voipsecurity-threatintel-activity-7467628633231282176-UadS) 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](https://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](https://www.enablesecurity.com/newsletter/2023-06-rtcsec-news/#another-open-relay-scan-detected-by-kwancros-honeypots), 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](https://github.com/signalwire/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](https://github.com/signalwire/freeswitch/security/advisories/GHSA-wfrq-qvg2-f88f), 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](https://github.com/signalwire/freeswitch/security/advisories/GHSA-5vjg-pv56-vg4c), 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](https://github.com/signalwire/freeswitch/security/advisories/GHSA-g597-9fgg-ghg9), 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](https://github.com/signalwire/freeswitch/security/advisories/GHSA-2v74-pcgh-75wg), 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](https://github.com/signalwire/freeswitch/security/advisories/GHSA-9j6h-hc95-q926), 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](https://github.com/signalwire/freeswitch/security/advisories/GHSA-p3gx-p2w7-wp35), 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](https://github.com/signalwire/freeswitch/security/advisories/GHSA-9457-fxr9-x78m), 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](https://github.com/signalwire/freeswitch/security/advisories/GHSA-4jm3-xpcm-mwwq), CVSS 5.3) in the xmlrpc-c tree.
- `mod_verto` userVariables state pollution ([CVE-2026-49848](https://github.com/signalwire/freeswitch/security/advisories/GHSA-j38x-xm7f-9p2f), 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)](https://ssd-disclosure.com/cisco-unified-communications-manager-arbitrary-file-write-to-rce/)

Cisco's unauthenticated SSRF in the WebDialer component of Unified CM ([CVE-2026-20230](https://sec.cloudapps.cisco.com/security/center/content/CiscoSecurityAdvisory/cisco-sa-cucm-ssrf-cXPnHcW), 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](https://ssd-disclosure.com/cisco-unified-communications-manager-arbitrary-file-write-to-rce/) chained the SSRF to root RCE. Fix: 14SU6 or 15SU5, or disable WebDialer.

[Original content here.](https://ssd-disclosure.com/cisco-unified-communications-manager-arbitrary-file-write-to-rce/)

#### [HP Poly VVX/Trio unauthenticated RCE via SIP (CVE-2026-0826)](https://www.rapid7.com/blog/post/ve-cve-2026-0826-critical-unauthenticated-stack-buffer-overflow-hp-poly-vvx-trio-voip-phones-fixed/)

Rapid7's Stephen Fewer found an unauthenticated stack buffer overflow in the SIP ICE-candidate parser of HP Poly VVX and Trio phones ([CVE-2026-0826](https://www.cve.org/CVERecord?id=CVE-2026-0826), CVSS 9.2), giving root RCE with a Metasploit module available. Affects VVX 150/250/350/450 and Trio 8300/8500/8800, fixed in VVX UCS 6.4.8 and Trio 8.1.7/7.2.8; needs the non-default ICE feature enabled.

[Original content here.](https://www.rapid7.com/blog/post/ve-cve-2026-0826-critical-unauthenticated-stack-buffer-overflow-hp-poly-vvx-trio-voip-phones-fixed/)

#### [Mitel MiCollab unauthenticated command injection and SQL injection (MISA-2026-0005)](https://www.mitel.com/support/security-advisories/mitel-product-security-advisory-misa-2026-0005)

Mitel disclosed several unauthenticated command injection flaws (MTLVULN-1667, 1666, 1669, 1631) and a SQL injection (MTLVULN-1640) in MISA-2026-0005, affecting MiCollab, MiVoice Business Solution Virtual Instance, and NuPoint Unified Messaging. Together they allow unauthenticated remote code execution and database exfiltration, so patch the affected products.

[Original content here.](https://www.mitel.com/support/security-advisories/mitel-product-security-advisory-misa-2026-0005)

#### [Mitel MiVoice MX-ONE authentication bypass (CVE-2025-67822)](https://www.cve.org/CVERecord?id=CVE-2025-67822)

An authentication bypass in Mitel MiVoice MX-ONE 7.3 through 7.8 SP1 ([CVE-2025-67822](https://www.cve.org/CVERecord?id=CVE-2025-67822)) gives unauthorized access to the system. Patch beyond 7.8 SP1 and segment the management network. It pairs with the MiCollab advisory above for a rough month on the Mitel side.

[Original content here.](https://www.cve.org/CVERecord?id=CVE-2025-67822)

#### [Yealink SIP-T46U: six web-interface RCE bugs with public exploits](https://attackerkb.com/topics/77a2675b-fd55-44f2-8ad7-d812fc8b350b)

A cluster of vulnerabilities in the Yealink SIP-T46U (firmware around 108.86.0.118) landed on AttackerKB, all in the phone's FastCGI web service and all with public exploit code. They split into command injection and stack buffer overflows reachable through unvalidated parameters:

- Command injection in the `/api/diagnosis/start` diagnosis handler via the `Time` parameter ([CVE-2026-12219](https://attackerkb.com/topics/77a2675b-fd55-44f2-8ad7-d812fc8b350b)).
- Command injection in the `/api/inner/tftpuploadiperf` TFTP upload handler via the `ip`/`port` parameters ([details](https://attackerkb.com/topics/eb235472-646d-45cd-80e7-98124931b48c)).
- Stack buffer overflows in `/api/inner/beforewifitest` (`port`, [CVE-2026-12218](https://attackerkb.com/topics/33c020ef-ddb7-443c-be03-6574b6348da8)), `/api/upgrade/accupgradebychunk` (`uid`, [CVE-2026-12220](https://attackerkb.com/topics/d6934849-1264-4973-8eab-1d920816832b)), `/api/upgrade/upgrade` (`uid`/`start_offset`, [CVE-2026-12221](https://attackerkb.com/topics/9a5f264d-2bcb-467c-b67d-53ca234d6861)) and the `/api/inner/bttest` Bluetooth test (`btMac`/`pin`, [CVE-2026-12222](https://attackerkb.com/topics/6347f2c8-0c2d-424f-88d7-9a86f28f3a8a)).

Most need access to the phone's management interface on the local network. Yealink fixed them in firmware 108.87.0.23 and later.

[Original content here.](https://attackerkb.com/topics/77a2675b-fd55-44f2-8ad7-d812fc8b350b)

#### [Asterisk security advisories (June 2026)](https://github.com/asterisk/asterisk/security/advisories)

Asterisk published a [batch of 20 GitHub security advisories](https://github.com/asterisk/asterisk/security/advisories). The one to watch on a default PJSIP install is an unauthenticated stack buffer overflow in MWI NOTIFY `Message-Account` parsing in `res_pjsip_pubsub` ([GHSA-589g-qgf8-m6mx](https://github.com/asterisk/asterisk/security/advisories/GHSA-589g-qgf8-m6mx), CVSS 8.2): a crafted packet corrupts the SIP transport and disables Asterisk until a restart. The RCE-capable bugs all need a non-default or deprecated module (T.140 RED text via `chan_sip`, `res_xmpp`, the ARI authorization bypasses) or valid credentials, and the rest are denial-of-service or info disclosure in optional modules (the H.323 add-on, `chan_unistim`, AMI-over-HTTP, LDAP realtime). Two more PJSIP DoS bugs (an MWI body-parser over-read and a TCP/SDP use-after-free) need an authenticated peer. Update to 20.20.1, 21.12.3, 22.10.1 or 23.4.1.

[Original content here.](https://github.com/asterisk/asterisk/security/advisories)

#### [Another batch of pjproject security advisories](https://github.com/pjsip/pjproject/security/advisories)

The pjproject advisories keep coming. After the [batch we covered in April](https://www.enablesecurity.com/newsletter/2026-04-rtcsec-news.md), a fresh set of GitHub security advisories landed in mid-June, again on the master branch:

- SDP parser out-of-bounds write in payload-type mapping ([GHSA-rfwg-w9gq-9mw2](https://github.com/pjsip/pjproject/security/advisories/GHSA-rfwg-w9gq-9mw2)), only with `PJMEDIA_SDP_NEG_MAINTAIN_REMOTE_PT_MAP` enabled (off by default).
- Pre-auth stack overflow parsing a peer certificate's SubjectAltName ([GHSA-jm2j-6rg6-qvwx](https://github.com/pjsip/pjproject/security/advisories/GHSA-jm2j-6rg6-qvwx)), GnuTLS builds only.
- One-byte overflow serializing Allow/Require/Supported/Unsupported SIP headers ([GHSA-277r-3q2j-mxcw](https://github.com/pjsip/pjproject/security/advisories/GHSA-277r-3q2j-mxcw), [CVE-2026-57160](https://github.com/pjsip/pjproject/security/advisories/GHSA-277r-3q2j-mxcw)).
- PJSUA stack overflow from too many Service-Route headers in a REGISTER response ([GHSA-xc62-j9h2-mp84](https://github.com/pjsip/pjproject/security/advisories/GHSA-xc62-j9h2-mp84)).
- HTTP client heap overflow from a bad `Content-Length` size calculation ([GHSA-59fr-724j-6fjv](https://github.com/pjsip/pjproject/security/advisories/GHSA-59fr-724j-6fjv)), needs a malicious server and non-incremental response buffering.
- SRTP/SDES stack overflow from too many `a=crypto` attributes ([GHSA-m9g3-jcj8-qjfm](https://github.com/pjsip/pjproject/security/advisories/GHSA-m9g3-jcj8-qjfm)), SRTP/SDES builds only.
- Two stack overflows in the telnet CLI ([GHSA-rpq9-9fx7-95xw](https://github.com/pjsip/pjproject/security/advisories/GHSA-rpq9-9fx7-95xw), [GHSA-9c8q-h38q-p85j](https://github.com/pjsip/pjproject/security/advisories/GHSA-9c8q-h38q-p85j)), only if you expose the unauthenticated telnet CLI.

These are all master-branch-only fixes with no tagged pjproject release. The latest Asterisk bundles pjproject 2.17 (affected) and has issued no advisory: most of the batch is in components it doesn't link, and on a default OpenSSL `res_pjsip` build only the low-severity SIP header overflow (GHSA-277r-3q2j-mxcw) realistically applies. If you build against pjproject directly, patch your 2.17 tree against the master commits.

[Original content here.](https://github.com/pjsip/pjproject/security/advisories)

#### [FreePBX security advisories (June 2026)](https://github.com/FreePBX/security-reporting/security/advisories)

FreePBX published a [batch of advisories](https://github.com/FreePBX/security-reporting/security/advisories) across the Dashboard, API, UCP, CDR, Superfecta, Backup, Soundlang and Music on Hold modules. Nearly all require an authenticated (usually admin) session, and the one unauthenticated bug, hard-coded UCP credentials ([CVE-2026-46376](https://github.com/FreePBX/security-reporting/security/advisories/GHSA-m55x-h47x-v3gx), CVSS 9.1), needs the non-default UCP generic-template feature. Check the advisories list and update.

[Original content here.](https://github.com/FreePBX/security-reporting/security/advisories)

#### [mediasoup SCTP state cookie authentication bypass (GHSA-p7x2-g5cq-fhmq)](https://github.com/versatica/mediasoup/security/advisories/GHSA-p7x2-g5cq-fhmq)

mediasoup's SCTP stack (3.20.0 to 3.20.2) doesn't authenticate SCTP state cookies the way RFC 9260 requires, checking them against hardcoded magic bytes instead of a per-instance HMAC. An attacker can forge a COOKIE-ECHO, skip the handshake, and inject DataChannel messages. It only affects PlainTransport with SCTP and no SRTP (DTLS-protected WebRtcTransport is unaffected). Fixed in 3.20.3.

[Original content here.](https://github.com/versatica/mediasoup/security/advisories/GHSA-p7x2-g5cq-fhmq)

#### [Pipecat unauthenticated WebSocket call-control abuse (GHSA-j8cv-x86q-rj85)](https://github.com/advisories/GHSA-j8cv-x86q-rj85)

Pipecat's telephony dev runner exposes an unauthenticated `/ws` WebSocket that reads a caller-supplied call ID and hangs it up using the server's own Twilio, Telnyx, or Plivo credentials ([CVE-2026-54695](https://github.com/advisories/GHSA-j8cv-x86q-rj85), CVSS 7.5). Anyone who reaches an exposed `/ws` can then terminate an active call on the operator's account, though they need a valid call ID (a long random provider SID). Fixed in 1.4.0, which adds optional HMAC token auth.

[Original content here.](https://github.com/advisories/GHSA-j8cv-x86q-rj85)

#### [Mattermost Calls plugin leaks TURN credentials in support packets (CVE-2026-6347)](https://github.com/advisories/GHSA-82j6-4fq7-fx62)

The Mattermost Calls plugin ([CVE-2026-6347](https://github.com/advisories/GHSA-82j6-4fq7-fx62), CVSS 7.6) writes TURN credentials in plaintext into exported support packets, so anyone with access to one can recover them. Fixed in Calls plugin 1.12.0 (Mattermost Server 11.5.2, 10.11.14, 11.4.4).

[Original content here.](https://github.com/advisories/GHSA-82j6-4fq7-fx62)

#### [Pion WebRTC stack: STUN and DTLS parser fixes](https://github.com/pion/dtls/security/advisories/GHSA-wg4g-wm44-ch5j)

Two remote-DoS advisories landed in the Pion Go WebRTC stack, both panics triggered by parsing a malformed peer response during connection setup: a short XOR-MAPPED-ADDRESS value in `pion/stun` ([GHSA-34rh-wp3j-6cxc](https://github.com/pion/stun/security/advisories/GHSA-34rh-wp3j-6cxc)), and a malformed ECDHE_PSK ServerKeyExchange in `pion/dtls` before v3.1.4 ([GHSA-wg4g-wm44-ch5j](https://github.com/pion/dtls/security/advisories/GHSA-wg4g-wm44-ch5j), CVE-2026-54908). Both sit on the connection-establishment path (STUN for NAT traversal, DTLS for media), so anything embedding these libraries should pull the fixes.

[Original content here.](https://github.com/pion/dtls/security/advisories/GHSA-wg4g-wm44-ch5j)

#### [libaom AV1 encoder heap buffer overflow (CVE-2026-56208)](https://www.cve.org/CVERecord?id=CVE-2026-56208)

A heap buffer overflow in libaom's AV1 encoder Look-Ahead Processing mode ([CVE-2026-56208](https://www.cve.org/CVERecord?id=CVE-2026-56208)) triggers when `g_lag_in_frames` is 1 or higher: the first-pass statistics ring buffer's wrap-around protection is bypassed, causing a 232-byte out-of-bounds heap write on every frame after the second. It matters for WebRTC sessions and transcoding services that run libaom with attacker-controllable encoder parameters, with DoS via heap corruption and potential RCE. Update libaom.

[Original content here.](https://www.cve.org/CVERecord?id=CVE-2026-56208)

#### [Chromium WebRTC memory fix (CVE-2026-11667)](https://nvd.nist.gov/vuln/detail/CVE-2026-11667)

Chromium fixed an out-of-bounds read in its WebRTC component ([CVE-2026-11667](https://nvd.nist.gov/vuln/detail/CVE-2026-11667), in 149.0.7827.103), though it needs a prior GPU-process compromise, so it acts as a sandbox-escape escalation step rather than a standalone bug. Update browsers and clients.

[Original content here.](https://nvd.nist.gov/vuln/detail/CVE-2026-11667)

#### [Android Pixel RTP/RTCP session integer overflow (CVE-2026-0161)](https://www.cve.org/CVERecord?id=CVE-2026-0161)

The CVE record for the Android Pixel RTP issue ([CVE-2026-0161](https://www.cve.org/CVERecord?id=CVE-2026-0161)) points to an integer overflow in `numberOfReportBlocks` in `RtpSession.cpp`, likely RTCP report-block handling inside the RTP session implementation. It can lead to an out-of-bounds write and remote elevation of privilege without user interaction. The public CVSS vector has `PR:L`, so this does not read as a clean unauthenticated Internet bug. Google fixed it in the [June 2026 Pixel Update Bulletin](https://source.android.com/docs/security/bulletin/pixel/2026/2026-06-01); the associated Android bug is marked non-public.

[Original content here.](https://www.cve.org/CVERecord?id=CVE-2026-0161)

#### [Real-time guardrails for voice AI agents with WebRTC](https://webrtc.ventures/2026/06/slug-voice-ai-security-webrtc-livekit-guardrails/)

WebRTC.ventures [describes a security-first architecture](https://webrtc.ventures/2026/06/slug-voice-ai-security-webrtc-livekit-guardrails/) for voice AI agents that runs protective controls inside the live voice pipeline rather than as post-processing. Built on LiveKit's WebRTC infrastructure and the GLiGuard framework, it does PII/PHI redaction, tool authorization, and audit logging before sensitive data reaches the model and before unsafe responses are spoken back. Relevant if you are building real-time voice agents that handle regulated data.

[Original content here.](https://webrtc.ventures/2026/06/slug-voice-ai-security-webrtc-livekit-guardrails/)

#### [Do you need a WebRTC security course? (Tsahi Levent-Levi)](https://www.youtube.com/watch?v=M6uDvHBCvkE)

A point we keep coming back to, made well by Tsahi Levent-Levi in a [short video](https://www.youtube.com/watch?v=M6uDvHBCvkE): WebRTC being encrypted by default (you can't turn off DTLS-SRTP, and the browser forces HTTPS or secure WebSockets for signaling) is exactly why engineers assume it's handled and skip the rest. But WebRTC is a set of building blocks, and a deployment is only as secure as whatever you bolt on top: an auto-answer that shouldn't be there, a sloppy TURN config, something in the SFU, or the application's own JavaScript. The video also plugs the paid WebRTC Security and Privacy Essentials course he runs with Philipp Hancke ([webrtccourse.com](https://webrtccourse.com)); we haven't taken it but it does look useful.

[Original content here.](https://www.youtube.com/watch?v=M6uDvHBCvkE)

#### [Reverse engineering a Viking VoIP phone protocol with Claude Code](https://www.youtube.com/watch?v=V-L0INGTEOg)

Interesting presentation about a custom VoIP protocol by Boris Starkov (ElevenLabs).

[Original content here.](https://www.youtube.com/watch?v=V-L0INGTEOg)

---

Thanks to [Vulners](https://vulners.com/) and other third parties for providing vulnerability source material.

This newsletter was prepared by Sandro Gauci and the Enable Security team for RTCSec newsletter subscribers. If you have someone in mind who would benefit from our content, please share.

To subscribe: [here](https://www.enablesecurity.com/subscribe.md)