Skip to main content
RTC Security Newsletter

Curated VoIP and WebRTC security news, research and updates by Enable Security.

Subscribe

September 2025: more RTP, FreePBX and Voice AI vulnerabilities this time

Published on Sep 30, 2025

Welcome to the latest edition of RTCSec Newsletter for September 2025. In this edition, we cover:

  • Our presentations at ClueCon and RTC.ON, clarification about DTLS-SRTP and RTP Bleed
  • FreePBX security fixes galore and technical details
  • Voice-AI and good old toll fraud
  • Round up of RTC security vulnerabilities that were addressed this month

The RTCSec newsletter is a free, periodic newsletter bringing you commentary and news about 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

RTC.ON 2025 in Kraków and our presentation about TURN security

Two weeks ago, the beautiful city of Kraków hosted a conference for audio and video developers. The event provided a great platform to explore new trends in WebRTC, video streaming, MOQ, and Voice AI technologies. RTC.ON is very well organized and professional, while still maintaining a personal, close-knit atmosphere. I highly recommend it for anyone working in this industry.

As part of this event, I delivered a presentation titled “TURNed inside out - a hacker’s view of your media relay,” which examined the security vulnerabilities and implications associated with TURN (Traversal Using Relays around NAT) servers commonly utilized in WebRTC implementations.

The following is a summary of my presentation:

  • Introduction to TURN Security: TURN servers act as relays for WebRTC traffic when direct peer-to-peer connections aren’t possible. The presentation highlights that despite being a critical component, their security is often overlooked.
  • Hacker’s Perspective: I drew parallels between modern TURN servers and older public proxy servers, emphasizing their potential for abuse.
  • Threat Model for TURN Servers:
    • TURN Relay Abuse: Attackers can use TURN servers to bypass firewalls, anonymize traffic, and access internal network resources. Examples include hacking Slack’s TURN servers to access internal AWS metadata and using Zoom/Teams TURN servers for Command and Control (C2) operations.
    • Denial of Service (DoS): TURN servers can be vulnerable to typical DoS attacks and, more uniquely, to reflection/amplification attacks, where a small spoofed request to the TURN server results in a larger response sent to a victim.
    • Software Vulnerabilities: TURN server software, like Coturn, can have critical vulnerabilities such as memory safety issues, SQL injection (CVE-2018-4056), protocol attacks, information disclosure, and access control bypasses.
  • Security Best Practices:
    • Access Control & Isolation: Isolate TURN servers on their own network, enable access control rules to deny local/internal IP ranges, and only allow traffic to legitimate media servers (like Zoom’s approach).
    • Protocol Hardening: Disable unnecessary features (RFC5780, RFC3489, DTLS transport), disable UDP listening and TCP peer relaying if not needed, and implement rate limiting.
    • Operations & Monitoring: Protect TURN credentials, keep servers updated, and monitor traffic for incidents.
  • Key Takeaways: TURN servers are powerful proxies, infrastructure can be weaponized, and security is a three-step process: isolate, restrict (limit attack surface), and update.

The presentation encourages staying informed about RTC security and thorough testing of WebRTC solutions. While the presentation video is not yet available, you can check out our slides.

Presentation on updates to RTP Bleed and RTP Inject is now on YouTube

My presentation at ClueCon 2025, “Media Security Is Hard”, is now available on YouTube. With the subtitle “The Many Ways RTP & SRTP Still Fail Us”, it is a sobering talk about how these security weaknesses are still thriving even if most people in the industry believe that they were fixed years ago.

I think this is the best overview of these misunderstood-but-persistent vulnerabilities and includes updates on how open-source software such as rtpengine is being updated. To address these vulnerabilities, we need both security updates and configuration changes.

In the near future, we’ll have more news on this topic as we’re still working with open-source developers to improve security options for RTP security. We also hope that proprietary solution vendors reach out and ask for our help on this topic once they get a break from fixing web interface security issues 😉.

If you don’t have 33 minutes for the video, check out last month’s summary or slides.

Clarification on the fix for the RTP bleed vulnerability for DTLS-SRTP

This month there was a post on the rtpengine mailing list that is worth paying attention to: “Need clarification on the fix for RTP bleed vulnerability for DTLS-SRTP”. The post’s author found it difficult to understand how RTP bleed is applicable to DTLS-SRTP. This was our response:

You’re right to assume that an ICE check should have prevented RTP packets that come from IP addresses and ports that were previously negotiated through ICE. However, in the current codebase, rtpengine only checks incoming DTLS packets against the ICE check in ice_peer_address_known().

RTP Bleed was therefore applicable before the fix because the learning mode ran before SRTP decryption. This would usually cause a Denial of Service (DoS). RTP Inject, on the other hand, in the case of DTLS-SRTP traffic, is not applicable because it fails the SRTP decryption. The attacker in this scenario does not have the correct encryption keys.

So yes, before the fixes applied in mr13.4.1.1, the text in our advisory is correct:

 There is the special case of DTLS-SRTP, typically used for WebRTC environments, which was found vulnerable to RTP Bleed but not RTP Inject. This was due to the logic applied in this case, where learning mode occurred before the RTP packets were properly validated. This has also received a security fix.

And:

In the case of DTLS-SRTP, a fix was made so that SRTP validation occurs before learning mode. We highly recommend upgrading to access these security features.

This is a complex topic with many details. As we mentioned earlier in this newsletter, we have more to publish about the nuances and security fixes in the RTP proxies that we have been researching and testing.

What’s happening?

FreePBX: explanation of CVE-2025-57819 and other disclosed vulnerabilities

Last month we covered a zero-day vulnerability in FreePBX that had Sangoma scrambling to get a fix out to its users. This month, FreePBX also fixed a number of new security issues:

Go read Chris Maj’s article about these fixes and the changes to FreePBX for the vendor’s perspective.

The security community has noticed that hacking the FreePBX system appears to be an easy way to cause serious damage.

The security experts at watchTowr Labs published a rather entertaining blog post detailing CVE-2025-57819, the vulnerability that was actively exploited last month. They deployed a fully-monitored FreePBX sensor into their global sensor network and used the logs to understand how these servers were being exploited. It turns out that multiple vulnerabilities were being exploited. The entry point was an authentication bypass/file inclusion quirk where attackers could directly hit module PHP files without needing to authenticate. This was chained to exploit an SQL injection in the Endpoint Manager, which allowed the attackers to insert a backdoor user in the database. In turn, this user could be used to insert malicious jobs into the cron_jobs table, which naturally leads to remote code execution.

They also mentioned that they had previously submitted a vulnerability to the FreePBX maintainers that wasn’t yet fixed as of the time of the blog post. This is tracked as CVE-2025-55211 and, in fact, that’s one of the security fixes that were published this month (i.e., “Authenticated Command Injection in Framework module”).

Additionally, a couple of GitHub repositories and a Metasploit module with exploits for FreePBX have appeared:

Is this a good time for a proper security review of the FreePBX web exposure? Maybe. 🙄

Voice-AI Callback Fraud: Telecom Exploitation Technique

In the past month, we saw a number of LinkedIn posts (1 2) and at least one Youtube video warning about toll fraud affecting voice AI applications. The gist is that Voice AI experts set up public online forms that allow anyone to receive a call back from a voice-AI agent. The forms accepted user-controlled phone numbers, and this behavior was abused to make calls to premium-rate numbers. Additionally, the fraudsters abusing this could keep the call going by making use of a repetitive audio recording that the voice-AI agent tried to deal with. This seems like a classic IRSF/AIT (international revenue-share fraud / artificially-inflated traffic) attack.

The best commentary I’ve seen about this was Rob Pickering’s blog post with the title “Voice-AI Industry Discovers Old School Telecoms Fraud”. I’ll quote Rob’s final words from his blog:

Treat PSTN like payments. If a public form can spend your money by placing calls, it deserves the same paranoia you reserve for charging cards: verify first, gate destinations, cap everything, and cut off in real time on anomalies. Or, more bluntly: don’t make outbound calls to unverified numbers—ever.

Nacho Ribeiro posted some recommendations to counter such attacks, before, during and after the call - writing that “Voice AI is like an F1 car without a handbrake. Put the brake on first, then hit the gas”.

Finally, a new podcast called “Traffic Light Protocol” had two episodes covering this and similar topics:

Fun times ahead!

U.S. Secret Service dismantles imminent telecommunications threat in New York tri-state area

Recent news about the U.S. Secret Service taking down a SIM farm outside of New York caught the imagination of many people, including us. What’s especially interesting are the claims of this operation ’enabling denial of services attacks’ and disrupting the United Nations General Assembly.

Such attacks are certainly possible, but Telco security experts like Dmitry Kurbatov believe this was more likely being used for what SIM farms are typically used for:

  • Robocalls, mass SMS, and scams
  • Grey-route call termination (billing circumvention)
  • SIM renting for disposable identities
  • Call-center/IVR abuse via telephony denial-of-service (TDoS)

They are less likely to be used for:

  • Paralyze New York’s telecom infrastructure
  • Enable P2P encrypted comms for criminals
  • Act as lawful-interception systems or IMSI-catchers

Security Updates and Vulnerability News Round-Up

SIPVicious Scanning Threat on Grandstream H802 VoIP Adapter

A Reddit user reported encountering SIPVicious call attempts on their Grandstream H802 VoIP adapter. A blog post from the old SIPVicious blog about this is now hosted on our blog: “If SIPVicious gives you a ring…”.

Original content here.

Samsung IMS Network Packet Anomaly Investigation

This fascinating technical deep-dive from “Nick vs Networking” explores an unusual network behavior discovered during IMS call analysis. The investigation revealed that Samsung mobile phones were transmitting mysterious 14-byte GTP-U encapsulated data packets instead of the expected RTP traffic during voice calls. This type of detailed packet-level analysis showcases the complex troubleshooting required in modern telecommunications networks and highlights how even established devices can exhibit unexpected network behavior that challenges engineers’ understanding of protocol implementations.

Original content here.

Qualcomm UE security fixes affecting RTP

Unrelated to the above, Qualcomm’s September 2025 security bulletin addresses several critical vulnerabilities in User Equipment (UE) affecting VoIP/VoLTE and IMS media transmission over RTP. The most severe issue, CVE-2025-21483, presents a critical memory corruption vulnerability during NALU reassembly of video RTP packets, potentially enabling remote code execution through crafted network traffic. Three additional CVEs (CVE-2025-21484, CVE-2025-21487, CVE-2025-21488) address information disclosure vulnerabilities related to fragmented RTP packet decoding, payload length validation, and RTP header parsing when padding bits are set. All vulnerabilities involve buffer over-read conditions and were discovered through Qualcomm’s internal security research efforts, highlighting the ongoing security challenges in real-time media protocol implementations.

Original content here.

Chrome WebRTC Use-After-Free Vulnerability (CVE-2025-10501)

Google’s Chrome stable channel update addresses a use-after-free vulnerability in WebRTC functionality. This security flaw, designated as CVE-2025-10501, was discovered and reported by security researcher sherkito on August 23, 2025.

Original content here.

Thanks to Vulners 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

Subscribe to Updates

Stay updated with our latest security insights and updates.

We hate spam and are committed to protecting and respecting your privacy. You can unsubscribe from our communications at any time. By subscribing, you are agreeing to the Privacy Policy.