---
title: SIPConfusion caller-ID spoofing, FreeSWITCH SIP DoS, OpenSIPS CVE batch
date: 2026-05-29
url: /newsletter/2026-05-rtcsec-news.md
---

Two RTC conferences ran back to back this month (OpenSIPS Summit and Kamailio World), and between the talks there was plenty of security to go around: a large batch of OpenSIPS fixes, more coturn hardening, and some sharp research on SIP identity spoofing.

In this edition, we cover:

- **DVRTC at OpenSIPS Summit and Kamailio World**: our Damn Vulnerable RTC workshop and talks, now up on YouTube
- **OpenSIPS security batch**: twelve advisories and eight assigned CVEs, including three critical issues and a TCP message-smuggling bug
- **FreeSWITCH 1.11.0**: an unauthenticated SIP PUBLISH DoS and a stack of other media-path fixes
- **SIPConfusion**: NDSS research forging caller ID and spoofing SMS via SIP parsing disagreements
- **coturn 4.10.0 and 4.11.0**: timing-safe HMAC, a realm-pinning fix, and serious new fuzzing infrastructure
- **Janus 1.4.1**: memory-safety and access-control fixes from two researchers, no CVEs attached
- **Cryptex negotiation lands in libWebRTC**: RFC 9335 support to encrypt RTP header extensions and CSRCs
- **Short news**: a flood of Chrome and Firefox WebRTC CVEs, FreePBX and GnuTLS fixes, Discord defaulting to E2EE, 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](https://www.enablesecurity.com/subscribe.md). 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

### Kamailio World 2026: Damn Vulnerable RTC for security testing

On Friday May 8 in Berlin, I gave a talk at [Kamailio World 2026](https://www.kamailioworld.com/k2026/) titled ["Damn Vulnerable RTC: A Kamailio, Asterisk and RTPEngine lab for security testing"](https://www.youtube.com/watch?v=nE43mCixP3E). We [introduced DVRTC](https://www.enablesecurity.com/newsletter/2026-03-rtcsec-news/#introducing-dvrtc-a-vulnerable-lab-for-rtc-security) back in March, so rather than rehash that here, this is the presentation recording for anyone who'd rather watch the lab get poked at than read about it.

I ran two short demos. The first is a SIP-to-SQL injection where a vulnerable Kamailio config passes the `User-Agent` header straight into `sql_query` (a config mistake, not a Kamailio bug, to be clear), so a small harness lets sqlmap dump the database as if it were a plain web target. The second is a digest leak: the attacker calls extension `2000`, the victim's challenge gets relayed back so they authenticate to the *attacker*, and the captured digest gets cracked offline with John the Ripper.

If you work with Kamailio, both demos are worth a watch. [See the talk on YouTube here](https://www.youtube.com/watch?v=nE43mCixP3E).

### OpenSIPS Summit 2026: Securing Damn Vulnerable RTC workshop and an introductory talk about DVRTC

A week before the Kamailio World talk above, I ran two DVRTC sessions at [OpenSIPS Summit 2026](https://summit.opensips.org/2026/) in Bucharest (April 28 to May 1): a short [introductory talk](https://www.youtube.com/watch?v=o2ePLC7r23Y&t=6574s) on the new `pbx2` scenario (OpenSIPS, FreeSWITCH, rtpproxy), and a hands-on [workshop](https://www.youtube.com/watch?v=1m9vrvvI9fY&t=17986s) later in the week on actually fixing the issues.

The demo from the introductory talk I want to call out is the FreeSWITCH Lua SQL injection, because the vulnerable pattern is taken almost verbatim from the official FreeSWITCH documentation and we have run into very similar code during real penetration tests. The dialplan calls a Lua script that concatenates the dialed number into a query against SQLite, with extension `2001` as the public entry point and `9000` as an internal "backdoor" you can only reach via injection. A short `'1' AND 0 UNION SELECT ...` payload typed straight into a softphone is enough to route the call to `9000`. There was also an RTP-flood / pcap storage abuse demo (the video demo failed on stage, so I described the attack from memory): 60 KB RTP payloads at 50k packets per second fill the recording disk with multiple gigabytes of pcap in a few seconds, which matters for any setup that records media unconditionally, including LEA / CALEA deployments.

The workshop ran a different format: I would show an attack, the audience would propose a fix, we would implement it live with a coding agent and then verify both that the attack was gone and that the system still worked. We started with the Lua SQLi. The cleanest suggestion came from Ihor Olkhovskyi in the audience: get the SQL out of Lua entirely and talk to a small HTTP service instead, because a blocked Lua thread blocks all of FreeSWITCH. For the demo we went with a less invasive swap, replacing `freeswitch.Dbh` with `lsqlite3` (installed via LuaRocks) so we could use proper parameterized queries. sqlmap found nothing injectable after the restart. 

We then moved on to RTP bleed, where Maxim (rtpproxy) joined the discussion: the most promising direction is binding the media session to the SSRC advertised in the SDP, so rtpproxy only learns the remote address from packets carrying that SSRC. Coarser mitigations like RTP ACLs for known interconnects, and statistics on IPs that hammer ports where no session is expected, can help too. We ran out of time before fixing much else, which is honestly the point: most of these are not one-line fixes, and the trade-offs are the interesting part. Audience reports during the sessions included a recent SIP-server compromise that led to command injection and toll fraud, and confirmation that the recording-storage abuse pattern bites real lawful-intercept deployments. Both sessions are up on YouTube ([talk](https://www.youtube.com/watch?v=o2ePLC7r23Y&t=6574s), [workshop](https://www.youtube.com/watch?v=1m9vrvvI9fY&t=17986s)) if you want to watch the demos and the discussion in full.

### OpenSIPS publishes a batch of security fixes

OpenSIPS published a [round-up of recent security fixes](https://blog.opensips.org/2026/05/21/recent-security-fixes-in-opensips/) on May 21, 2026, along with [twelve GitHub advisories](https://github.com/OpenSIPS/opensips/security/advisories). The blog post mentioned six CVEs at publication time; at the time of writing, I count eight assigned CVEs across the advisories. They worked through 30 reports in total, five of which came from Alfred Farrugia and myself at Enable Security and the rest from Tristan Madani (Talence Security) and Haruto Kimura (Stella).

Three issues are rated critical and can be triggered in configurations that call the affected script functions or transformations on attacker-controlled SIP data. [CVE-2026-45538](https://github.com/OpenSIPS/opensips/security/advisories/GHSA-37wc-5j8j-95x3) (CVSS 9.8) is a stack buffer overflow in `sip_to_json()`: an oversized SIP header name is copied into a fixed 255-byte stack buffer, making remote code execution plausible when a route calls `sip_to_json()`. [CVE-2026-45537](https://github.com/OpenSIPS/opensips/security/advisories/GHSA-v7h4-fwrc-c66v) (CVSS 9.1) is a global buffer overflow in `construct_uri()`: if a route builds a URI from attacker-controlled fields such as a long Request-URI username, the combined URI can overflow a fixed 1024-byte global buffer and corrupt adjacent global state, including SIP 503 response-handling state. [CVE-2026-45100](https://github.com/OpenSIPS/opensips/security/advisories/GHSA-35fr-6rv9-vp68) (CVSS 9.1) is a buffer overflow in the `{s.b64encode}` transformation, where the input length check misses the 4/3 output expansion of base64 encoding. The rest of the batch runs from HEPv3 parsing crashes to out-of-bounds reads and a handful of DoS conditions, most of which only bite in specific module or routing setups.

The one worth dwelling on is [CVE-2026-45103](https://github.com/OpenSIPS/opensips/security/advisories/GHSA-jv35-555v-54jh) (CVSS 7.5), a SIP message smuggling bug in the TCP framing layer. An integer overflow in the `Content-Length` handling (a value like `4294967296` wraps to 0) makes the parser split the stream in the wrong place, so a smuggled message inherits the connection's authentication and trust. That is a classic way past SBC policies and rate limiting.

This one is related to the Kamailio core TCP issue [CVE-2026-39863](https://github.com/kamailio/kamailio/security/advisories/GHSA-2wj4-f825-2h2f) we [covered in April](https://www.enablesecurity.com/newsletter/2026-04-rtcsec-news/#kamailio-fixes-two-dos-vulnerabilities-cve-2026-39863-cve-2026-39864), but it is not identical in impact. In our own prior testing the OpenSIPS variant did not crash the server; what we saw was connection retention and parser-state differences, whereas this advisory describes message smuggling from the wraparound. It is a useful reminder that shared SIP-server lineage can produce similar parser bugs, but the exploitability and severity still come down to each project's transport-state machine and data types.

A few comments. First, credit where it is due: Răzvan Crainea and the OpenSIPS team triaged a large batch of reports over a short period, opened proper GHSA advisories, requested CVEs, and shipped a release. That is the right way to handle this volume. Second, most of these issues are the kind of bugs you find when you actually look (fixed-size buffers, missing length checks, integer arithmetic on attacker-controlled inputs in protocol parsers) and some have been sitting in the code for a long time. We have been saying for a while that core open source SIP stacks deserve sustained security review, and this batch is more evidence of that. If you run OpenSIPS, upgrade to the patched release and check which of the advisories apply to your loaded modules and routing logic, since several of these only trigger in specific configurations.

## What's happening?

### SIPConfusion: spoofing caller ID and SMS by exploiting SIP's ambiguities

A team from Tsinghua University has shown, in an NDSS 2026 paper called [SIPConfusion](https://www.ndss-symposium.org/ndss-paper/sipconfusion-exploiting-sip-semantic-ambiguities-for-caller-id-and-sms-spoofing/), how SIP's flexibility lets an attacker forge caller identity and spoof SMS across VoIP, VoLTE and RCS. Qi Wang, Jianjun Chen, Jingcheng Yang, Jiahe Zhang, Yaru Yang and Haixin Duan built a black-box fuzzer, SIPCHIMERA, to hunt down the parsing and semantic disagreements that make it work.

The core idea will be familiar to anyone who has spent time with SIP. Identity lives in headers (`From`, `P-Asserted-Identity`, `Contact`), and the implementations along a call path do not agree on how to parse, normalise and trust them. When the proxy that authenticates you reads one value and the box that displays or routes the call reads another, you have request smuggling, just for identities instead of HTTP requests. SIPCHIMERA generates the inputs that trigger those disagreements, and the team used it to pull off caller ID spoofing on calls and spoofed messages over RCS.

What makes it worth reading is the breadth. They threw it at six open source SIP servers (Asterisk, OpenSIPS, Kamailio and FreeSWITCH among them), nine user agents, five VoIP devices, seven commercial SIP services and three RCS-based SMS platforms, and the header-trust problems showed up across the board, not in one buggy product. The researchers disclosed to the affected projects and report positive acknowledgements.

Here's what we think: this lands in the same place as a lot of our own work. These are not exotic memory corruption bugs, they are different components making different assumptions about the same untrusted text, and the durable fix is strict, consistent parsing and identity validation across the whole dialog rather than at a single hop. It is also one more argument that STIR/SHAKEN style attestation has to be enforced end to end, not bolted onto one edge. Worth a read if you operate or build SIP infrastructure, and the [slides](https://www.ndss-symposium.org/wp-content/uploads/s0116-wang-slides.pdf) and [talk video](https://youtu.be/7IC_CmVAlTs) from NDSS are a quicker way in.

### FreeSWITCH 1.11.0 fixes an unauthenticated SIP PUBLISH DoS, and a lot more besides

SignalWire [released FreeSWITCH 1.11.0](https://github.com/signalwire/freeswitch/releases/tag/v1.11.0) on May 7, the first major release since 1.10.12 back in August 2024. A week later they published [GHSA-5vjg-pv56-vg4c](https://github.com/signalwire/freeswitch/security/advisories/GHSA-5vjg-pv56-vg4c) ([CVE-2026-45771](https://nvd.nist.gov/vuln/detail/CVE-2026-45771), High), an unauthenticated denial-of-service in SIP PUBLISH parsing that this release fixes.

The bug is a textbook "Billion Laughs" attack against the core XML parser in `src/switch_xml.c`. The PIDF body of a SIP `PUBLISH` is fed to the parser by `mod_sofia` presence handling before any digest check, ACL check, or registration check, so a single unauthenticated request with around ten nested `<!ENTITY>` levels (each fanning out by ten) produces roughly 10^10 leaf expansions. The parser keeps realloc-growing its character buffer until the process is OOM-killed, pinning a Sofia worker thread for the duration. The attack reaches any SIP profile with `manage-presence` enabled, which is the default on the vanilla `internal` profile.

Do keep in mind that this is not the only security-relevant fix in 1.11.0. The release notes call out a few more: a fix to DTLS peer certificate verification, a libesl heap buffer overflow in `esl_buffer_write`, a missing `ice_mutex` to protect DTLS (a race condition), frame size sanitisation when parsing Opus packets, a STUN packet boundary check, and a possible `mod_httapi` segfault when a HEAD request fails. There are also two XML parser hardening items, namely the entity expansion limit that fixes CVE-2026-45771 and an option to disable XML DTD processing entirely. Most of these do not have a public CVE or GHSA attached, so 1.11.0 is worth treating as a security-significant upgrade in its own right, not just the fix for CVE-2026-45771.

You especially want to prioritise the upgrade if your deployment touches any of the following:

- **SIP presence** (`mod_sofia` with `manage-presence` enabled, which is the default on the `internal` profile). This is the CVE-2026-45771 attack surface.
- **WebRTC or DTLS-SRTP media** (browser clients, `mod_verto`, anything terminating DTLS-SRTP). The DTLS peer certificate fingerprint verification bypass, the DTLS/ICE race, and the STUN boundary fixes all live in this path.
- **ICE/STUN** more generally, including any deployment that accepts STUN from untrusted peers.
- **Opus codec** in your media path, which in practice means most WebRTC and a lot of modern SIP setups.
- **Event Socket Library (ESL) integrations**, i.e. anything linking `libesl`. The heap overflow is in the library, so the risk lands on ESL consumers rather than the FreeSWITCH daemon itself.
- **`mod_httapi`**, if you have it loaded and reachable.

A [post on pbxforums.com](https://www.pbxforums.com/threads/freeswitch-v1-11-0-release-critical-security-fix.9124/) the same week as the release urged FusionPBX operators to update "before the CVE and PoC is released". The post also argues that FreeSWITCH is the backend of FusionPBX and does not get updated when running OS or FusionPBX updates, so operators need to apply the upgrade by hand. We have not independently verified that claim, but either way, if you run FreeSWITCH, on its own or under FusionPBX, do go and upgrade. Since we drafted this, SignalWire shipped [FreeSWITCH 1.11.1](https://github.com/signalwire/freeswitch/releases/tag/v1.11.1) on May 26, another release flagged as carrying critical security fixes, including a `libesl` Content-Length check, a cJSON parser nesting cap, and a set of `mod_verto` (WebRTC) auth and memory fixes. These are separate from the 1.11.0 PUBLISH DoS above (CVE-2026-45771), so go straight to 1.11.1.

### coturn keeps up the security momentum across 4.10.0 and 4.11.0

coturn has been getting more security attention in a couple of months than it has in years. Pavel Punsky ([eakraly](https://github.com/eakraly)) shipped [coturn 4.11.0](https://github.com/coturn/coturn/releases/tag/4.11.0) on May 8, following [4.10.0 in April](https://www.enablesecurity.com/newsletter/2026-04-rtcsec-news/#coturn-4100-security-fixes), and then on May 24 published a batch of [GHSA advisories](https://github.com/coturn/coturn/security/advisories) putting CVE numbers on fixes across both releases. Here is where things stand.

The two 4.11.0 fixes worth your attention are both reachable pre-authentication, which matters because TURN servers sit out on the internet. coturn now does a timing-safe comparison of the STUN `MESSAGE-INTEGRITY` HMAC, replacing a plain `memcmp()` that leaked timing, and it now binds a session to a realm (via the STUN `ORIGIN` attribute) only after `MESSAGE-INTEGRITY` validates rather than before. Previously an attacker could forge the `ORIGIN` in an unauthenticated first packet to pin a session to a realm of their choosing, for example the one with the most permissive ACLs. Alongside those, 4.11.0 fixes a format-string injection in the Redis DB driver, hardens the HTTP parser with out-of-bounds detection, plugs a Prometheus memory leak introduced in 4.10.0, and now fails loud on malformed peer-IP ACLs: a typo in `allowed-peer-ip` or `denied-peer-ip` used to be silently ignored, which could leave you believing peer filtering was in place when it was not. coturn now aborts at startup instead.

The May 24 batch also assigned [CVE-2026-43915](https://github.com/coturn/coturn/security/advisories/GHSA-xxf5-9vj2-g84j), a stored XSS in the web-admin interface (set a malicious TURN username, it fires when an admin views the session list), fixed in 4.11.0. Then again, if you are exposing coturn's web-admin interface at all, an XSS is probably the least of your problems. ;-)

More relevant from that batch is [CVE-2026-43994](https://github.com/coturn/coturn/security/advisories/GHSA-74pg-rfh2-5qw5) (High), a stack buffer overflow in `decode_oauth_token_gcm()`. The advisory is new but the fix is not: it landed in 4.10.0 back in April, so the disclosure really only matters if you are still on 4.9.x or earlier and using OAuth tokens. Either way it is one more reason not to sit on an old release.

What we want to flag separately is the scaffolding around all this. 4.11.0 adds Unity-based unit tests, substantially extends fuzz coverage across STUN, HTTP and integrity helpers, ties into OSS-Fuzz, and adds a [fil-c](https://fil-c.org) harness for memory-safety validation. Pavel is both proactively finding issues through fuzzing and handling external security reports, and the project now has the infrastructure to keep doing it. That is a great sign for a project that has historically had long gaps between security attention. Upgrade to 4.11.0.

### Janus 1.4.1 fixes a batch of memory-safety and access-control bugs

Meetecho tagged [Janus 1.4.1](https://github.com/meetecho/janus-gateway/releases/tag/v1.4.1) and the [changelog](https://github.com/meetecho/janus-gateway/blob/v1.4.1/CHANGELOG.md) sums the security side up as "Fixed a few vulnerability issues", thanking Haruto Kimura (Stella) and Kelvin Mbogo (Add Content) for the reports and fixes. There are no CVEs and no advisory, so the only way to see what actually got fixed is to read the two PRs the work landed in. We did, and there is more here than the one-liner suggests.

[PR-3636](https://github.com/meetecho/janus-gateway/pull/3636), from Haruto Kimura, is a sweep through the media path. One fix caps how large incoming RTP/RTCP packets can be, which heads off potential stack buffer overflows when doing SRTP in the SIP and NoSIP plugins and in RTP forwarders generally. On top of that there is an out-of-bounds read/write when handling VP8 simulcast, an integer underflow in the RTX (retransmission) path, a heap over-read when opening data channels, a stack buffer overflow when `janus-pp-rec` processes a crafted MJR recording file, and a missing NULL check in the VideoRoom plugin. These are classic media and protocol parsing bugs, mostly reachable once an attacker can establish or influence the relevant RTP/RTCP or datachannel path. The `janus-pp-rec` issue is different: it needs a crafted MJR recording file to be processed by the post-processing tool.

[PR-3637](https://github.com/meetecho/janus-gateway/pull/3637), from Kelvin Mbogo, is about access control and injection rather than memory. It tightens ACL matching in the HTTP and WebSocket transport plugins (substring matching becomes prefix matching), rejects parent-directory traversal and suffix-smuggled filenames when creating file-based Streaming mountpoints, and rejects CR/LF in custom SIP header names and values, closing a header-injection vector.

None of this got a CVE or a security advisory, so it is easy to miss if you only watch CVE feeds, and the modest changelog line does not really convey how much was cleaned up. Credit to Lorenzo Miniero and the Meetecho team, though: they turned the reports around quickly, credited both researchers, and backported the fixes to the `0.x` branch so older deployments are covered too. We have been poking at Janus ourselves on recent engagements (we [mentioned it in January](https://www.enablesecurity.com/newsletter/2026-01-rtcsec-news.md)), and it is good to see this kind of care on the media path. If you run Janus, upgrade to 1.4.1, or to 0.16.1 if you are still on the legacy `0.x` branch.

### Cryptex negotiation lands in libWebRTC

After about five years, [Cryptex](https://datatracker.ietf.org/doc/html/rfc9335) negotiation has landed in libWebRTC. Sergio Garcia Murillo [announced it on LinkedIn](https://www.linkedin.com/posts/sergiogarciamurillo_after-a-final-and-awesome-heavy-lifting-from-activity-7465346076384841728-cuts), crediting Philipp Hancke for the final heavy lifting, with Pascal Bühler backporting and Harald Alvestrand putting it through a lot of review.

If you have not come across it, Cryptex is [RFC 9335](https://datatracker.ietf.org/doc/html/rfc9335), "Completely Encrypting RTP Header Extensions and Contributing Sources", from Justin Uberti, Cullen Jennings and Garcia Murillo. It closes a long-standing gap in SRTP: SRTP encrypts the media payload, but it leaves the RTP header extensions and the contributing source (CSRC) list in the clear. That metadata is not nothing. Header extensions carry things like per-packet audio levels (who is talking, and how loudly), and the CSRC list reveals which participants are mixed into a stream, all of which an on-path observer can read on an otherwise "secure" SRTP call. Cryptex encrypts those too.

Landing it in libWebRTC is the milestone that matters in practice, since that is the stack behind Chrome and most WebRTC deployments. The next steps Garcia Murillo lists are the W3C process, Chromium integration and interop testing, so it will be a while before it is on by default in browsers, but the hard part of getting it upstream is done.

We like this one. Metadata leakage is easy to wave away ("the media is encrypted, what is the problem?") right up until someone correlates audio levels or CSRCs to work out who said what on a call. Closing that gap in the core stack, rather than leaving it as a bolt-on, is the right direction.

### A vulnerable RTC lab from the University of Naples

Martina Borgstrom at the University of Naples Federico II has published [RTC_Attacks](https://github.com/WebRTC-Thesis-Unina/RTC_Attacks/), a Node.js + Docker Compose lab for "studying attack techniques against Real-Time Communication infrastructures". It came out of a thesis under the [WebRTC-Thesis-Unina](https://github.com/WebRTC-Thesis-Unina) organisation, with supporting commits from [Gaetano Perrone](https://github.com/giper45) of [CyberSecSI](https://github.com/cybersecsi).

The [`public/labs/`](https://github.com/WebRTC-Thesis-Unina/RTC_Attacks/tree/main/public/labs) directory ships nine numbered scenarios, each anchored to a real CVE with a reproducible exploit path:

1. SIP `MESSAGE` spoofing against FreeSWITCH ≤ 1.10.6 ([ES2021-07 / CVE-2021-37624](https://www.enablesecurity.com/advisories/ES2021-07-freeswitch-SIP-MESSAGE-without-auth.md))
2. SIP registration flood DoS against FreeSWITCH ≤ 1.10.6 ([ES2021-06 / CVE-2021-41145](https://www.enablesecurity.com/advisories/ES2021-06-freeswitch-flood-dos.md))
3. Kamailio heap overflow via malformed `REGISTER` ([ES2018-05 / CVE-2018-8828](https://www.enablesecurity.com/advisories/ES2018-05-kamailio-heap-overflow.md))
4. [RTP Bleed](https://www.enablesecurity.com/advisories/ES2017-04-asterisk-rtp-bleed.md) injection against Asterisk
5. TURN relay abuse on coTURN ([ES2021-01 / CVE-2020-26262](https://www.enablesecurity.com/advisories/ES2021-01-coturn-access-control-bypass.md))
6. RCE in socket.io-file ≤ 2.0.31 with a webshell + ransomware demo ([CVE-2020-24807](https://nvd.nist.gov/vuln/detail/CVE-2020-24807))
7. NoSQL injection against a mongoose login fronting VDO.Ninja ([CVE-2019-17426](https://nvd.nist.gov/vuln/detail/CVE-2019-17426))
8. XSS in VDO.Ninja 28.0 via the `room` parameter ([CVE-2025-62613](https://nvd.nist.gov/vuln/detail/CVE-2025-62613))
9. Firefox mic permission abuse driven via a [GoPhish](https://getgophish.com/) phishing chain ([CVE-2019-11748](https://nvd.nist.gov/vuln/detail/CVE-2019-11748))

Snort is wired in on the defensive side, so the same scenarios work for testing detection rules.

Five of the nine (RTP Bleed, the Kamailio heap overflow, both FreeSWITCH issues, and the coTURN ACL bypass) trace back to [our own advisories](https://www.enablesecurity.com/advisories.md), so this one made me smile. It also sits alongside our own [DVRTC](https://github.com/EnableSecurity/DVRTC/) work, and more vulnerable RTC labs is a good thing. Shout-out to Martina.

And thanks to Janus WebRTC developer Lorenzo Miniero for pointing out this project to us!

### Security at OpenSIPS Summit and Kamailio World 2026

[OpenSIPS Summit 2026](https://summit.opensips.org/2026/) (Bucharest, April 28 to May 1) and [Kamailio World 2026](https://www.kamailioworld.com/k2026/) (Berlin, May 7-8) ran back-to-back this month, and I made it to both. Here is what stood out from a security angle, on the agenda and in the hallway track.

**Kamailio World: [APIBAN and Kamailio](https://www.youtube.com/watch?v=SAxseBDTrLA) (Fred Posner).** Always good to see Fred at Kamailio World, and his update on [APIBAN](https://apiban.org/) (the free IP reputation feed for SIP scanners that has been running since 2020) had some nice numbers. Last year APIBAN blocked 83,466 IPv4 addresses on the SIP side, with around 16,000 of them brand new, plus 111,457 on the HTTP side. IPv6? Zero. Maybe this is the year that changes. What is new: a `FLUSHAFTER` option to extend the seven-day cache, an `UPTIME` feature that re-pulls the full list after a reboot instead of just deltas, YAML config support, an `nftables` client, and a local `nftables-api` for HTTP-driven ruleset management. Fred's main practical point is one we keep making too: doing the blocking inside Kamailio's `htable` works, but at sustained attack rates (he quoted ~10% CPU at 1000 cps) you really want the kernel doing the drop. From a pentester's perspective, the more interesting bit was Fred flagging the cleverer attack patterns that Ivan Nyarko has been catching in the honeypots, including an open proxy relay attack he [wrote about](https://www.kwancro.com/post/another-open-relay-scan/). So if you run APIBAN clients, do go for the `nftables` one. And if you go the htable route, do remember to set `max_while_loops=600`, because APIBAN returns IPs in batches of 600. Miss that and only the first batch loads.

**OpenSIPS Summit: [Introducing an OpenSIPS MCP Server for Everyone](https://www.youtube.com/watch?v=o2ePLC7r23Y&t=19953s) (Alex Goulis, OfficerRing).** Working code for an MCP server that exposes OpenSIPS knowledge, config templates, lint checks and version-migration tooling to any LLM or IDE that speaks MCP. The pitch: the LLM is just the orchestrator, the rendering and linting (against `opensips -C`, plus module and parameter coverage from 2.4 through 3.6) is done by deterministic Python tools shipped with the server. The bit I found most interesting is the "Pre-launch security audit" tool. You point it at an existing config and it flags the obvious foot-guns. In the live demo against a WebRTC gateway file it called out an INVITE handler with no authentication as toll-fraud risk and an MI port with no ACL, each with a suggested fix. Alex was upfront that this is not meant to be your only security check and that the rule set will need to grow as people contribute, which is the right framing. From a pentester's perspective, having a deterministic baseline that catches the easy stuff before a config goes to prod is genuinely useful. And the underlying design choice (the LLM picks which deterministic Python engine to call rather than writing the config text itself, so every output is machine-checked instead of hallucinated) is a much safer way to point these tools at production than letting an LLM freehand your config. Code is at [OpenSIPS/opensips-mcp-server](https://github.com/OpenSIPS/opensips-mcp-server).

**OpenSIPS Summit: [Vibe Routing](https://www.youtube.com/watch?v=CsGf0fudVXE&t=17319s) (Shlomi Gutman, Voicenter, presented remotely).** A companion piece to the MCP talk. Voicenter shipped a Claude Code plugin (on the Claude plugin marketplace) with two skills: "OpenSIPS Config" for generating configs from natural-language prompts with dynamically loaded module docs, and "OpenSIPS Security Advisor" which reviews an existing config and produces an HTML report with critical/high/medium findings and remediation steps. Shlomi demoed it against a deliberately broken config and recommended every OpenSIPS operator run it at least once. Code is at [VoicenterTeam/opensips-skills](https://github.com/VoicenterTeam/opensips-skills).

**OpenSIPS Summit: [SIP eSIM Calls Managed by Blockchain](https://www.youtube.com/watch?v=o2ePLC7r23Y&t=24805s) (Ron Terman, Cellact).** Ron presented Cellact's eSIM calling setup, in which service and product data (OpenSIPS server IP, per-service code, pricing, UI) is stored on a blockchain and consumed by a white-label app. As part of this, he contributed a new [`auth_web3`](https://github.com/OpenSIPS/opensips/tree/master/modules/auth_web3) module to OpenSIPS that uses Web3 authentication in place of the usual MD5-style SIP digest.

### The WebRTC Weekly on the CVE flood and Chrome's faster releases

The [WebRTC Weekly](https://webrtcweekly.com/p/webrtc-weekly-issue-640) is not a security newsletter, but a couple of things in issue 640 are worth flagging. Tsahi Levent-Levi dropped his usual security links this month with this note:

> Got a CVE flood of links in the last month. AI pen testing by Mythos and similar, along with bounty hackers make it useless to share here - so I skipped them.

We feel the volume too: a good chunk of our own short news this month is repeated Chrome, Firefox and GnuTLS rounds. These are legitimate fixes though, plenty of them coming out of AI-assisted fuzzing and bounty work (we covered Mozilla's agentic fuzzing with Anthropic). There are simply too many to list one by one, which is not the same as them not mattering. Patch them anyway.

The other useful bit is operational: Tsahi flags Chrome moving from a four-week to a two-week release cycle, so there is "less time to catch WebRTC breakage before it ships." We are already seeing several Chrome WebRTC rounds a month, so if you run WebRTC infrastructure, your testing cadence needs to keep up.

### Short news

#### [Cellular location data leaking into SIP](https://nickvsnetworking.com/somebodys-watching-me-adventures-in-cellular-locating/)

Nick (nickvsnetworking) walks through how 4G/5G networks locate subscribers and shows a SIP REGISTER and an Initial Attach with the cell global identifier embedded inline. He notes a real case of a misconfigured Mavenir IMS in O2 UK that leaked CGI (Cell Global Identifiers) in SIP messages between the two parties on a call because the B-party-facing headers were not stripped. Useful reading if you operate VoLTE, IMS, or any SIP trunk that interconnects with a mobile core: the cell identifier is present in core/IMS signalling, and a misconfigured IMS or SBC can leak it to the called party if those fields are not stripped.

[Original content here.](https://nickvsnetworking.com/somebodys-watching-me-adventures-in-cellular-locating/)

#### [Firefox patches WebRTC and Web Codecs bugs across 150, 151 and ESR](https://www.mozilla.org/en-US/security/advisories/mfsa2026-30/)

From late April through May, Firefox 150 and 151 and the matching ESR 140.10.x/140.11 releases ([MFSA 2026-30](https://www.mozilla.org/en-US/security/advisories/mfsa2026-30/), [2026-41](https://www.mozilla.org/en-US/security/advisories/mfsa2026-41/), [2026-46](https://www.mozilla.org/en-US/security/advisories/mfsa2026-46/)) fixed a run of WebRTC and Web Codecs bugs. The standout is [CVE-2026-7321](https://nvd.nist.gov/vuln/detail/CVE-2026-7321), a WebRTC Networking sandbox escape that Mozilla rates Moderate, while CISA-ADP scores it CVSS 9.6. The rest are use-after-free, boundary-condition and integer-overflow issues, including a Web Codecs DoS ([CVE-2026-8968](https://nvd.nist.gov/vuln/detail/CVE-2026-8968)) reported by Tristan Madani of Talence Security. Mozilla ties part of this wave to its [agentic-fuzzing work with Anthropic](https://hacks.mozilla.org/2026/05/behind-the-scenes-hardening-firefox/) and other models, which we covered in [March](https://www.enablesecurity.com/newsletter/2026-03-rtcsec-news.md) and [April](https://www.enablesecurity.com/newsletter/2026-04-rtcsec-news.md).

[Original content here.](https://www.mozilla.org/en-US/security/advisories/mfsa2026-30/)

#### [Chrome keeps patching WebRTC vulnerabilities across 147 and 148](https://chromereleases.googleblog.com/2026/04/stable-channel-update-for-desktop.html)

Chrome shipped several rounds of WebRTC fixes through 147 and 148: one in [147.0.7727.55](https://chromereleases.googleblog.com/2026/04/stable-channel-update-for-desktop.html), three in [147.0.7727.137/138](https://chromereleases.googleblog.com/2026/04/stable-channel-update-for-desktop_28.html), five in [148.0.7778.96/97](https://chromereleases.googleblog.com/2026/05/stable-channel-update-for-desktop.html), another in [148.0.7778.167/168](https://chromereleases.googleblog.com/2026/05/stable-channel-update-for-desktop_12.html) ([CVE-2026-8526](https://nvd.nist.gov/vuln/detail/CVE-2026-8526)), and three more in [148.0.7778.178/179](https://chromereleases.googleblog.com/2026/05/stable-channel-update-for-desktop_0841193308.html) ([CVE-2026-9111](https://nvd.nist.gov/vuln/detail/CVE-2026-9111), [CVE-2026-9119](https://nvd.nist.gov/vuln/detail/CVE-2026-9119), [CVE-2026-9120](https://nvd.nist.gov/vuln/detail/CVE-2026-9120)). All are crafted-HTML attack surface, so keep Chrome current.

[Original content here.](https://chromereleases.googleblog.com/2026/05/stable-channel-update-for-desktop.html)

#### [Cisco Unity Connection patches RCE and SSRF vulnerabilities](https://sec.cloudapps.cisco.com/security/center/content/CiscoSecurityAdvisory/cisco-sa-unity-rce-ssrf-hENhuASy)

Cisco Unity Connection fixes an authenticated RCE as root via API input validation ([CVE-2026-20034](https://nvd.nist.gov/vuln/detail/CVE-2026-20034), CVSS 8.8) and an unauthenticated SSRF in the Web Inbox via improper HTTP input validation ([CVE-2026-20035](https://nvd.nist.gov/vuln/detail/CVE-2026-20035), CVSS 7.2). Check the Cisco advisory for patches.

[Original content here.](https://sec.cloudapps.cisco.com/security/center/content/CiscoSecurityAdvisory/cisco-sa-unity-rce-ssrf-hENhuASy)

#### [Asterisk pjproject ICE and PJSIP presence vulnerabilities](https://github.com/asterisk/asterisk/security/advisories/GHSA-x2f3-ccvh-2rr2)

Three Asterisk advisories cover `res_rtp_asterisk` and `res_pjsip_pubsub`: an ICE use-after-free race condition during session cleanup ([CVE-2026-32942](https://nvd.nist.gov/vuln/detail/CVE-2026-32942), [GHSA-x2f3-ccvh-2rr2](https://github.com/asterisk/asterisk/security/advisories/GHSA-x2f3-ccvh-2rr2)), an ICE buffer overflow when processing long ICE usernames via upstream pjproject ([CVE-2026-25994](https://nvd.nist.gov/vuln/detail/CVE-2026-25994), [GHSA-rrfc-6662-c6hm](https://github.com/asterisk/asterisk/security/advisories/GHSA-rrfc-6662-c6hm)), and a heap UAF in PJSIP on presence unsubscription via `SUBSCRIBE` with `Expires: 0` ([CVE-2026-28799](https://nvd.nist.gov/vuln/detail/CVE-2026-28799), [GHSA-x6qg-jfj6-6f93](https://github.com/asterisk/asterisk/security/advisories/GHSA-x6qg-jfj6-6f93)). The May bundle (security release SB2026052528) also adds an out-of-bounds read in `pjsip_multipart_parse()` during SIP multipart body processing that can disclose adjacent heap memory ([CVE-2026-33069](https://nvd.nist.gov/vuln/detail/CVE-2026-33069), Medium). Asterisk 20.19.0, 21.12.2, 22.9.0, 23.3.0, Certified Asterisk 20.7-cert10 and 22.8-cert2 security updates are available.

[Original content here.](https://github.com/asterisk/asterisk/security/advisories/GHSA-x2f3-ccvh-2rr2)

#### [FreePBX GraphQL moduleOperations command injection (CVE-2026-41410)](https://github.com/FreePBX/security-reporting/security/advisories/GHSA-rgfm-wg7c-27w3)

FreePBX's API module GraphQL `moduleOperations` mutation passes unsanitized input to `shell_exec()` (CVSS 8.6), letting authenticated OAuth2 API users run arbitrary commands. The flaw has been present since 2020. Update the API module and restrict ACP access via VPN, MFA, or the FreePBX Firewall module.

[Original content here.](https://github.com/FreePBX/security-reporting/security/advisories/GHSA-rgfm-wg7c-27w3)

#### [FreePBX OAuth2 validateClient always returns true (CVE-2026-44237)](https://github.com/FreePBX/security-reporting/security/advisories/GHSA-vgjf-4h63-8vcc)

FreePBX's OAuth2 `validateClient()` always returns true, granting access tokens to anyone who knows the `client_id` without the client secret. Introduced in 2023, this chains with the GraphQL command injection above for unauthenticated RCE on exposed FreePBX APIs. Update the API module.

[Original content here.](https://github.com/FreePBX/security-reporting/security/advisories/GHSA-vgjf-4h63-8vcc)

#### [FreePBX UCP hard-coded default credentials authentication bypass (CVE-2026-46376)](https://github.com/FreePBX/security-reporting/security/advisories/GHSA-m55x-h47x-v3gx)

FreePBX's UCP generic template setup uses hard-coded sample credentials that allow unauthenticated access to the User Control Panel if the admin never changed them (base CVSS 9.1, real-world 6.9 with mitigations). The issue has been present since 2021. Update the `userman` module to randomize the password.

[Original content here.](https://github.com/FreePBX/security-reporting/security/advisories/GHSA-m55x-h47x-v3gx)

#### [FreePBX backup module unsafe deserialization RCE (CVE-2026-26978)](https://github.com/FreePBX/security-reporting/security/advisories/GHSA-5v7h-49gr-jcwr)

FreePBX before 16.0.71 and 17.0.6 deserializes attacker-controlled data from tar archives during backup restore ([CVE-2026-26978](https://nvd.nist.gov/vuln/detail/CVE-2026-26978)), giving an authenticated attacker with backup access code execution as `asterisk`/`www-data`. Also tracked as PT-2026-41736 and EUVD-2026-30810.

[Original content here.](https://github.com/FreePBX/security-reporting/security/advisories/GHSA-5v7h-49gr-jcwr)

#### [FreePBX Dashboard module authenticated local file inclusion (CVE-2026-44239)](https://github.com/FreePBX/security-reporting/security/advisories/GHSA-hw7v-v2jp-wc4v)

FreePBX's Dashboard `getcontent` AJAX handler includes PHP files based on `$_REQUEST['rawname']` without path sanitization ([CVE-2026-44239](https://nvd.nist.gov/vuln/detail/CVE-2026-44239), CVSS 7.6). Path traversal via `../` sequences lets an authenticated user include arbitrary `.class.php` files; the included PHP executes before the class instantiation error, giving RCE as `asterisk`. Introduced on or before 2022. Update the `dashboard` module.

[Original content here.](https://github.com/FreePBX/security-reporting/security/advisories/GHSA-hw7v-v2jp-wc4v)

#### [FreePBX CDR Reports authenticated SQL injection via ORDER BY (CVE-2026-44238)](https://github.com/FreePBX/security-reporting/security/advisories/GHSA-p9fq-fmpw-2h9x)

FreePBX CDR Reports interpolates the `order` and `sort` POST parameters directly into the ORDER BY clause without adequate sanitization ([CVE-2026-44238](https://nvd.nist.gov/vuln/detail/CVE-2026-44238), CVSS 8.5). The `escapeSimple()` function only escapes single quotes and is ineffective in an unquoted ORDER BY context. Any ACP account with CDR section access can exploit this. It also bypasses the March 2026 CDR Reports fix (CVE-2026-28210) which addressed only the LIMIT parameter in the same file. Update the `cdr` module.

[Original content here.](https://github.com/FreePBX/security-reporting/security/advisories/GHSA-p9fq-fmpw-2h9x)

#### [GnuTLS DTLS handshake heap overflow (CVE-2026-33846)](https://www.gnutls.org/security-new.html#GNUTLS-SA-2026-04-29-1)

GnuTLS before 3.8.13 has a heap buffer overflow in DTLS handshake fragment reassembly ([CVE-2026-33846](https://nvd.nist.gov/vuln/detail/CVE-2026-33846)). The `merge_handshake_packet()` function matches fragments by handshake type without checking message length consistency, and a missing array size check means crafted fragments with conflicting length fields trigger an OOB write on the heap. Remotely exploitable via the DTLS handshake with no authentication required. Reported by Haruto Kimura (Stella), Oscar Reparaz, and Zou Dikai. Worth noting that GnuTLS is not widely used in WebRTC stacks - DTLS-SRTP is mostly OpenSSL/BoringSSL/libsrtp territory, with GnuTLS being comparatively niche.

[Original content here.](https://www.gnutls.org/security-new.html#GNUTLS-SA-2026-04-29-1)

#### [GnuTLS DTLS reassembly second heap overrun (CVE-2026-33845)](https://www.gnutls.org/security-new.html#GNUTLS-SA-2026-04-29-3)

A second remotely triggerable heap overrun in GnuTLS's DTLS reassembly code ([CVE-2026-33845](https://nvd.nist.gov/vuln/detail/CVE-2026-33845)), distinct from CVE-2026-33846 in the same 3.8.13 release. High severity, no authentication required.

[Original content here.](https://www.gnutls.org/security-new.html#GNUTLS-SA-2026-04-29-3)

#### [GnuTLS DTLS packet reordering DoS (CVE-2026-42009)](https://www.gnutls.org/security-new.html#GNUTLS-SA-2026-04-29-2)

GnuTLS's DTLS sequence number comparator mishandles duplicate sequence numbers during packet reordering, causing undefined behaviour and a DoS ([CVE-2026-42009](https://nvd.nist.gov/vuln/detail/CVE-2026-42009)). Remotely triggerable with no authentication needed, affecting VoIP and real-time media components using GnuTLS, though GnuTLS notes that modern glibc-based systems that do not fall back to quicksort are not affected. Fixed in 3.8.13.

[Original content here.](https://www.gnutls.org/security-new.html#GNUTLS-SA-2026-04-29-2)

#### [GnuTLS RSA-PSK authentication bypass via NUL username (CVE-2026-42010)](https://www.gnutls.org/security-new.html#GNUTLS-SA-2026-04-29-4)

GnuTLS before 3.8.13 has a bug where RSA-PSK usernames containing NUL characters match truncated versions, allowing authentication bypass ([CVE-2026-42010](https://nvd.nist.gov/vuln/detail/CVE-2026-42010)). Relevant to SIP/TLS or DTLS deployments using PSK authentication.

[Original content here.](https://www.gnutls.org/security-new.html#GNUTLS-SA-2026-04-29-4)

#### [Elixir WebRTC missing DTLS fingerprint validation (CVE-2026-44700)](https://github.com/elixir-webrtc/ex_webrtc/security/advisories/GHSA-qwfw-ggxw-577c)

`ex_webrtc` before 0.15.1 and 0.16.1 skips the peer certificate fingerprint check when acting in DTLS client role ([CVE-2026-44700](https://nvd.nist.gov/vuln/detail/CVE-2026-44700)), removing one half of WebRTC mutual authentication. This enables a full MITM on SRTP and SCTP data channels when combined with insecure signalling. Worth noting: insecure signalling alone is enough for the same MITM without any DTLS bug, since an attacker can swap the `a=fingerprint:` in the SDP and the library's fingerprint check becomes pointless. Affects media servers and SFUs answering browser offers.

[Original content here.](https://github.com/elixir-webrtc/ex_webrtc/security/advisories/GHSA-qwfw-ggxw-577c)

#### [STUNner v1.2.0 merges pion/turn TURN amplification mitigation](https://github.com/l7mp/stunner/releases/tag/v1.2.0)

[STUNner v1.2.0](https://github.com/l7mp/stunner/releases/tag/v1.2.0) (May 19, 2026), the Kubernetes-native WebRTC media gateway from l7mp, merges the upstream `pion/turn` NONCE size optimization that mitigates the ongoing TURN amplification attacks (unauthenticated TURN requests producing larger error responses than the trigger, making the server a UDP reflector). The release also bumps Pion, Kubernetes Gateway API, and OpenTelemetry dependencies to pick up upstream security fixes, and hardens authentication and authorization on the Config Discovery Service (CDS). If you run STUNner, upgrade.

[Original content here.](https://github.com/l7mp/stunner/releases/tag/v1.2.0)

#### [Discord makes E2EE the default on all voice and video calls](https://discord.com/blog/every-voice-and-video-call-on-discord-is-now-end-to-end-encrypted)

Discord [announced](https://discord.com/blog/every-voice-and-video-call-on-discord-is-now-end-to-end-encrypted) that end-to-end encryption is now on by default for every voice and video call, no opt-in required. It covers DMs, group DMs, voice channels and Go Live streams (stage channels and text messages are excluded), using the DAVE protocol introduced in September 2024, with an open implementation in [discord/libdave](https://github.com/discord/libdave) reviewed by Trail of Bits.

[Original content here.](https://discord.com/blog/every-voice-and-video-call-on-discord-is-now-end-to-end-encrypted)

#### [Element Call leaks call URLs with encryption keys to PostHog analytics (CVE-2026-48007)](https://github.com/element-hq/element-call/security/advisories/GHSA-6vhh-4xw6-h2h2)

Element Call versions 0.5.17 to 0.19.3 send call URLs that contain the call's encryption password to PostHog analytics when analytics are enabled ([CVE-2026-48007](https://nvd.nist.gov/vuln/detail/CVE-2026-48007), [GHSA-6vhh-4xw6-h2h2](https://github.com/element-hq/element-call/security/advisories/GHSA-6vhh-4xw6-h2h2)), exposing the encryption credentials to anyone with access to the analytics data. It is the classic "secrets in the URL fragment" mistake. Standalone deployments like call.element.io are most at risk, while embedded Element Web, Desktop and X use a safer key-distribution path. Fixed in 0.19.4; otherwise disable PostHog analytics or regenerate the call links.

[Original content here.](https://github.com/element-hq/element-call/security/advisories/GHSA-6vhh-4xw6-h2h2)

#### [Wireshark VoIP parser DoS bugs in the RTSP, SDP and iLBC dissectors](https://www.wireshark.org/security/)

Three Wireshark dissector denial-of-service bugs are worth noting for anyone analysing VoIP traffic: crashes in the RTSP parser ([CVE-2026-6526](https://nvd.nist.gov/vuln/detail/CVE-2026-6526)) and the SDP parser ([CVE-2026-5655](https://nvd.nist.gov/vuln/detail/CVE-2026-5655)) in 4.6.0 to 4.6.4, and one in the iLBC codec dissector ([CVE-2026-6529](https://nvd.nist.gov/vuln/detail/CVE-2026-6529)) affecting 4.4.0 to 4.4.14 and the 4.6.x line. A crafted packet or capture file crashes the dissector, so update Wireshark if you open untrusted captures.

[Original content here.](https://www.wireshark.org/security/)

#### [sipexer v2.0.0 released](https://github.com/miconda/sipexer)

Daniel-Constantin Mierla (miconda) [released sipexer v2.0.0](https://www.kamailio.org/w/2026/05/sipexer-v2-0-0-released/), the Go-based SIP CLI for crafting custom SIP requests and testing signalling and SBCs. The release adds modern digest auth hashing (SHA-256, SHA-512 and AKAv1-MD5 beyond legacy MD5), new `--call-self`, `--call-user` and `--subscribe-session` flags to simulate dialogues, registration floods and stateful flows, and dynamic templating (UUIDs, random strings and env vars in headers) for generating varied SIP test traffic.

[Original content here.](https://github.com/miconda/sipexer)

---

Thanks to [Vulners](https://vulners.com/) 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](https://www.enablesecurity.com/subscribe.md)