Skip to main content
RTC Security Newsletter

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

Subscribe

June 2025: WebRTC security, privacy and Yealink provisioning vulnerabilities

Published on Jun 30, 2025

Welcome to the June edition of RTC Sec newsletter, your favorite source of VoIP and WebRTC security commentary.

In this edition, we cover:

  • Celebrating the OWASP ASVS v5 release with the WebRTC chapter
  • Yealink YMCS security problems have been published
  • More WebRTC security items, including STUN DDoS, WebRTC’s security/privacy reputation, and Meta abusing WebRTC to bypass privacy controls
  • Numerous vulnerabilities, mostly fixed, in Sangoma, Audiocodes, Qualcomm chipsets, Cisco, Mitel, and others
  • Plug for TADSummit Online and a LinkedIn article about overlooked UC security

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

ASVS 5 published, including a WebRTC chapter with 12 security requirements.

We have been anticipating the release of the OWASP Application Security Verification Standard v5 because it includes a new chapter dedicated to WebRTC security, which we contributed.

How do you use this? The ASVS is used to assess application security. For WebRTC platforms, it can evaluate the security levels of TURN, Signaling, and Media servers. Version 5.0 includes a dedicated chapter, V17, specifically addressing WebRTC security requirements for stakeholders who develop, host, or integrate WebRTC systems.

The WebRTC chapter (V17) includes specific sections for:

  • TURN Servers (V17.1) - Security requirements for relay services, focusing on secure address filtering and protection against resource exhaustion.
  • Media Servers (V17.2) - Requirements for components that handle and distribute media streams, preventing eavesdropping, tampering, and denial-of-service attacks.
  • Signaling Servers (V17.3) - Requirements for components that coordinate peer-to-peer communication, ensuring resilience against attacks that disrupt session establishment or control.

Each requirement is assigned an ASVS level (L1, L2, or L3), allowing organizations to select appropriate security depth based on risk analysis and application sensitivity. This structure enables organizations to verify their WebRTC components’ security posture against defined ASVS levels.

Download the entire document here.

What’s happening?

Earlier this June, the phone vendor Yealink issued the following advisories with security fixes:

A bit of an introduction: YMCS stands for Yealink Management Cloud Service, while RPS stands for Redirect and Provisioning Service. This feature is present on their phones and allows IT administrators and service providers to remotely provision, manage, and redirect Yealink devices. Thus, a significant compromise of the RPS could lead to a compromise of Yealink devices. On the other hand, the YMCS OpenAPI interface is an API that allows third-party systems to interact programmatically with the YMCS platform.

Each vulnerability is rated Medium or Low severity under CVSS 3.1. Plus, Yealink has already applied the security fixes, so there is also nothing for the administrator to do. The security advisories lack detailed information. So, there’s nothing to worry about, right?

Actually, a few days after the Yealink publications, the original security researchers, Jeroen Hermans and Stefan Gloor, published their advisory on the Full Disclosure list. In this detailed post, they outline how the vulnerabilities they disclosed to Yealink are critical in nature and have not been properly addressed. So if we ignore what Yealink published in terms of advisories, which is confusing, and instead focus on what Jeroen and Stefan published, we have the following vulnerabilities:

  • Unauthorised Access to RPS Data (CA Private Key Leak):
    • The researchers were able to access the private key of the “Yealink Equipment Issuing CA”. This enabled them to issue rogue client certificates to contact Yealink’s Redirection and Provisioning Service (RPS).
    • From the RPS server, they obtained highly confidential data, including provisioning URLs, provisioning credentials, and provisioning certificates.
    • With these credentials, it becomes “trivial” to contact the customer’s provisioning service and obtain significant Personally Identifiable Information (PII) such as SIP usernames/passwords, LDAP credentials, and address books.
    • Yealink claimed this issue was fixed and only relevant for End-of-Life (EOL) devices. However, the researchers found this to be incorrect, as they successfully tested the vulnerability on a non-EOL T44U device and confirmed it was still present.
    • Yealink classified this as “medium severity”. However, the researchers consider leaking address books and SIP credentials a major issue for customers, particularly concerning GDPR in the EU and ISO27001 outside the EU.
    • The researchers highlighted that Yealink made a “dumbest mistake from an IT security perspective” by supplying a copy of the CA’s private key with every VoIP phone. This effectively turns every one of the thousands of Yealink IP phones into an “almighty CA” within the Yealink universe.
    • An attacker with this private key can issue any certificate for any Yealink device ID, impersonate any Yealink phone to the RPS, and thus gain access to any access data of all users on all telephony servers worldwide.
    • While the private key is encrypted, the key to decrypt the software (and thus the private key) can be read with some hardware knowledge. The researchers state that this fundamental error is impossible to correct by a software update due to its inherent design principle. They also mentioned that encrypting the phone’s software is not protection but a sign the manufacturer is hiding something from the legitimate owner.
  • Firmware Encryption (AES Key Obtained):
    • The researchers obtained the AES key used to decrypt the firmware.
    • Yealink classified this internally as “high severity” but ultimately did not publicly disclose this vulnerability.
    • The researchers could not determine if new firmware using a different AES key leads to improved security and have not fully analysed it.
  • Missing Input Validation RPS:
    • The RPS service did not properly validate uploaded certificate files, only checking if they were smaller than 5 MB and had a “.pem” extension.
    • The researchers were able to upload random data, which was then returned when contacting the RPS service. They stated that, to their knowledge, this specific failed input validation was not directly exploitable.
    • Yealink’s advisory confirms that the “YMCS RPS Certificate Content Validation Bypass Vulnerability” was patched on 26 May 2025 by implementing content validation.
  • RPS Serial Number Enumeration / Missing Rate Limiting:
    • The researchers were able to enumerate the last 5 digits of the Yealink serial number, which served as a “2FA” mechanism since a 2020 RPS vulnerability.
    • They observed no rate limiting or brute-force protection in the RPS, allowing them to test all 20,000 possibilities without hindrance. They successfully guessed a serial number in approximately 18,000 attempts.
    • Yealink’s advisory for “YMCS RPS API Rate Limiting Missing Vulnerability” confirms the lack of rate limiting and states it was patched on 26 May 2025 by implementing controls for sensitive APIs.
    • Regarding the “YMCS RPS Device SN Last-Five-Digit Enumeration Vulnerability”, Yealink states it was patched on 4 June 2025 with enhanced SN verification, including IP blocking for repeated failed attempts. However, the researchers remain skeptical, suggesting simple rate limiting or IP blocking might not deter dedicated attackers who could use thousands of IP addresses from cloud providers.
  • RPS MAC Address Enumeration:
    • The researchers could enumerate MAC addresses registered on the RPS platform globally, not just within their own organisation. This capability makes finding vulnerable device configurations faster.
    • They observed no rate limiting or brute-force protection in the RPS API for this.
  • RPS Authentication Bypass:
    • When their RPS account was banned, this mechanism only applied to the web interface, while the RPS API remained accessible for blocked entities.

The researchers also argue that the compounded severity of these vulnerabilities is much higher than their individual assessments, stating that layer after layer of security has been peeled away. They believe that combined, these flaws allow the retrieval of personal data from the internet and manipulation of devices, corresponding to a very high severity level, contrary to Yealink’s often “medium” or “low” severity classifications and CVSS scores. They conclude it is unlikely that Yealink has fully and sustainably fixed these fundamental security flaws in such a short time.

For German speakers, there’s also an article about this on dnip’s blog.

TURN Server Reflection Attacks Trigger Cloud Provider Blocking

Gustavo Garcia, a core coturn developer, wrote about TURN servers being exploited in reflection and amplification DoS attacks. TURN servers have been abused for years to reflect traffic toward victims in DDoS attacks, with the first in-the-wild reports appearing in April 2021 on the XMPP operators mailing list. This latest case involved OVH, Hetzner, and other cloud providers blocking abused TURN servers.

If you run a TURN server, follow these best practices:

  • Move TURN off default ports.
  • Strip or shorten optional STUN/TURN attributes (SOFTWARE, error-phrase, long NONCE/REALM).
  • Filter UDP fragments or unusually long STUN packets.
  • Block traffic from ports commonly targeted in DDoS attacks.
  • Monitor 401 errors and block excessive traffic by IP.
  • Upgrade coturn servers to version 4.7.0, which hardens default behavior.

FFmpeg adds WebRTC support: Security concerns emerge

Sean Dubois posted on Hacker News:

I am so incredibly excited for WebRTC broadcasting. I wrote up some reasons in the Broadcast Box and the OBS PR Now that GStreamer, OBS and FFmpeg all have WHIP support we finally have a ubiquitous protocol for video broadcasting for all platforms (Mobile, Web, Embedded, Broadcasting Software etc…)

I have been working on Open Source + WebRTC Broadcasting for years now. This is a huge milestone :)

It is indeed great to see this support. The forum post then shifted to security concerns around WebRTC and how it adds complexity, which undermines security. The conversation reveals WebRTC’s poor reputation regarding privacy and security.

For what it’s worth, we think WebRTC does have a significant attack surface, which makes it interesting to us. However, it remains a great project and an excellent set of protocols and standards. It’s an amazing effort that sets the bar much higher than previous RTC attempts.

WebRTC Privacy Exploit: Meta Android Tracking

Speaking of WebRTC security and privacy, this came up on our news feeds a couple of times in the past month. Here’s what captured my attention:

  • In early June 2025, an academic team from IMDEA Networks, Radboud University, and KU Leuven published a detailed report showing that Meta’s mobile apps (Facebook and Instagram) were opening hidden listeners on Android’s loopback interface (127.0.0.1) on UDP ports 12580–12585. When a user visited a site with the Meta (Facebook) Pixel, the pixel JavaScript would use a WebRTC/STUN SDP munging technique to shove the site’s first-party _fbp cookie into the SDP ice-ufrag field of a STUN binding request, which the native app would receive and then associate with the logged-in user’s identity and Android Advertising ID (localmess.github.io, theregister.com).

  • According to Meta’s own statement to The Register, “Upon becoming aware of the concerns, we decided to pause the feature while we work with Google to resolve the issue,” and researchers immediately observed the Pixel script stop sending data to localhost, and the offending code was largely removed (theregister.com).

  • This cross-context tracking capability was first deployed by Meta around September 2024, exploiting Android’s unmediated localhost access to bypass Incognito Mode, cookie-clearing, and Play Store policies against covert data collection (bgr.com).

  • The same disclosure revealed that Yandex’s Android apps listened on fixed local ports for data from Yandex Metrica scripts embedded on millions of websites. These scripts transmitted browsing cookies and metadata via the loopback interface to the native app, where they were combined with persistent identifiers to de-anonymize web sessions. Unlike Meta, Yandex used standard TCP/HTTP connections rather than WebRTC for this process.

Broader response

  • Google and Mozilla both confirmed they are investigating whether these behaviors violate their platform policies, and Chrome is being patched to block unmediated loopback access by browser engines (bgr.com).

  • This incident has prompted calls for platform-level mitigations - sandboxing loopback sockets, mDNS obfuscation, or blocking WebRTC-based STUN to localhost - to prevent similar covert tracking in the future.

In sum, Meta’s and Yandex’s mobile apps exploited Android’s design to bridge web cookies to persistent app IDs via localhost, enabling surreptitious cross-context tracking. Both have since removed the offending functionality in the wake of the June 2025 disclosure.

Overflow attacks in Telecommunications hardware - affecting Sangoma and AudioCodes

Students from San Jose State University published a paper and security advisories for security flaws affecting Sangoma IMG2020 Media Gateway as well as Audiocodes Mediapack ATAs. In each case, the unchecked buffer overflow can be weaponized for unauthenticated, remote code execution and data exfiltration. The Github repository also includes payloads to reproduce the vulnerabilities and full technical details. The security issues are tracked as CVE-2025-32105 for Sangoma IMG2020 and CVE-2025-32106 for Audiocodes Mediapack.

Congratulations to Austin Erwin-Martinetti, Amith Kamath, and Belman from the Computer Science Department, College of Science, San Jose State University.

Qualcomm fixed various issues affecting VoLTE/VoWiFi IMS, exploitable through RTP and RTCP

Qualcomm issued a bulletin for their June security fixes, which included security vulnerabilities related to decoding or processing RTP and RTCP. These advisories represent high-severity buffer over-read vulnerabilities in Qualcomm’s data network stack that could allow remote attackers to access sensitive information during VoIP communications, including VoLTE/VoWiFi calls, across a wide range of Snapdragon chipsets. Links to the advisories of interest:

No actual technical details seem to have been published at the time of writing this newsletter.

More security problems for Mitel

Mitel has been struggling with cybersecurity issues in their equipment. A new vulnerability, CVE-2025-52913, affects “MiCollab - NuPoint Unified Messaging” and has been fixed according to Mitel’s security advisories site. This vulnerability bypasses a previously disclosed issue (CVE-2024-41713) that we covered in January, December and October due to active exploitation in the wild. The advisory thanks Dahmani Toumi for reporting this to Mitel.

Additionally, Mitel’s 6800/6900/6900w series SIP phones and the 6970 model had an unauthenticated command injection vulnerability leading to remote code execution, which the vendor has now fixed. The advisory credits Marc Bollhalder of InfoGuard Labs for reporting the issue.

The Forgotten Attack Surface: Why UC is a major cybersecurity concern

Jaron Davis wrote about the large attack surface that is Unified Communications, which is often simply ignored from a risk assessment perspective. We also find that Unified Communications (VoIP, video conferencing, messaging, paging, etc.) often aren’t treated as part of the cybersecurity domain. In fact, in many penetration tests, security audits, and similar exercises, these systems are marked as “out of scope”. The thing is, no attacker ever cares about your scope; as long as it is a weak link, it will be abused.

This article hit a nerve when discussing legacy protocols, toll fraud, the lack of network-level encryption, and weak passwords on critical communications equipment.

From the article, here’s why UC gets left behind:

  1. Out of sight, out of mind: Without visible inbox or file share components, people assume UC systems can’t be hacked.
  2. Fear of breaking legacy systems: Teams hesitate to update or reconfigure functioning phone systems.
  3. Unclear ownership: UC falls between networking, infrastructure, and security teams, leaving no clear owner.
  4. Perceived complexity: InfoSec practitioners are less familiar with SIP/RTP protocols than HTTP/SMTP or endpoints. linkedin.com

These are familiar challenges we can relate to.

TADSummit Online: focus on Telecom Security

Alan Quayle’s TADSummit Online increasingly focuses on cybersecurity and telecom security, covering RCS, identity, security incidents, and 5G.

Recent sessions on these topics include:

Security Updates and Vulnerability News Round-Up

CVE-2025-20278: Cisco UC CLI Root Command Injection Vulnerability

This vulnerability affects multiple Cisco Unified Communications products, enabling an authenticated, local attacker with administrator credentials to execute arbitrary commands on the device’s OS as the root user via the CLI. The flaw arises from improper validation of user-supplied command arguments. Cisco has released software updates to fix the issue. No workarounds are available.

Original content here.

CVE-2025-20275: Cisco CCX Editor RCE via Malicious .aef File

This vulnerability exists in the Cisco Unified CCX Editor and allows unauthenticated attackers to execute arbitrary code if they can convince a local user to open a malformed .aef file. The root cause is insecure deserialization of Java objects, leading to code execution with the user’s privileges. Multiple versions of Unified CCX are affected.

Original content here.

Cisco Unified CCX Stored XSS Vulnerability (CVE-2025-20279)

A stored cross-site scripting (XSS) vulnerability in the web-based management interface of Cisco Unified CCX allows an authenticated, remote attacker to inject malicious scripts into the system. Exploitation requires administrative credentials and results from improper input sanitization.

Original content here.

Cisco Unified CCX RCE Vulnerability via Java Deserialization (CVE-2025-20276)

This vulnerability enables remote code execution by authenticated attackers through insecure Java object deserialization in Cisco Unified CCX’s web interface. Exploitation could lead to code execution as a low-privileged user, with the possibility of privilege escalation.

Original content here.

Cisco Unified CCX Path Traversal RCE Vulnerability (CVE-2025-20277)

Cisco Unified CCX suffers from a path traversal flaw that may allow authenticated, local attackers to push crafted web requests and follow up via SSH, leading to code execution on the system with low-level privileges. It stems from improper enforcement of file path restrictions.

Original content here.

Cloudflare open-sources Orange Meets with End-to-End encryption

Cloudflare has added end-to-end encryption (E2EE) to its Orange Meets video conferencing tool and open-sourced the project. Using the IETF’s Messaging Layer Security (MLS) protocol, Orange Meets achieves forward secrecy and client-side data protection without server access. It’s designed more as a technical showcase for developers and researchers than a mature consumer product.

Original content here.

Fortinet Patches CVE-2025-32756 Zero-Day RCE Flaw Exploited in FortiVoice Systems

Fortinet addressed a critical stack-based buffer overflow vulnerability affecting FortiVoice and other products. Tracked as CVE-2025-32756 with a CVSS score of 9.6, the flaw allows remote code execution via crafted HTTP requests. It has already been exploited in the wild. Patches are available, and users are urged to upgrade or disable the HTTP(S) management interface.

Original content here.

CVE-2025-49140: Pion Interceptor RTP Padding DoS Vulnerability

A denial-of-service vulnerability was found in versions v0.1.36 to v0.1.38 of Pion Interceptor. Improper validation of RTP padding could cause remote crashes in SFU implementations using Pion. Patched in v0.1.39, users should upgrade or implement workarounds to reject malformed packets with invalid padding lengths.

Original content here.

Grandstream GSD3710 Firmware - Stack Overflow Vulnerability

A remote stack-based buffer overflow vulnerability in Grandstream GSD3710 firmware version 1.0.11.13 and lower allows attackers to execute arbitrary code using crafted SSH payloads after authentication. The proof-of-concept leverages a vulnerable command within the firmware using pwntools.

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.