RTC Security Newsletter

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

February 2026: TURN security series, libvpx VP9 overflow, Grandstream RCE, coturn fixes

Published on Feb 26, 2026

This month we published our three-part TURN server security blog series, and there’s plenty of vulnerability news to go with it. A libvpx VP9 encoder heap overflow hit Chrome and Firefox, Rapid7 dropped a full chain on Grandstream GXP1600 phones including SIP call interception, and coturn 4.9.0 patches an IPv4-mapped IPv6 ACL bypass that’s eerily similar to the one we found back in 2020.

In this edition, we cover:

TURN server security blog series: our three-part guide on threats, best practices, and coturn configuration
Coturn 4.9.0 security fixes: IPv4-mapped IPv6 ACL bypass, buffer overflows, and a reversed password check that went unnoticed for 7 years
AISLE Research finding RTC vulnerabilities: Firefox WebRTC use-after-free, heap overflow, and OpenSIPS SQL injection
APIBAN 2025 year in review: VoIP attack trends and new nftables tooling
libvpx VP9 encoder heap overflow: same bug, two CVEs across Chrome and Firefox
Grandstream GXP1600 unauthenticated RCE: stack overflow to SIP call interception
Dutch police using vulnerable Yealink phones: end-of-life devices in sensitive interrogation environments
Shadowserver tracking compromised FreePBX instances: now around 900 systems flagged
Asterisk security releases: privilege escalation, XSS, and XXE fixes
Short news: PJSIP, Pion DTLS, Cisco UC, BigBlueButton, FreePBX, Zoom plugin, Microsoft Teams, and more

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

TURN server security: new blog post series from Enable Security

It has been a long time coming but this month we finally published a three-part blog series on TURN server security. This builds on the presentation “TURNed inside out” that we delivered at RTC.ON 2025 in Kraków (covered in the September 2025 newsletter), now expanded into detailed written guides.

The first post, TURN security threats: a hacker’s view, covers the three main threat categories we see during pentests: relay abuse (using TURN as a proxy to reach internal services), denial of service (including reflection/amplification attacks), and software vulnerabilities in implementations like coturn. It includes real-world examples from our work, including the Slack TURN server compromise that gave access to internal AWS infrastructure.

The second post, TURN server security best practices, is an implementation-agnostic reference covering network isolation, IP range blocking, protocol hardening, rate limiting, and credential protection. It includes a 10-point security checklist and deployment patterns for SFU-based, P2P, and enterprise architectures. The opening advice: “the best TURN server to secure is the one you don’t run.”

The third post, Securing coturn: configuration guide, is a practical guide with copy-paste configuration blocks for coturn specifically. It provides three complete configuration templates (minimal, recommended, and high-security) and covers version-specific changes from coturn 4.5.2 through the recent 4.9.0 release. It also documents dangerous options like no-auth and allow-loopback-peers that should never be used in production.

I also joined Tsahi Levent-Levi and Hector Zelaya on a WebRTC Live panel titled “Everything You Need to Know About TURN Servers,” covering deployment options and security best practices. You can watch the recording here.

What’s happening?

Coturn 4.9.0 fixes IPv4-mapped IPv6 ACL bypass and reversed password check

Coturn 4.9.0 has been released with a fix for CVE-2026-27624 (CVSS 7.2), an access control bypass that allows attackers to circumvent denied-peer-ip rules using IPv4-mapped IPv6 addresses (e.g. ::ffff:127.0.0.1). In affected versions, three functions in ns_turn_ioaddr.c (ioa_addr_is_loopback(), ioa_addr_is_zero(), and addr_less_eq()) did not check for IN6_IS_ADDR_V4MAPPED when processing peer addresses. So CreatePermission or ChannelBind requests with v4-mapped peer addresses bypass rules that would normally block loopback, link-local, and RFC1918 ranges.

This one feels familiar. It’s very similar to CVE-2020-26262, which we discovered back in 2020 and wrote about on our blog. That vulnerability also bypassed coturn’s default access control using alternative address representations (0.0.0.0 and IPv6 loopback). The new CVE targets denied-peer-ip configuration rather than the default loopback protection, but the root cause is the same: incomplete address normalization. We also covered this class of issue in our recent TURN security threats blog post.

Beyond the ACL bypass, the 4.9.0 release addresses several buffer overflow and string-handling vulnerabilities identified and fixed by Pavel Punsky (coturn maintainer). The decrypt_aes_128() function in mainrelay.c used strcat() to append decryption output to a fixed 1024-byte stack buffer without null-terminating first (#1799). A similar pattern existed in the MySQL database driver’s decrypt path (#1801). The HTTP server’s write_http_echo() had an unbounded strcpy() into a network buffer with no capacity check (#1800), and stun_method_str() in ns_turn_msg.c also used strcpy() with no size validation on fixed 32-byte buffers (#1798). Multiple strncpy() calls in the MongoDB and other database drivers were missing null termination, which could leave buffers unterminated when the source string exceeded the destination size (#1797, #1804).

The release also fixes a reversed password check in the web admin interface. The bug was a single negation operator: the login handler used if (!check_password_equal(...)) instead of if (check_password_equal(...)), meaning wrong passwords were accepted and correct passwords were rejected. Yes, you read that right. The first bug report about not being able to log in to the web admin was filed on 11 March 2019, with another in 2023, and the logic was fixed in PR #1802 on 13 February 2026. That’s roughly 7 years of the web admin accepting any password except the right one. The fact that nobody caught this sooner probably says a lot about how many people actually use coturn’s web admin interface. At this point, maybe it’s time to just remove it entirely rather than keep maintaining a feature that apparently nobody is testing.

The deprecated OpenSSL AES and CRYPTO functions have been migrated to the EVP API.

If you can’t upgrade right away, the advisory suggests adding denied-peer-ip=::ffff:0.0.0.0-::ffff:255.255.255.255 as a workaround for the ACL bypass. We also covered coturn’s weak RNG issue (CVE-2025-69217) in our January 2026 newsletter.

AISLE Research finding RTC vulnerabilities in Firefox WebRTC and OpenSIPS

AISLE, an AI-native cybersecurity startup that launched publicly in October 2025, has been racking up RTC-related vulnerability discoveries. Their researchers have reported three vulnerabilities affecting Firefox WebRTC and OpenSIPS in the past few months.

The first is CVE-2025-14321, which Mozilla tracks as a use-after-free in the WebRTC: Signaling component and which we briefly mentioned in the December 2025 newsletter when no details were public. Joshua Rogers from AISLE has since published a detailed writeup explaining the root cause in Encoded Transforms handling: the RTCEncodedFrameBase class exposes native frame storage as a JavaScript ArrayBuffer using JS::NewArrayBufferWithUserOwnedContents(), but when the underlying native memory is freed, the JavaScript buffer is not detached. This gives an attacker both read and write primitives on freed memory through standard WebRTC APIs, which could plausibly enable memory corruption and code execution with additional exploitation work. Igor Morgenstern reported the vulnerability on October 6, 2025, and it was fixed in Firefox 146 / ESR 140.6 (shipped December 9, 2025). A third-party proof of concept by h3raklez demonstrates the read/write primitives on Firefox 145.0.1.

The second Firefox finding is a boundary condition issue in the WebRTC Audio/Video component (CVE-2026-2757, CVSS 3.1: 9.8 in NVD), also reported by Igor Morgenstern. Mozilla’s advisory doesn’t give much detail beyond “incorrect boundary conditions,” though AISLE published a writeup on the heap overflow. Fixed in Firefox 148 / ESR 115.33 / ESR 140.8, published February 24, 2026.

On the SIP side, Pavel Kohout from AISLE found an SQL injection in the OpenSIPS auth_jwt module (CVE-2026-25554, CVSS v4: 8.3). The jwt_db_authorize() function extracts the tag claim from a JWT and interpolates it directly into an SQL query without escaping, and it does this before verifying the JWT signature. So an attacker can craft a JWT with an SQL injection payload in the tag claim (e.g., ' UNION SELECT 'admin','attacker_secret' --), inject their own secret into the query result, then sign the token with that known secret to bypass authentication entirely. The fix adds escape_common() to sanitize the tag value. Affects OpenSIPS 3.1 through 3.6.3, fixed in 3.6.4.

AISLE isn’t specifically focused on RTC. These are just a few of the vulnerabilities their autonomous analyzer has been finding across major open-source projects including OpenSSL, curl, Samba, Chrome, and NASA CryptoLib. The WebRTC and OpenSIPS findings are a small part of a much larger output.

APIBAN 2025 year in review

APIBAN has released its 2025 year in review, documenting another year of VoIP attack trends. The free threat intelligence service, maintained by Fred Posner, provides blocklists for SIP and HTTP traffic targeting VoIP infrastructure.

2025 statistics:

5,175 new users signed up to use the service
16,063 new SIP IPs identified
111,457 new HTTP IPs identified
83,466 SIP IPs blocked in total

The HTTP blocking numbers are notable, nearly 7x the SIP additions. APIBAN has been collecting HTTP honeypot data since late 2023 and the numbers reflect the sheer volume of HTTP scanning happening across the internet.

The top offending networks are dominated by major cloud providers. For SIP traffic, Palo Alto Networks ranges led with 484 malicious IPs, followed by Google Cloud and Microsoft. The Palo Alto Networks presence is curious and likely due to their Cortex Xpanse service, which scans the entire IPv4 space to map attack surfaces for their customers. Even so, blocking this makes sense for APIBAN’s purpose: filtering out all SIP traffic that isn’t legitimate calls or registrations. For HTTP, Microsoft’s 20.0.0.0/8 topped the list with 1,229 bad IPs, followed by Amazon’s 18.0.0.0/8 with 1,163. Cloud infrastructure features prominently here, whether it is being used by attackers directly or through compromised instances.

New tooling:

The project released an nftables client for integrating APIBAN data directly into nftables, which offers better performance for large datasets compared to iptables. A new FLUSHAFTER field lets users customize block duration beyond the standard seven-day retention window.

libvpx VP9 encoder heap overflow affects Chrome and Firefox WebRTC video

Two CVEs were assigned in February for the same heap buffer overflow in libvpx’s VP9 encoder: CVE-2026-1861 patched in Chrome 144.0.7559.132 (Linux) and 144.0.7559.132/.133 (Windows/macOS) on February 3, and CVE-2026-2447 patched in Firefox 147.0.4 on February 16. Google assigned CVE-2026-1861 and Mozilla assigned CVE-2026-2447. Mozilla downstream trackers link CVE-2026-2447 to the same upstream libvpx fix used for Chrome. Both CVEs have a CVSS 3.1 score of 8.8 (High).

This is not just another browser media bug. The interesting part is that it’s in the VP9 encoder, not the decoder. The vulnerability sits in the write_superframe_index() function in vp9/vp9_cx_iface.c, which writes the VP9 superframe container index. The root cause is an off-by-one error in a buffer capacity check (using < instead of <=) combined with a flawed assumption that pending data always starts at the beginning of the output buffer. When these conditions align, a 1-byte heap buffer overflow write occurs.

The bug was caught by OSS-Fuzz via AFL fuzzing against the vpx_enc_fuzzer_vp9 target. OSS-Fuzz shows a regression range between January 12 and January 13, 2026 for the fuzzing job, but the upstream libvpx fix notes that the underlying bug was introduced much earlier when write_superframe_index() was added in March 2013 (CL 44659, CL 45268). Wan-Teh Chang at Google committed the fix on January 22, 2026. The Firefox fix was reported by security researcher jayjayjazz, and the Mozilla patch (ef5b202) was authored by Chun-Min Chang.

For WebRTC, the encoder-side location matters. Browsers use libvpx’s VP9 encoder for outgoing video streams, particularly on Linux where platform hardware encoders may not be available. The superframe index is used in VP9 scalable video coding (SVC) configurations. In theory, an attacker joining a WebRTC call could try to influence codec settings so that the victim browser encodes VP9 in a way that reaches this path. The exact remote trigger conditions in browser call flows are not publicly documented. OSS-Fuzz classified the crash as a heap-buffer-overflow write of size 1, which is often harder to exploit than larger overflows. As of February 26, 2026, there are no public reports of in-the-wild exploitation.

We’ve covered libvpx vulnerabilities before. In October 2023, we reported on CVE-2023-5217, a libvpx heap overflow that was actively exploited by a commercial surveillance vendor. And in May 2025, we covered a double-free in vpx_codec_enc_init_multi fixed in Firefox ESR 115.24. This latest bug continues the pattern of VP9 encoder code being a recurring source of memory safety issues in libvpx.

Beyond Chrome and Firefox, Mozilla’s advisories include Thunderbird. Tor Browser and Mullvad Browser shipped February 2026 updates tied to Firefox ESR 140.7.1, which includes the fix for CVE-2026-2447. Microsoft lists CVE-2026-1861 for Edge with a fix in Edge 144.0.3719.115 (Chromium 144.0.7559.132/.133). Debian and Ubuntu also published libvpx fixes for CVE-2026-2447. As of February 26, 2026, Arch Linux’s libvpx security page shows no tracked issue for this CVE. VP8 is not affected since the superframe index is specific to VP9.

Grandstream GXP1600 unauthenticated RCE enables call interception

Rapid7 researcher Stephen Fewer published a detailed writeup of CVE-2026-2329 (CVSS v4.0 9.3), a stack-based buffer overflow in Grandstream GXP1600 series VoIP phones. The vulnerability is in the /cgi-bin/api.values.get web API endpoint, which processes a colon-delimited request parameter without checking buffer boundaries. Unauthenticated, remote, root. All six models in the series are affected (GXP1610, GXP1615, GXP1620, GXP1625, GXP1628, GXP1630) on firmware versions before 1.0.7.81 (that is, up to 1.0.7.80).

The gs_web binary has no stack canary and is non-PIE, so ASLR does not randomize the main binary’s code segment, making exploitation easier even though NX is enabled. Rapid7 developed Metasploit modules for RCE, credential extraction (including HTTP, SIP, and TR-069 credentials), and SIP proxy reconfiguration.

That last one is what caught our attention. In a companion blog post, Douglas McKee describes how an attacker can reconfigure SIP settings to redirect calls through attacker-controlled infrastructure for silent call interception. The phone keeps working normally, so the user has no idea their calls are being relayed. From the perspective of a pentester, this is a textbook example of how a buffer overflow in a VoIP phone can escalate to full call interception.

Grandstream indicated patch availability in firmware version 1.0.7.81 on February 2, 2026, and reaffirmed the fix on February 3. The disclosure timeline was reasonable: initial vendor contact on January 6, technical details shared on January 22, patch confirmation in early February, and public disclosure on February 18.

Grandstream keeps showing up in RTCSec. We covered the GDMS compromise in December 2024, a GSD3710 stack overflow in June 2025, GXP2135 command injection in July 2024, and various other Grandstream vulnerabilities in August 2025.

Dutch police using vulnerable end-of-life Yealink phones during interrogations

Jeroen Hermans from CloudAware published a blog post about the Dutch National Police using end-of-life Yealink T27 phones with EXP20 expansion modules in their AVIM department (Aliens Police, Identification and Human Trafficking). Yealink’s own product pages show both the SIP-T27G and EXP20 were discontinued on 2021-09-30. These are the same Yealink devices affected by the RPS vulnerabilities that Hermans and Stefan Gloor disclosed last year, which we covered extensively in June, August and January 2026.

What makes this case particularly interesting is the deployment setup reported by Hermans: PCs are daisy-chained through the phones, so traffic passes through those devices. The June 2025 disclosure also states the researchers obtained the AES key used to decrypt Yealink firmware, which raises firmware-integrity concerns. Put together, this creates a plausible high-impact attack path in sensitive environments.

The underlying RPS issue (CVE-2025-68644) has a long timeline: researchers publicly disclosed related findings on 2025-06-21, Yealink says the cloud-side fix was deployed on 2025-06-27, Yealink’s bulletin is dated 2025-11-27, and the CVE record publication date is 2025-12-21. Hermans argues for replacing the aging infrastructure rather than accepting residual risk, especially in relation to BIO/ISO 27001-style risk management expectations. I think many phone provisioning systems in sensitive environments deserve this kind of scrutiny.

Shadowserver tracking around 900 compromised FreePBX instances

The Shadowserver Foundation is tracking compromised FreePBX instances using a freepbx-compromised tag based on remote webshell fingerprinting. Shadowserver initially reported at least 386 compromised systems in August 2025, and dashboard data now shows around 900. The compromises are linked to CVE-2025-57819, the unauthenticated RCE in the Endpoint Manager module that we first covered in the August 2025 newsletter. We also covered the EncystPHP webshell campaign affecting FreePBX in our January 2026 newsletter, which attributed the attacks to the INJ3CTOR3 threat group.

If you’re running FreePBX, you can subscribe to Shadowserver’s free daily reports to check if your IPs are flagged as compromised.

Asterisk security releases fix privilege escalation, XSS and XXE

The Asterisk project released versions 23.2.2, 22.8.2, 21.12.1, 20.18.2 and 20.7-cert9 to fix four low severity security issues, all reported by ThatTotallyRealMyth:

Two local privilege escalation issues in ast_coredumper (CVE-2026-23740, CVE-2026-23741), similar to the safe_asterisk LPE we covered in August 2025
A reflected XSS in the /httpstatus endpoint (CVE-2026-23738)
A proactive XXE fix in ast_xml_open() (CVE-2026-23739)

ThatTotallyRealMyth is building quite the Asterisk CVE collection at this point, even if mostly low severity ones.

Security updates and vulnerability news round-up

PJNATH ICE buffer overflow with long username credentials (CVE-2026-25994)

A buffer overflow in PJNATH ICE session credential handling (CVE-2026-25994, High) can be triggered by excessively long usernames, leading to unexpected termination or memory corruption. Affects PJPROJECT 2.16 and earlier, fixed in 2.17. We previously covered PJSIP vulnerabilities in November 2025.