TL;DR
We are publishing two FreeSWITCH advisories: one for redirecting and injecting plaintext call audio, and another for causing one-way audio, even when SRTP is used. We worked with the SignalWire/FreeSWITCH team to test and address both issues. The changes are included in FreeSWITCH 1.11.2. Upgrading alone is not enough to mitigate the RTP hijacking issue: two new controls must also be configured.
One report, two vulnerabilities
We found these issues during our internal research and reported them to the FreeSWITCH team in June 2025. This was before our ClueCon presentation, Media Security Is Hard: The Many Ways RTP & SRTP Still Fail Us.
We initially reported these as one problem. Further analysis made it clear that we were dealing with two separate vulnerabilities, each needing its own CVE. They concern the same media handling code, but one is about how FreeSWITCH chooses a media peer, and the other is about when it rejects packets from anyone else.
Learning the wrong media peer
RTP source learning exists for a good reason: NAT. The address an endpoint advertises in SDP is not always the address its media actually comes from. FreeSWITCH’s RTP auto-adjust feature watches incoming packets and adjusts the media destination accordingly.
What could possibly go wrong?
An attacker who reaches the media port during call setup can send enough RTP packets to win that learning race. FreeSWITCH then adopts the attacker’s address, sends call audio there, and accepts the attacker’s packets as call media. The legitimate endpoint cannot reclaim the session once that learning window closes.
That gives us both RTP Bleed (audio sent to the attacker) and RTP Inject (attacker-supplied audio entering the call). Both stem from the same source-learning flaw, tracked as CVE-2026-119293 (CVSS v4.0: 9.3 Critical).
The attacker does not need SIP credentials or a position on the media path. They do need to reach the allocated media port or spray the RTP range during setup. Winning the race depends on how quickly the legitimate endpoint starts sending media and how many ports the attacker has to cover. On plaintext RTP, the attacker can hear and inject audio. With SRTP, they cannot decrypt the audio or inject valid media without the session keys.
Read advisory ES2026-07 and the reproduction lab.
Rejecting packets, but too late
The second issue affects established calls, after FreeSWITCH has already learned the legitimate media peer.
FreeSWITCH rejected packets from other sources, but only after doing much of the work to process them. On encrypted calls, that included attempting SRTP authentication and decryption. A sustained flood kept the media read path busy enough to stop legitimate audio from getting through.
In a bridged call, flooding one leg stopped the far endpoint from hearing that participant. Audio in the opposite direction could continue, and SIP signalling stayed up. From the users’ perspective: one-way audio.
This is CVE-2026-119292 (CVSS v4.0: 8.7 High). It does not let an attacker hear or inject encrypted audio. They need to reach an active media port, but they do not need the SRTP key. Their packets fail authentication, but FreeSWITCH still spends time processing them. Send enough, and legitimate audio stops getting through.
What should FreeSWITCH operators do?
Upgrade to FreeSWITCH 1.11.2 or a later release containing the changes. The updated code rejects packets from unexpected sources earlier, before SRTP processing. This prevented audio from stopping completely in our tests, without additional configuration. Do keep in mind that very high-rate floods still caused packet loss.
For the source-learning race, also configure both channel variables before RTP session creation:
rtp_auto_adjustment_wait_for_advertised_msrtp_packet_not_advertised_reject_threshold
Both default to zero. We tested 3000 ms and 5 together, but these are validation values, not universal production settings. The advisory covers configuration and NAT considerations. These settings prevented persistent takeover and application-level injection in our test, although two transient outbound packets still reached the attacker during learning.
Use SRTP where possible to protect call contents, and restrict media access where your topology allows it. SRTP does not replace the flood-handling fix.
Getting from a report to a reproducible fix
This took longer than any of us would have liked, and some of that delay was on our side too. We could reproduce the issues reliably with our tools, but getting the same results with the developers’ existing test tools took more work. The fixes also had to preserve legitimate media behaviour.
We worked hand in hand with the SignalWire/FreeSWITCH team throughout this process, helping set up our security testing tools for their developers. That gave us a shared way to reproduce the issues and verify what the changes actually prevented.
Thanks to the SignalWire/FreeSWITCH team for working through this with us. As the talk title suggested: media security is hard. That includes testing it properly.
