Our news
Introducing
DVRTC: a vulnerable lab for RTC security
We’ve been wanting to build this for a long time. Web application
security has DVWA and WebGoat for hands-on practice. VoIP and WebRTC
security? Not much exists out there. So we built DVRTC
(Damn Vulnerable Real-Time Communications), an intentionally vulnerable
lab environment for learning RTC security.
The first scenario, pbx1, deploys a full VoIP stack with
Kamailio, Asterisk, rtpengine, coturn, Nginx, and MySQL using Docker
Compose. It covers 12 attack paths across 7 guided exercises, including
SIP enumeration, traffic analysis, RTP bleed, credential cracking, SIP
digest leaks, TURN relay abuse, and more. Each exercise walks you
through real attack techniques that we regularly use during VoIP
penetration tests.
If you want to try it out without setting up your own lab, there’s a
live instance at pbx1.dvrtc.net.
Otherwise, you can run it yourself on a Linux host with Docker and host
networking. The source code is on
GitHub.
This is just the pbx1 scenario for now. We plan to add
more scenarios with different attack surfaces and more complex
deployments. If you have ideas, do open an issue on GitHub or drop me a line.
SIPVicious OSS
v0.3.5: IPv6 handling improvements
We released SIPVicious
OSS v0.3.5 with fixes for IPv6 address handling. What can I say,
IPv6 parsing is hard!
This release improves consistency in how svwar and
svcrack handle IPv6 literals and bracketed IPv6 URIs, along
with cleaner rejection of invalid URI syntax in svmap. Test
coverage for IPv6 input formats has been expanded, and documentation for
IPv6 target syntax has been updated across the README, wiki, and manual
pages.
Expect more SIPVicious updates as we continue work on the DVRTC
project.
Upcoming
conferences: OpenSIPS Summit and Kamailio World
It’s that time of the year again. OpenSIPS Summit 2026 runs April
28 to May 1 in Bucharest, Romania, which is a first for the summit since
this is the OpenSIPS team’s home city. Then Kamailio World 2026 follows on
May 7-8 in Berlin, marking both the 14th edition of the conference and
25 years of Kamailio.
I’ll be presenting at both events, talking about DVRTC. At the
OpenSIPS Summit, I’ll cover how we extended DVRTC to include OpenSIPS,
FreeSWITCH, and rtpproxy, the vulnerabilities we added, and the
configuration choices behind each one. I’m also treating this as a
feedback session, so if you have ideas for what else we should break,
come tell me ;-)
At Kamailio World, the talk focuses on the original DVRTC stack
(Kamailio, Asterisk, rtpengine), with Homer integration for visualizing
attacks in real time and some experiments using DVRTC as a honeypot to
study actual attack patterns in the wild.
If you’re attending either event, do come say hi!
Recent podcasts and
interviews
If you were wondering what we’ve been up to, I was a guest on a
couple of WebRTC-related shows recently.
In February, Arin Sime had me on WebRTC
Live #110: Everything You Need to Know About TURN Servers as part of
a panel discussing TURN servers, deployment options, and the usual
security pitfalls.
Then in March, Tsahi Levent-Levi had me on his Built
with WebRTC series. We covered what Enable Security does, the
differences between VoIP and WebRTC from a security perspective, common
issues we find during WebRTC security assessments, and of course
DVRTC.
What’s happening?
Researchers from Ruhr University Bochum and the Technology Innovation
Institute published a paper at USENIX Security
2026 on breaking DTLS-SRTP authentication across the WebRTC ecosystem.
The team, which includes Lukas Knittel (whom we know from his
BigBlueButton audio leak research), built a black-box man-in-the-middle
testing framework called DTLS-MitM-Scanner (DMS) and used it to test 24
service providers across 33 media server implementations.
The results are pretty stark: 19 of the 33 tested implementations had
vulnerabilities that let an attacker complete the DTLS handshake without
owning the private key to the certificate. For 9 of those, the
researchers confirmed they could actually retrieve media data from a
pure MitM position. The affected services include some very big
names:
- Webex: accepted empty client certificates, allowing
the researchers to listen in on video conference calls. Cisco fixed the
issue and assigned CVE-2025-20215
- Discord: two separate auth bypasses found (Oct 2022
and Feb 2024). The first was independently found and fixed by Discord;
the second earned a bug bounty
- Zoom: web application’s media server didn’t request
authentication from the browser at all. Fixed after report, rated high
severity, bug bounty awarded
- Steam: media server didn’t request client
certificates and immediately sent RTP after handshake completion
- Vonage: neither requested nor validated client
certificates, media data leaked immediately
- RingCentral: no client authentication requested,
RTP data sent directly
- Zoho: accepted any client certificate, plus used a
512-bit RSA certificate that the researchers factored in 4.5 hours
- FreeSWITCH (used by BigBlueButton v2.4): accepted
any client certificate due to a bug where the remote SDP fingerprint was
overwritten during verification. The fix PR from 2023 was never merged;
BBB v2.5 moved to mediasoup
- Teams: accepted empty or arbitrary certificates,
but no RTP media leakage was observed. Microsoft considered it out of
scope
The researchers also found that all tested browsers (Chrome, Firefox,
Safari, Edge, Opera) accept weak 512-bit RSA certificates from media
servers. Firefox additionally allows generating RSA keys with exponent
e=3, which could enable signature forgery.
The PoC exploit against Webex is particularly interesting: after
completing the DTLS handshake with an empty certificate, the attacker
requests media using Cisco’s Multistreaming protocol and receives the
call’s audio stream, decryptable in real-time. The real user appears to
have joined the call normally from other participants’ perspective.
FreePBX security talk at
AstriCon 2026
Noah King from Horizon3 AI presented
at AstriCon 2026 (part of SCaLE 23x in Pasadena) about discovering
and disclosing a chain of FreePBX vulnerabilities. We covered these
issues in our December
2025 edition, but this talk gives us the researcher’s perspective on
how they were found.
King’s team started poking at FreePBX after seeing news about an
actively targeted zero-day auth bypass without a public exploit. While
they were attempting to reverse-engineer it, a third-party exploit was
captured in a honeypot and released. Using that as a starting point to
dig deeper into the software, King’s team found a chain of unpatched
issues that allowed full unauthenticated host compromise on systems
using the webserver auth type:
- Authentication bypass (CVE-2025-66039):
with the auth type set to “web server”, passing a basic authorization
header with any base64-encoded credentials bypassed login entirely
- Path traversal and file upload (CVE-2025-61678):
the Endpoint Manager’s “custom firmware” upload could be abused with a
path traversal to drop a PHP webshell into
/var/www/html
- SQL injection (CVE-2025-61675):
multiple Endpoint Manager parameters were injectable, allowing database
writes such as creating an admin user or planting commands via
cron_jobs
The talk also goes into the disclosure process with the FreePBX team.
Horizon3’s write-up shows fixes landing across October and December 2025
before the detailed research was published. Good to see Horizon3 AI and
the FreePBX team working through this properly.
WebRTC
skimmer bypasses CSP to steal payment data from e-commerce sites
Sansec discovered a payment skimmer that
uses WebRTC DataChannels to bypass Content Security Policy (CSP, a
browser mechanism that restricts which domains a page can load scripts
from or connect to) and exfiltrate stolen card data from e-commerce
sites. Victims include an unnamed “$100+ billion car maker”, a top-3 US
bank, and a top-10 global supermarket chain.
The key trick: CSP only controls HTTP connections. WebRTC peer
connections are completely outside its scope. The skimmer constructs SDP
locally, opens a DataChannel to a hardcoded IP over DTLS-encrypted UDP,
receives its payload, and exfiltrates card data. No signaling server, no
HTTP requests to suspicious domains, nothing for WAFs or CSP to
catch.
WebRTC gives browsers super-powers, and CSP has no say over them.
This is by design, but seeing it weaponized at scale like this is a
first.
AI is
coming for your C code and it does not need coffee
Thomas Ptacek published a piece titled “Vulnerability
Research Is Cooked” that I think every RTC developer should read.
His argument is simple: AI coding agents have gotten good enough at
finding vulnerabilities that the economics of security research has
changed dramatically. Not in five years. Now.
Ptacek describes Nicholas Carlini’s work at Anthropic’s Frontier Red
Team, where the process is almost comically straightforward: download
source code, point Claude at each file, ask it to find exploitable
vulnerabilities, then verify the results. Carlini presented this at
Unprompted Con and the numbers speak for themselves: more than 500
high-severity vulnerabilities, a Firefox collaboration that led to 22
CVEs, and a Linux kernel bug that had been hiding since 2003. No coffee
required.
Why does this matter to us? Think about the codebases we work with
every day. Kamailio, Asterisk, pjsip, rtpengine, coturn, FreeSWITCH.
These are large C and C++ projects, many with decades of history,
complex state machines, and the kind of subtle memory management issues
that LLMs are apparently very good at pattern-matching. We have already
been seeing an acceleration in disclosed vulnerabilities. Look at pjsip
alone: six advisories just this month. FreePBX has been a constant
presence in our newsletter for the past year. Coturn shipped fixes for a
reversed password check that went unnoticed for seven years.
Last month we covered AISLE,
an AI-native security startup that has been finding real WebRTC and
OpenSIPS vulnerabilities. That is not a coincidence, it is the early
wave of exactly what Ptacek is describing.
So what does this mean if you maintain an open source RTC project? A
few things worth thinking about:
The volume of incoming vulnerability reports is going to increase
significantly. Projects that already struggle with security triage (and
let’s be honest, most do) will need to figure out how to handle a steady
stream of valid, reproducible, high-severity findings. The bottleneck
shifts from discovery to fixing and releasing patches.
Memory-safe rewrites are the obvious long-term answer, but that is a
multi-year effort for projects like Kamailio or Asterisk, and that only
covers a certain subset of vulnerabilities. In the meantime, automated
fuzzing, better CI security checks, and faster release cycles become
more important than ever.
For those of us on the offensive security side, the honest truth is
that AI agents already match or exceed what a human researcher can do
for common vulnerability classes in C codebases. We are adapting our own
methodology at Enable Security to account for this. The value of human
expertise shifts toward understanding the RTC-specific attack surface,
protocol-level issues, and configuration problems that require domain
knowledge an LLM does not (yet) have out of the box.
Ptacek ends his piece with a warning about regulatory overreach and I
share some of that concern. But the more immediate question for our
community is practical: are RTC projects ready for a world where finding
vulnerabilities in their code is cheap and abundant? I am not sure the
answer is yes.
Short news
PJSIP
security advisories: six vulnerabilities in pjproject 2.16 and
earlier
Six security advisories were published for pjproject this month, all
affecting version 2.16 and earlier. The most severe is a critical stack
buffer overflow in pjmedia-codec RTP payload parsing for Opus, Speex,
and Silk codecs (CVE-2026-29068),
triggered when an RTP payload contains more frames than the buffer can
hold.
Two high-severity use-after-free issues were also disclosed: one in
ICE session handling (CVE-2026-32942)
caused by race conditions between async callbacks and session
destruction, and another in the presence subscription handler (CVE-2026-28799)
triggered during unsubscription via SUBSCRIBE with
Expires=0.
The remaining three are a high-severity heap buffer overflow in the
DNS parser (CVE-2026-32945),
only affecting apps using PJSIP’s internal DNS resolver, a moderate
out-of-bounds read in SIP multipart parsing (CVE-2026-33069),
and a moderate heap OOB read in the VP9 RTP unpacketizer (CVE-2026-34235).
No tagged release yet; patches are on the master branch. We covered
previous PJSIP vulnerabilities in our February
2026 edition.
Asterisk 21.12.2
and certified-22.8-cert2
were released on March 26, 2026, updating the bundled pjproject to fix
four of the advisories listed above: the ICE session use-after-free (CVE-2026-32942),
presence subscription use-after-free (CVE-2026-28799),
SIP multipart parsing OOB read (CVE-2026-33069),
and the February ICE buffer overflow with long username (CVE-2026-25994).
Original
content here.
FreePBX:
multiple authenticated injection paths (RCE + SQLi)
Four authenticated vulnerabilities were disclosed in FreePBX modules
this month. Two are command injection flaws in the recordings module:
one via crafted filenames in AJAX endpoints (CVE-2026-28287,
CVSS 8.6) and another in the ElevenLabs TTS integration where input is
passed unsanitized to exec() (CVE-2026-28209,
CVSS 7.5). Both are patched in 16.0.20 and 17.0.5.
Two SQL injection vulnerabilities were also fixed: one in the
logfiles module via the namefile parameter (CVE-2026-28284,
CVSS 8.6, affects versions before 16.0.10 and 17.0.5) and one in the CDR
module via LIMIT parameters (CVE-2026-28210,
CVSS 8.6, affects versions before 16.0.49 and 17.0.7). We have been
covering FreePBX security extensively since August
2025.
Daniel-Constantin Mierla posted a notice on March 23, 2026 that
several CVEs for issues discovered in recent months would be published
soon. Depending on deployment type and enabled components, the security
impact could be high. The notice recommends upgrading to 6.1.1, 6.0.6,
or 5.8.8. CVE numbers were still not public as of March 31.
Original
content here.
Two cross-site scripting vulnerabilities affect Cisco contact center
products. CVE-2026-20116
affects Finesse, Packaged CCE, Unified CCE, Unified CCX, and Unified
Intelligence Center web management interfaces. CVE-2026-20117
specifically affects Unified CCX. Both allow unauthenticated remote
attackers to inject scripts via insufficient input validation.
Original
content here.
A cross-site scripting vulnerability in Cisco Webex (CVE-2026-20149)
allows unauthenticated attackers to execute scripts by tricking a user
into clicking a malicious link. Cisco says the issue has already been
addressed and no customer action is needed.
Original
content here.
Chrome 146.0.7680.153/154 for Windows and Mac, and 146.0.7680.153 for
Linux, fixes four high-severity WebRTC vulnerabilities: a stack buffer
overflow (CVE-2026-4444),
two use-after-free issues (CVE-2026-4445,
CVE-2026-4446),
and a heap buffer overflow (CVE-2026-4463).
All four were credited to the same pseudonymous reporter handle.
Original
content here.
Firefox 149 and ESR 140.9 fix three WebRTC signaling vulnerabilities:
a DoS (CVE-2026-4704,
moderate) and two undefined behavior issues (CVE-2026-4705,
moderate; CVE-2026-4718,
low). All three were credited to a team including Nicholas Carlini
“using Claude from Anthropic”, making these a concrete example of the
AI-driven vulnerability research trend we discuss elsewhere in this
edition.
Original
content here.
Avaya Call Management System has a critical RCE vulnerability (CVE-2025-1041,
CVSS 9.9) where improper input validation allows unauthorized remote
command execution via crafted web requests. Affects versions 18.x
through 19.2.0.6 and 20.0 through 20.0.0.x. Upgrade to 19.2.0.7 or
later, or 20.0.1.0 or later.
Original
content here.
Poly VVX, Edge E, and Trio 8300 devices contain embedded test keys
and certificates that can be extracted through reverse engineering (CVE-2026-0754).
If SIP service providers do not properly validate device certificates,
these credentials could be used to impersonate legitimate Poly
devices.
Original
content here.
An out-of-bounds array access in Mumble before 1.6.870 (CVE-2025-71264)
allows a malicious or compromised server to crash the client. Fixed in
Mumble 1.6.870.
Original
content here.
Rakuten Viber’s Cloak mode produces a distinctive TLS handshake
fingerprint that DPI systems can detect and block (CVE-2025-13476),
undermining its censorship-circumvention purpose. Affects Android
25.7.2.0g and Windows 25.6.0.0 through 25.8.1.0. Fixed in Android
27.2.0.0g and Windows 27.3.0.0.
Original content
here.
