NuGet · SIPSorcery
SIPSorcery: Malformed UDP datagram crashes TurnServer receive loop with no restart, disabling TURN UDP relay for all clients (DoS)
TurnServer.ReceiveUdpAsync places its generic catch (Exception) OUTSIDE the while receive loop, and Start() launches the loop fire-and-forget with no supervision or restart. A single pre-authentication UDP datagram whose STUN header first byte is in 0x80–0xFF causes STUNHeader.ParseSTUNHeader to throw ApplicationException, which unwinds past the loop and terminates it. The TURN UDP relay is then dead for ALL clients until the process is restarted.
src/SIPSorcery/net/TURN/TurnServer.cs:
ReceiveUdpAsync (:555-577): the inner try (:562-567) wraps only _udpSocket.ReceiveAsync(); HandleUdpDatagram(result.Buffer, result.RemoteEndPoint) (:569) is inside the while body but OUTSIDE that inner try. The generic catch (Exception ex) (:573) is lexically OUTSIDE the while.Start() does _ = ReceiveUdpAsync(); (:381) — fire-and-forget, no restart.HandleUdpDatagram (:579) calls STUNMessage.ParseSTUNMessage(data, data.Length) (:600) for any non-ChannelData datagram; ParseSTUNMessage (STUNMessage.cs:94) has no try/catch.ApplicationException propagates out of the while, is caught at :573, logged, and the method returns. _running remains true but nothing re-invokes ReceiveUdpAsync → TURN UDP relay permanently unavailable for all clients (whole-server DoS). Pre-authentication: STUN parsing precedes any TURN allocation/credential check.
Send one UDP datagram to the TURN port (default 3478) with first byte 0x80 (e.g. 80 00 00 00). 0x80 & 0xC0 = 0x80 ≠ 0x40 → not ChannelData → ParseSTUNMessage → ParseSTUNHeader executes if ((Array[startIndex] & 0xC0) != 0) throw new ApplicationException(...) (STUNHeader.cs:169-172); 0x80 & 0xC0 = 0x80 ≠ 0 → throws.
0x80–0xFF. Guard: ChannelData branch requires (data[0] & 0xC0) == 0x40 (:583). Bypass: 0x80 & 0xC0 = 0x80 ≠ 0x40 → falls through to ParseSTUNMessage (:600).STUNMessage.ParseSTUNMessage → STUNHeader.ParseSTUNHeader (STUNHeader.cs:169-172) throws ApplicationException. Guard: none before the throw; ParseSTUNMessage has no try/catch. Bypass: 0x80 & 0xC0 = 0x80 ≠ 0 → throws.while into catch(Exception) at :573 → logged → method returns → loop exits. Guard: none — no restart (Start() :381 fire-and-forget). Bypass: N/A. TURN UDP relay dead for all clients until process restart.while at :559; HandleUdpDatagram at :569 is outside the inner try (:562-567).ParseSTUNMessage at :600; throw at STUNHeader.cs:169-172.Start().TurnServerConfig.ListenAddress defaults to IPAddress.Loopback (:42), but a functioning TURN server must bind a routable address to serve clients, so real deployments are exposed. Non-default config narrows the vulnerable population, not the attack difficulty → AC:L.nuget:SIPSorcery <= 10.0.13 (TurnServer component present since 10.0.5; verified on release tag v10.0.13 and HEAD).
NOT a duplicate of GHSA-28gm-jrmw-xx93 (CVE-2026-54632), which covers the client RTP/ICE socket (UdpReceiver/RTPChannel). TurnServer is a distinct shipped RFC 5766 server component with its own loop and fix location.
Wrap HandleUdpDatagram in a per-datagram try/log-and-continue INSIDE the while (matching the drop-and-continue intent of fix bdb76cb), and/or add loop supervision/restart.
Reported by zx (Jace) — GitHub: @manus-use
Is your project exposed to this? Stateward checks every dependency on every pull request and flags it only if your code actually reaches it.
Check my repoSources: CISA KEV (public domain), OSV.dev & GitHub Advisory Database (CC-BY-4.0), FIRST EPSS, NVD/CWE (public domain). Served live from the Stateward advisory database.