RedMirror reported a SIPSorcery media-session denial of service, now CVE-2026-54632 (CVSS 7.5), fixed in version 10.0.9. Before calling it a finding, RedMirror proved a reachable path with a state-space search, reproduced it against a real socket on .NET 8, and rated it honestly. Findings are proofs, not opinions.
The bug we reported in SIPSorcery now has a CVE, a patched release, and a mention in RTCSec News, the newsletter Enable Security has been writing for the VoIP and WebRTC security community for years. Their short-news entry reads:
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. RTCSec News, 30 July 2026
That is our finding, tracked as GHSA-28gm-jrmw-xx93 and reported privately ahead of the fix. We wrote up the mechanics when the patch landed: one malformed UDP packet could tear down a SIPSorcery media session. The newsletter tracks the vulnerability rather than the tool that found it, which is exactly as it should be. What made the mention worth writing about is the rest of the issue.
The lead story that week is about AI-discovered remote code execution in Brekeke SIP Server and Cisco CUCM, and the editorial around it is blunt about where the work has moved. Finding candidate vulnerabilities is now cheap. Establishing that a candidate is real, and rating it honestly, is the expensive part that keeps getting skipped. The author describes reports arriving with scary CVSS numbers attached to a wall of generated text and hallucinated reproduction logs, and lands on a rule:
Reproduce before you rate, be honest about the impact. RTCSec News, 30 July 2026
And on AI's actual role:
AI is a genuinely strong assistant for this work. It just still needs a lab and a skeptic. RTCSec News, 30 July 2026
We agree with all of it, and it is a fair description of the problem we set out to solve. A language model that reads code will produce plausible vulnerability reports all day. Plausible is worthless to a maintainer. The only thing worth their attention is a claim someone has already tried to break.
Three gates stood between "the model thinks this is a bug" and the private report to the maintainer.
The skeptic is a search, not an opinion. The receive path was modelled as a state machine, with the property we cared about stated as an invariant: an active media channel stays open. Our kernel then searched the reachable states looking for a way to violate it. It came back with a two-step path, not a paragraph of prose:
invariant: single_packet_keeps_channel_open (channel_open == 1) REFUTED 1. <init> channel_open=1 2. recv_xor_address_attr[vlen=0] channel_open=0 // one zero-length XOR attribute
Either the search finds such a path or it does not. There is no confidence score to inflate.
The lab is a real socket. A refuted invariant is still only a claim about our model of the code, so the counterexample was rebuilt as a proof of concept against a real RTPChannel on .NET 8, with a plain UdpClient as the attacker. Two vectors ran end to end: a STUN message carrying a zero-length XOR-MAPPED-ADDRESS attribute, and a one-byte UDP datagram. Both tore the channel down. That output, and the code to rerun it, went to the maintainer along with the report.
Rate it for what it is. The suggested score was AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H, which is 7.5, availability only. No confidentiality impact, no integrity impact, no RCE framing. We also wrote down what weakens it: a blind off-path attacker has to learn the ephemeral media port first, so the clean case is a malicious peer or an on-path attacker who already has the ICE candidate from the SDP exchange. Volunteering the caveat costs a few points of severity and buys the one thing that matters when you turn up in a maintainer's inbox unannounced.
Maintainers are the scarce resource here, and every unverified AI report spends a little of them. SIPSorcery's maintainer got a reproducible crash, a minimal packet, and a severity that survived scrutiny, and shipped a fix in 10.0.9 that both adds the missing length checks and stops the receive loop from closing the channel on a single bad packet.
The lab and the skeptic are not a process we ask our users to remember. They are the product. RedMirror only calls something a finding when a search over the reachable states of your code produced a concrete path into a state it should not reach, and where we can run it, when the path reproduces. Everything else is filed as a candidate with the reason it was ruled out, which is a much less exciting thing to publish and a much more useful thing to receive.
CVE-2026-54632 is a denial-of-service vulnerability in SIPSorcery. Versions 10.0.8 and earlier crash on a malformed UDP packet on the RTP/ICE socket, reachable before the DTLS handshake or STUN auth, so any active RTP or WebRTC session can be dropped. It is rated CVSS 7.5 and fixed in SIPSorcery 10.0.9.
Yes. It was reported privately as GHSA-28gm-jrmw-xx93 ahead of the fix, and SIPSorcery 10.0.9 both adds the missing length checks and stops the receive loop from closing the channel on a single bad packet.
RedMirror modelled the receive path as a state machine with the invariant that an active media channel stays open, then searched the reachable states and returned a two-step counterexample path. That path was rebuilt as a proof of concept against a real RTPChannel on .NET 8 and reproduced end to end before the report was sent.
It comes from the RTCSec News editorial: establish that a candidate vulnerability is real and reproduce it before attaching a severity score, instead of sending a maintainer a scary CVSS number wrapped in generated text and hallucinated reproduction logs. RedMirror only calls something a finding when the path reproduces.
Because an honest rating is what earns a maintainer's attention. The bug was scored 7.5, availability only, with no confidentiality, integrity, or RCE framing, and RedMirror noted that a blind off-path attacker must first learn the ephemeral media port, so the clean case is a malicious peer or an on-path attacker. The caveat costs a few points of severity and buys credibility.
Point RedMirror at your repo and you get reachable, reproducible paths rather than a wall of generated text. Anything that parses untrusted bytes off a socket is a good place to start.
Get RedMirror Read the SIPSorcery write-up