Welcome to the summer (on this part of the hemisphere) edition of your favorite VoIP and WebRTC security newsletter! Why not send this one to your ebook reader and take it with you to the beach?
In this edition, we cover:
- Editorial piece on what we’re thinking about the slew of security reports hitting open source RTC projects
- 0day Rubbish, real, reproduced and verified vulnerabilities without vendor fixes
- SBOM for Kamailio and lots of security updates in the short news section
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
The finding is (now) the easy part, the impact is the job
We have been collaborating with the coturn developers to work through the security reports landing on the project, and the exercise has made something very clear to me: the finding is the easy part, and working out the real impact is where the actual work is. Most of what we have been doing is reproducing reported issues against a lab environment, and, more importantly, figuring out how bad each one really is.
That last part is what everyone downstream acts on. When an admin reads an advisory, they are deciding one thing: do I need to upgrade now, or does this not affect me? Constant upgrading is not always feasible, so that decision leans entirely on the severity being honest. A “critical” that is really a “your admin panel would have to be exposed to the internet first” wastes a lot of people’s time. A “low” that is really exploitable in a default config gets people breached.
Our June coverage of the coturn advisory batch is a good example of the difference. The loopback bypass hits a default deployment, so it is the reason to upgrade. The admin-panel SQL injection and the CLI path traversal only matter if you have exposed interfaces that are off by default, in which case those bugs are the least of your problems. Same batch, three CVEs, very different real-world impact. Sorting that out is exactly the part a maintainer cannot outsource to whoever filed the report.
And they are getting a lot of reports. A growing share of them arrive with a scary CVSS number attached to a scenario that does not survive contact with the software, plus a wall of generated text that is far too long to be useful. To be clear, this is not an anti-AI rant. A lot of AI-assisted findings are real and worth the maintainer’s attention, especially from the more capable models. The problem is the ones where nobody reproduced anything before pasting the model’s first answer into an advisory template, and it often sounds legitimate. Sometimes it has reproduction logs, some of which might be valid, others hallucinated, and yet others reproduced using a harness rather than actual attacker-controlled network traffic. At the volume maintainers are now seeing, automation on the intake side is not optional, everyone is reaching for it, and it is still overwhelming. Jan Schaumann made the same point from the Linux kernel side after the kernel published 432 CVEs in about 32 hours, and he is honest that he does not know what to do about it either.
Assessing the impact has always been the most interesting job, now even more than ever. So here is where I land: reproduce before you rate, be honest about the impact, and respect that the maintainer on the other end has too many of these to get through. AI is a genuinely strong assistant for this work. It just still needs a lab and a skeptic.
What’s happening?
0day Rubbish: AI-discovered unauthenticated RCEs in Brekeke SIP Server and Cisco CUCM
0day Rubbish wouldn’t have been my first choice for naming an AI-driven vulnerability discovery service. They run a multi-LLM ensemble (Claude, GPT, DeepSeek and others) against targets and “aggressively disclose” the results with runnable PoCs on GitHub.
Four of their advisories land in RTC territory: three July ones against Brekeke SIP Server and an earlier six-stage chain against Cisco CUCM. We reproduced all three Brekeke findings in our own lab, so for once you can treat an AI-found, self-published RCE as confirmed rather than just claimed. The CUCM chain we did not test.
Brekeke SIP Server (v3.19.1.8p1). The three advisories share one root: an authentication fail-open in the product’s self-developed framework. ScopeBean.checkScope() admits any bean (a server-side Java object that handles a request) that never declared a scope, and the GateServlet bean parameter is attacker-controlled, so administrative handlers become reachable through /sip/gate with no session. That fail-open is the first advisory; the other two are the RCE sinks it exposes. We confirmed the chain on the exact evaluation WAR (build 593-4, dated 2026-06-24) with our own LLM-driven validation pipeline, the same one we use to verify vendor fixes and to find and report our own 0days in open-source projects:
- Zip Slip webshell: the
ProvisioningModelImportbean unzips an uploaded archive through a homegrownZip.extractAllwith no..filtering or canonical-path check. One unauthenticated POST writes a JSP seven directory levels up into the webroot, one GET triggers it, and you have RCE. We ran it end to end with an inert marker file and a JSP that only returns a fixed string, which Tomcat compiled and executed. - Nashorn eval: the
ProvisioningTestbean passes a user-controlledscriptparameter straight into a NashornScriptEngine.eval()with no sandbox, giving unrestricted access to Java classes and so toRuntime.exec(). It needs anetc/pv/temp/directory the default deployment lacks (on its own the anonymous request returns HTTP 500), but the Zip Slip primitive can create that directory unauthenticated, so the two chain together. We confirmed the Java access with a script that only reads a system property.
A few of the report’s specifics didn’t survive checking, though none of them undo the two RCEs. The self-scored 9.8s use CVSS v3.1; rescored in v4.0 from what we confirmed, the three findings land at 9.2 to 9.3, still critical. “RCE as the tomcat user” is deployment-specific: the stock Tomcat image we tested runs the app as root. And the headline “23 exposed beans” is unverified: the report’s own counts don’t add up (78 + 23 ≠ 95), and for several classes its PoC probes (sipadmin.web.Command, LicenseBean, UserEdit) just return 404 on this build.
Is any of this reachable in practice? Brekeke serves phone provisioning from /sip/pv/ on the same listener as the /sip/gate dispatcher, and the vendor supports provisioning from any source with HTTP auth optional, so an Internet-facing deployment is supported. The problem isn’t that provisioning is public; it’s that exposing /sip/pv/ to remote phones puts the fail-open /sip/gate, and the two RCE sinks behind it, on the same origin, unless a reverse proxy allows only /sip/pv/ and blocks /sip/gate and the Admintool.
Cisco CUCM. The earlier writeup (also self-scored 9.8) chains six stages from an unauthenticated blind SQL injection in /ssosp/user/whoami (Authorization header, DNS-exfiltrated) through XXE key extraction, credential decryption, an Apache Axis service deployment, a Freemarker template RCE, and finally root command execution (CUCM runs as root).
This feeds the overblown-advisories problem we cover separately this edition: self-published, self-scored 9.8s with no CVE and no vendor confirmation, where the only way to know what is real is to run them. 0day Rubbish practices aggressive full disclosure by design, dropping working RCE PoCs on GitHub the day they publish rather than coordinating with the vendor first (they “release unauthorized RCE vulnerabilities immediately upon discovery” to force global patching), so defenders (and attackers) get a public exploit before a patch exists. To their credit the writeups are unusually honest about the human effort: the CUCM one says every stage needed significant manual intervention, that automation produced “hundreds of false-positive DNS callbacks,” and that a “fully autonomous vulnerability finder remains science fiction.”
Don’t confuse 0day Rubbish’s CUCM chain with the separate, Cisco-confirmed WebDialer SSRF-to-root (CVE-2026-20230) that Cisco patched in June and that was exploited in the wild within a day. That one is CVE-tracked, disclosed by SSD Secure Disclosure; the 0day Rubbish findings carry no CVE and no vendor confirmation. We haven’t tested the CUCM chain and aren’t aware of anyone who has, so treat it as credible but unverified. The Brekeke three we did verify, though only on the evaluation build and with no vendor fix yet to diff against.
Building an operational SBOM for Kamailio
Olle E. Johansson has started building a software bill of materials (SBOM) for Kamailio, the open source SIP proxy written in C that just passed 25 years. His premise is a practical one: the SBOM tools he has tried over the years never produce anything operational for a mature C codebase, so he is doing it by hand with Claude Code, parsing makefiles and source to map the code and its modules.
The useful distinction he draws is between a source-code SBOM and a runtime one. Kamailio ships well over 100 modules, but any given deployment loads only a handful. The goal is to parse the config and the modules actually loaded in memory, then express that usage as PURLs or CPEs so future CVEs match the running instance rather than the whole project. That is the gap between “there is a CVE in Kamailio” and “there is a CVE in a module this server actually runs,” which is the whole point of an SBOM and the part most tooling skips.
It is early and framed as a work in progress, with a lively comment thread on the hard parts (parsing makefiles, separating internal from external dependencies). We have followed Olle’s SBOM work before: the 2023 Kamailio SBOM mailing-list thread on why C code makes this hard, next to lcamtuf’s skepticism about leaning on SBOMs for vulnerability response, and his 2024 talk on the EU Cyber Resilience Act and SBOMs.
ClueCon 2026: the security talks worth catching
ClueCon 2026 is happening on August 10-13 in Chicago. I’ve been last year (we presented on RTP and SRTP media security at ClueCon 2025) but sadly won’t make it this year. Having said that, it is definitely one of the better gatherings for the open-source VoIP and WebRTC crowd.
The schedule leans heavily into voice AI this year, but a few sessions have a real security angle:
- Daniel-Constantin Mierla on “Safe and secure communications with Kamailio” walks through the Kamailio components you’d use to run it as a security guard in front of a VoIP or telephony platform. He also has a lunch session on SIP registrar scalability and redundancy.
- Fred Posner with “What’s new with APIBAN” . APIBAN is the free service for blocking unwanted SIP and HTTP traffic, so an update is worth catching.
- Hector Zelaya on “eBPF makes Python a good language for a TURN server” runs packet handling in the kernel with eBPF instead of user space. TURN is close to home for us, and the kernel-boundary approach is interesting in its own right.
On the AI side, Kishor Patil’s “Securing agentic workflows at enterprise scale” covers trust boundaries between agents, secret sprawl and lateral movement. Also worth a glance for the infrastructure crowd: Liviu Chircu on OpenSIPS 4.0 with its redesigned TCP/TLS subsystem, and the Homer 11 sessions on VoIP monitoring.
FreePBX security advisories: seven fixes led by two unauthenticated criticals
FreePBX published a batch of seven security advisories this month. Two are critical and reachable without authentication; the other five are high severity but need an authenticated session, API access, or a crafted backup.
The two that matter for internet-facing systems:
- My personal favorite: Unauthenticated SQL injection in missedcall (GHSA-g27h-xf3q-h3rm, CVSS-B v4 9.3, “Amber” urgency, FreePBX 16 before 16.0.11 and 17 before 17.0.6). The module concatenates the inbound Caller ID Name into an INSERT without escaping, so a crafted SIP
Fromheader injects SQL and can take over an admin account. It is reachable by anyone who can place an inbound call to a monitored extension, and inbound CNAM is not length-restricted the way PSTN CNAM is, so systems accepting trunk or anonymous calls are most exposed. - Unauthenticated RCE in the UCP (GHSA-37j8-fhxx-9vhp, CVSS-B v4 9.3, “Red” urgency, FreePBX 17 before 17.0.9). The UCP Node server (ports 8001/8003) authenticates socket.io connections with
io.use(checkAuth), but a change in socket.io removed some of those protections, so unauthenticated clients can send crafted events that get relayed to the Asterisk Manager Interface and run arbitrary commands as theasteriskuser. Zero interaction, and exploitable on any internet-facing UCP without an adequate firewall.
The remaining five are all high severity and require authentication:
- Authenticated TTS AGI command injection through the TTS name (GHSA-hg3v-m857-mvw9).
- Authenticated command injection in the API
generatedocshost parameter (CVSS 8.6), where the GraphQL documentation generator builds a shell command from an unescaped host value and runs it as theasteriskuser (GHSA-79rg-3xp6-rqq6). - Authenticated Music module RCE via mpg123 and Asterisk call files (GHSA-p97w-rq48-p8q2).
- Authenticated Framework AUTHTYPE restorable from a crafted backup (GHSA-f6hc-rqxg-ch86).
- Authenticated arbitrary SSH key injection via the Backup module (GHSA-24w6-hpg3-rwfg).
If you’re using FreePBX, update the affected modules. For the UCP flaw specifically, enable the Responsive Firewall (which limits UCP to IPs that have a registered SIP endpoint), restrict inbound calls to trusted trunks, and put an SBC in front to sanitize the SIP From header.
Short news
Security Updates and Vulnerability News Round-Up
Chaos ransomware’s msaRAT hides C2 in WebRTC DataChannels
Cisco Talos detailed msaRAT, a Rust RAT that drives Chrome/Edge over the DevTools Protocol and opens a WebRTC PeerConnection so C2 egresses from the real browser process. Signaling goes through a Cloudflare Workers endpoint, then C2 flows over the DataChannel relayed through Twilio TURN to hide the operator’s IP, double-encrypted with DTLS plus ChaCha20-Poly1305. It continues the TURN/WebRTC-for-C2 theme (see the Ghost Calls technique we covered in August 2025).
Chrome patches WebRTC use-after-free and GetUserMedia flaw (July 2026)
Chrome’s July stable (150.0.7871.114/.115) fixed a use-after-free in WebRTC (CVE-2026-15121) and a GetUserMedia issue (CVE-2026-15119), both High, on top of more WebRTC heap-overflow and out-of-bounds fixes across the June Chrome 149/150 builds (including CVE-2026-11096). We covered the earlier round in June.
Firefox and Thunderbird WebRTC use-after-free fixes
Firefox 153 and ESR 140.13 fixed a High use-after-free in the WebRTC Audio/Video component (CVE-2026-16362, MFSA 2026-68 / -70). An earlier ESR 140.10.2 and Thunderbird update patched another High WebRTC issue (CVE-2026-8094); despite an inflated “9.8” in some trackers, Mozilla rates it High.
Apple 26.5.2 updates patch WebRTC memory bugs
iOS/iPadOS, macOS Tahoe and Safari 26.5.2 all list WebRTC-component fixes: an out-of-bounds access (CVE-2026-28979) plus stack-overflow and use-after-free Safari crashes (CVE-2026-43718, CVE-2026-43717). Apple gives no severity ratings and describes these as crashes, not confirmed RCE.
HP Poly Voice phones: SIP DoS and WebUI XSS/CSRF
Poly CCX, Trio and Edge E phones can be knocked offline by malformed data from a malicious SIP server (CVE-2026-2891). Separately, the phone WebUI has stored XSS via unsanitized config parameters plus CSRF session hijacking (CVE-2026-5922, CVE-2026-5923, advisory HPSBPY04108). Fix: firmware updates.
Juniper Junos SIP ALG DoS (CVE-2026-57026)
A malformed SIP INVITE crashes the flow daemon (flowd) on Junos MX with SPC3 and on SRX when SIP ALG is enabled, an unauthenticated total outage until it restarts (CVE-2026-57026). Fixed in the July 2026 Junos releases; workaround is to disable SIP ALG if unused.
Sangoma Switchvox SMB: unauthenticated SQL injection to RCE and three more bugs
Cameron Lischke of Security Risk Advisors disclosed four flaws in Sangoma Switchvox SMB. The critical one is an unauthenticated SQL injection to RCE in the /pa endpoint, which drops the PolycomIPPhone PhoneIP value straight into PostgreSQL queries (CVE-2026-9586, CVSS 9.3), alongside an unauthenticated reflected XSS (CVE-2026-9585) and authenticated local file inclusion and stored XSS (CVE-2026-9587, CVE-2026-9588). Affects 8.3 through 8.4.0.1; fixed in 8.4.0.2.
Zoom for Windows unauthenticated account takeover (CVE-2026-53412)
Zoom’s bulletin ZSB-26014 rates this improper-input-validation flaw CVSS 9.8: an unauthenticated network attacker can take over accounts on Zoom Workplace for Windows (before 7.0.0) and the VDI client. Found by Zoom’s own offensive security team, no in-the-wild exploitation reported; three lesser flaws (CVE-2026-53409 to -53411) were patched alongside.
Mitel MiCollab AWV command injection and OpenScape UC XSS
Mitel patched an unauthenticated command injection in the MiCollab Audio/Web/Video conferencing component (MISA-2026-0006, Critical), fixed in MiCollab 10.3.0.18 with backports to 10.2.1.205 and 9.8.3.203. A separate advisory covers an authenticated reflected XSS to command injection in OpenScape UC (MISA-2026-0007, High).
pjproject heap buffer overflow in AVI parser
pjproject’s AVI parser copies frame data without checking length against buffer capacity, so a crafted AVI triggers an out-of-bounds write (GHSA-6p2p-5wf8-h5hr). Affects all versions up to 2.17; matters for RTC apps that consume untrusted video.
PJSIP TLS hostname verification bypass via embedded NUL in SAN
With server verification enabled, PJSIP treats a certificate whose DNS SAN contains an embedded NUL (victim.example\0.attacker) as identifying victim.example, enabling MITM and interception of SIP REGISTER credentials (GHSA-382p-87mh-r3q8). The OpenSSL and GnuTLS backends are affected (mbedTLS is not); fixed on master (commit 43d3bd77). Credited to Bin Luo.
GStreamer DTLS stack buffer overflow via oversized certificate DN (CVE-2026-59692)
A certificate with an oversized Subject DN overflows a stack buffer in GStreamer’s openssl_verify_callback during the DTLS handshake, crashing the process (CVE-2026-59692). No fix at time of writing; mitigate by disabling DTLS or restricting endpoints to trusted peers.
coturn: TURN allocation hijack and pre-auth memory disclosure
coturn shipped two advisories. With --mobility (MICE) enabled, the session-resume path doesn’t bind the resuming identity to the victim’s allocation, so an attacker with valid credentials can hijack an active TURN allocation using only the victim’s 56-bit mobile ID and intercept relayed media (GHSA-69wx-x7x6-pjj8). Separately, a signed-to-unsigned bug in the --acme-redirect handler lets any unauthenticated client leak up to ~870 bytes of adjacent process heap, potentially TURN credentials or OAuth tokens, in the HTTP 301 Location header (CVE-2026-62959, GHSA-m23x-5qf5-988g, fixed in 4.15.0).
mediasoup: three advisories in RTP, SCTP and STUN handling
mediasoup fixed three issues in npm 3.23.0 and the matching Rust releases. Two are memory-safety bugs reachable over an established WebRTC session: an out-of-bounds write in UpdateDependencyDescriptor() RTP-extension parsing (GHSA-jhm4-v227-4375), and an integer overflow in SCTP ParseStrict() where a single malformed packet crashes the worker and takes down every call sharing it (GHSA-p9cq-fqxc-987w). The third is a Low-severity non-constant-time MAC comparison in STUN MESSAGE-INTEGRITY and SCTP cookie checks, a theoretical timing side-channel (GHSA-xvjj-6cm4-ppgq).
SIPSorcery malformed-UDP DoS on the RTP/ICE socket (CVE-2026-54632)
SIPSorcery 10.0.8 and earlier crash on a malformed UDP packet on the RTP/ICE socket (unchecked indexing of packet and STUN bytes), reachable before the DTLS handshake or STUN auth, so any active RTP or WebRTC session can be dropped (CVE-2026-54632, CVSS 7.5). Fixed in 10.0.9.
Erlang/OTP DTLS demux race condition DoS (CVE-2026-55950)
A pre-auth race in dtls_packet_demux.erl lets rapid ClientHello messages from one UDP source crash the shared demux process, killing all active DTLS connections on a listener with no handshake needed (CVE-2026-55950). Affects OTP 25.3 to 29.0.2; fixed in 29.0.3, 28.5.0.3 and 27.3.4.14.
Erlang/OTP TLS/DTLS 1.2 client cipher-suite validation bypass (CVE-2026-55953)
The Erlang/OTP TLS client doesn’t verify the ServerHello cipher suite was offered in ClientHello, so an on-path attacker can force an anonymous key exchange and bypass all certificate and hostname validation (CVE-2026-55953). Affects OTP 17.0 up to the fixes in 29.0.4, 28.5.0.4 and 27.3.4.15; TLS 1.3 is unaffected.
Yealink Android desk phones: admin access and APK injection (BSides Canberra)
An upcoming BSides Canberra 2026 talk, scheduled for September 25, will dissect Yealink Android desk phones, often paired with Microsoft Teams. The abstract promises admin access, loading custom APKs, and exploiting weak firmware decisions. Original RTC hardware research worth watching for once the slides or video are out.
Zenitel TCIV-3+ intercom vulns, found with LLM assistance
Claroty’s Team82 used Claude Opus 4.6 to reproduce and extend their manual research on Zenitel’s TCIV-3+ IP video intercom: five web-interface bugs (command injection, out-of-bounds write, XSS; CVE-2025-64126 to -64130) in a device used in high-security areas. The news is the method, the agent unpacked the firmware and found the bugs in under 10 minutes.
Caller ID Verification proof-of-concept on stock Asterisk
Shin Wang built a working Caller ID Verification prototype on unmodified Asterisk (config only), implementing the IETF draft draft-hao-civ-03 as a challenge-response alternative to STIR/SHAKEN against caller-ID spoofing. Two cloud servers show end-to-end “verified” status on a stock Zoiper softphone, at 986 ms latency.
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