One malformed UDP packet could tear down a SIPSorcery media session

A single malformed, unauthenticated UDP packet sent to a SIPSorcery media socket could crash the receive path and close the entire RTP/ICE channel, dropping an active call, with no handshake or credentials. Tracked as GHSA-28gm-jrmw-xx93 / CVE-2026-54632 (High, 7.5), it was fixed in PR #1677; upgrade SIPSorcery to 10.0.9 or later.

SIPSorcery is a widely used .NET stack for real-time communications: SIP telephony, VoIP, and WebRTC. Like every RTC stack, its media plane lives on UDP: audio and video arrive as RTP packets, and the connection is negotiated with ICE, whose keep-alives are STUN packets. That media socket takes bytes straight off the network, before any authentication. That is simply how real-time media works.

We found that a single crafted UDP packet, sent by anyone who could reach that port, could crash the receive path and close the entire RTP/ICE channel, dropping the call. No handshake, no credentials, no session state required. One packet.

Send one short, malformed RTP or STUN packet at the media socket and the receiver throws while parsing it, and then tears down the whole channel in response.

Why are two small assumptions together fatal?

The bug is the seam between two pieces of code that are each locally reasonable:

• The RTP-packet and STUN-attribute parsers read fields at fixed offsets (version, type, length, attribute headers), assuming the packet is at least as long as a valid one. A short or truncated packet makes one of those reads run past the end of the buffer and throw.
• The UDP receive loop treated any exception while processing a packet as fatal, and responded by closing the channel.

Neither is obviously wrong on its own. A parser may assume well-formed input; a receive loop may want to fail loudly. But put them together on a socket that accepts unauthenticated packets from the open network, and the invariant that actually matters, “a malformed packet is dropped, not fatal,” is violated. One packet drives the channel into the closed state.

// the shape of the receive path, before the fix
OnPacket(byte[] buf) {
    var pkt = RTPPacket.Parse(buf);      // reads fixed offsets; a short buf throws
    ...
}
OnException(ex) {
    Close();                             // one bad packet -> whole channel torn down
}

Because UDP is connectionless and the source address is spoofable, the attacker needs no place in the call and no prior packets. The media port is discoverable from the SDP/ICE exchange, and a single datagram is enough to end an in-progress session: a clean, cheap, pre-authentication denial of service.

How was it fixed?

SIPSorcery PR #1677 (merged) closes both halves of the seam:

• Minimum-length checks for packets received on the RTP channel and for STUN attributes, so a short packet is rejected before any out-of-bounds read.
• The UdpReceiver no longer closes when an exception occurs processing a single packet. In the maintainer's words, that behaviour “was a potential DoS vector.” A bad packet is now dropped and the channel keeps running.

The issue was reported privately ahead of the fix and is tracked as advisory GHSA-28gm-jrmw-xx93 / CVE-2026-54632 (High, 7.5). Everything up to and including 10.0.8 is affected; if you build on SIPSorcery, take 10.0.9 or later.

Update, August 2026: this one was picked up by the RTCSec News newsletter, in an issue whose editorial makes the case that AI-found vulnerabilities need a lab and a skeptic before they need a CVSS score. More on that, and on what we verified before sending the report, in Reproduce before you rate.

Why is this the kind of bug RedMirror finds?

A parser that reads fixed offsets and a receive loop that closes on error each pass code review in isolation; nothing in either file is a “known-bad” pattern a linter flags. The defect only exists in the relationship between them, on the specific socket that receives untrusted input. RedMirror models how a packet actually flows through the receive path and looks for a reachable state where an unauthenticated input drives the system somewhere it shouldn't go: here, an active channel reaching closed with no consent from either peer. It reports the concrete input that gets there, so the maintainer can reproduce it before an attacker does.

Frequently asked questions