GHSA-PFVM-W89X-94JW

Vulnerability from github – Published: 2026-08-12 19:31 – Updated: 2026-08-12 19:31
VLAI
Summary
SIPSorcery: Malformed UDP datagram crashes TurnServer receive loop with no restart, disabling TURN UDP relay for all clients (DoS)
Details

Summary

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.

Root Cause

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.

Impact

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.

Proof of Concept

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 → ParseSTUNMessageParseSTUNHeader executes if ((Array[startIndex] & 0xC0) != 0) throw new ApplicationException(...) (STUNHeader.cs:169-172); 0x80 & 0xC0 = 0x80 ≠ 0 → throws.

Attack Chain

  1. Entry: one UDP datagram to the TURN port, first byte 0x80–0xFF. Guard: ChannelData branch requires (data[0] & 0xC0) == 0x40 (:583). Bypass: 0x80 & 0xC0 = 0x80 ≠ 0x40 → falls through to ParseSTUNMessage (:600).
  2. Sink: STUNMessage.ParseSTUNMessageSTUNHeader.ParseSTUNHeader (STUNHeader.cs:169-172) throws ApplicationException. Guard: none before the throw; ParseSTUNMessage has no try/catch. Bypass: 0x80 & 0xC0 = 0x80 ≠ 0 → throws.
  3. Impact: exception unwinds past the 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.

Bypass Evidence

  • Loop/catch structure: catch at TurnServer.cs:573 is outside the while at :559; HandleUdpDatagram at :569 is outside the inner try (:562-567).
  • Unguarded ParseSTUNMessage at :600; throw at STUNHeader.cs:169-172.
  • Fire-and-forget start at :381 with no restart in 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.

Affected Versions

nuget:SIPSorcery <= 10.0.13 (TurnServer component present since 10.0.5; verified on release tag v10.0.13 and HEAD).

Dedup

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.

Suggested Fix

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

Show details on source website

{
  "affected": [
    {
      "database_specific": {
        "last_known_affected_version_range": "\u003c= 10.0.13"
      },
      "package": {
        "ecosystem": "NuGet",
        "name": "SIPSorcery"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "10.0.5"
            },
            {
              "fixed": "10.0.14"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [],
  "database_specific": {
    "cwe_ids": [
      "CWE-248",
      "CWE-755"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2026-08-12T19:31:48Z",
    "nvd_published_at": null,
    "severity": "HIGH"
  },
  "details": "## Summary\n`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\u20130xFF` 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.\n\n## Root Cause\n`src/SIPSorcery/net/TURN/TurnServer.cs`:\n- `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`.\n- `Start()` does `_ = ReceiveUdpAsync();` (:381) \u2014 fire-and-forget, no restart.\n- `HandleUdpDatagram` (:579) calls `STUNMessage.ParseSTUNMessage(data, data.Length)` (:600) for any non-ChannelData datagram; `ParseSTUNMessage` (STUNMessage.cs:94) has no try/catch.\n\n## Impact\n`ApplicationException` propagates out of the `while`, is caught at :573, logged, and the method returns. `_running` remains true but nothing re-invokes `ReceiveUdpAsync` \u2192 TURN UDP relay permanently unavailable for all clients (whole-server DoS). Pre-authentication: STUN parsing precedes any TURN allocation/credential check.\n\n## Proof of Concept\nSend one UDP datagram to the TURN port (default 3478) with first byte `0x80` (e.g. `80 00 00 00`). `0x80 \u0026 0xC0 = 0x80 \u2260 0x40` \u2192 not ChannelData \u2192 `ParseSTUNMessage` \u2192 `ParseSTUNHeader` executes `if ((Array[startIndex] \u0026 0xC0) != 0) throw new ApplicationException(...)` (STUNHeader.cs:169-172); `0x80 \u0026 0xC0 = 0x80 \u2260 0` \u2192 throws.\n\n## Attack Chain\n1. Entry: one UDP datagram to the TURN port, first byte `0x80\u20130xFF`. Guard: ChannelData branch requires `(data[0] \u0026 0xC0) == 0x40` (:583). Bypass: `0x80 \u0026 0xC0 = 0x80 \u2260 0x40` \u2192 falls through to `ParseSTUNMessage` (:600).\n2. Sink: `STUNMessage.ParseSTUNMessage` \u2192 `STUNHeader.ParseSTUNHeader` (STUNHeader.cs:169-172) throws `ApplicationException`. Guard: none before the throw; `ParseSTUNMessage` has no try/catch. Bypass: `0x80 \u0026 0xC0 = 0x80 \u2260 0` \u2192 throws.\n3. Impact: exception unwinds past the `while` into `catch(Exception)` at :573 \u2192 logged \u2192 method returns \u2192 loop exits. Guard: none \u2014 no restart (`Start()` :381 fire-and-forget). Bypass: N/A. TURN UDP relay dead for all clients until process restart.\n\n## Bypass Evidence\n- Loop/catch structure: catch at TurnServer.cs:573 is outside the `while` at :559; `HandleUdpDatagram` at :569 is outside the inner try (:562-567).\n- Unguarded `ParseSTUNMessage` at :600; throw at STUNHeader.cs:169-172.\n- Fire-and-forget start at :381 with no restart in `Start()`.\n- `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 \u2192 AC:L.\n\n## Affected Versions\n`nuget:SIPSorcery \u003c= 10.0.13` (TurnServer component present since 10.0.5; verified on release tag v10.0.13 and HEAD).\n\n## Dedup\nNOT 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.\n\n## Suggested Fix\nWrap `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.\n\n---\nReported by **zx (Jace)** \u2014 GitHub: @manus-use",
  "id": "GHSA-pfvm-w89x-94jw",
  "modified": "2026-08-12T19:31:48Z",
  "published": "2026-08-12T19:31:48Z",
  "references": [
    {
      "type": "WEB",
      "url": "https://github.com/sipsorcery-org/sipsorcery/security/advisories/GHSA-pfvm-w89x-94jw"
    },
    {
      "type": "WEB",
      "url": "https://github.com/sipsorcery-org/sipsorcery/commit/ccb0b5a845efa2fb131fd00de4f5321bae627f29"
    },
    {
      "type": "PACKAGE",
      "url": "https://github.com/sipsorcery-org/sipsorcery"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H",
      "type": "CVSS_V3"
    }
  ],
  "summary": "SIPSorcery: Malformed UDP datagram crashes TurnServer receive loop with no restart, disabling TURN UDP relay for all clients (DoS)"
}



Log in or create an account to share your comment.




Tags
Taxonomy of the tags.


Loading…

Loading…

Loading…

Forecast uses a logistic model when the trend is rising, or an exponential decay model when the trend is falling. Fitted via linearized least squares.

Sightings

Author Source Type Date Other

Nomenclature

  • Seen: The vulnerability was mentioned, discussed, or observed by the user.
  • Confirmed: The vulnerability has been validated from an analyst's perspective.
  • Published Proof of Concept: A public proof of concept is available for this vulnerability.
  • Exploited: The vulnerability was observed as exploited by the user who reported the sighting.
  • Patched: The vulnerability was observed as successfully patched by the user who reported the sighting.
  • Not exploited: The vulnerability was not observed as exploited by the user who reported the sighting.
  • Not confirmed: The user expressed doubt about the validity of the vulnerability.
  • Not patched: The vulnerability was not observed as successfully patched by the user who reported the sighting.

Loading…

Detection rules are retrieved from Rulezet.

Loading…

Loading…

Loading…