Vulnerabilities in pkg:nuget/SIPSorcery

PACKAGE
Advisory Summary

GHSA-pfvm-w89x-94jw is a HIGH (CVSS 7.5) denial of service vulnerability (CWE-755: Improper Handling of Exceptional Conditions) affecting SIPSorcery libraries in the NuGet ecosystem. The issue involves malformed udp datagram crashes turnserver receive loop with no restart, disabling turn udp relay for all clients (dos). Remediation is available by upgrading affected packages to version 10.0.14.

3 Known Advisory Record(s)
Package Vulnerability Intelligence

pkg:nuget/SIPSorcery

3 Known Advisory Record(s)

Vulnerability advisories affecting package pkg:nuget/SIPSorcery. Select an advisory below to view technical details or fixes.

Advisory ID CVE / NVD Severity Summary
GHSA-pfvm-w89x-94jw - HIGH SIPSorcery: Malformed UDP datagram crashes TurnServer receive loop with no restart, disabling TURN UDP relay for all clients (DoS)
GHSA-jwjp-4649-v8jp - HIGH SIPSorcery vulnerable to Denial of Service via out-of-bounds read in SCTP SACK chunk parsing
GHSA-28gm-jrmw-xx93 CVE-2026-54632 HIGH SIPSorcery: Malformed UDP packet on the RTP/ICE socket can remotely terminate a media session (DoS)

GHSA-pfvm-w89x-94jw at a Glance

CVE Identifier N/A
GHSA Identifier GHSA-pfvm-w89x-94jw
Severity HIGH
CVSS v3.1 Base Score 7.5
CWE Classification CWE-755: Improper Handling of Exceptional Conditions
Affected Product SIPSorcery
Package Ecosystem NuGet
Published Date
Last Updated

Security Impact

CVSS: 7.5

The security impact metrics below are parsed directly from the CVSS v3.1 vector string (CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H).

Attack Vector Network (AV:N)
Attack Complexity Low (AC:L)
Privileges Required None (PR:N)
User Interaction None (UI:N)
Scope Unchanged (S:U)
Confidentiality None (C:N)
Integrity None (I:N)
Availability High (A:H)

How to Fix GHSA-pfvm-w89x-94jw

To remediate this vulnerability, upgrade all affected SIPSorcery dependencies to a patched release. Both direct and transitive dependencies should be checked, as frameworks or security libraries may pull in vulnerable versions transitively.

SIPSorcery fixed: 10.0.14
Upgrade SIPSorcery to 10.0.14
Verify Direct and Transitive Dependencies

Run the following command in your project directory to verify that all resolved dependencies use the patched release:

inspect dependencies for SIPSorcery

How to Check if You Are Affected

To determine whether your application is affected by GHSA-pfvm-w89x-94jw, inspect your project dependencies for SIPSorcery:

inspect dependencies for SIPSorcery

Analyze the terminal output to locate any version of SIPSorcery in your dependency tree. If any resolved version matches the vulnerable ranges listed in the table below (for example, versions earlier than 10.0.14), your application is affected.

Note: Verify declared build manifests and deployed runtime container environments.

Technical Details

Vulnerability Mechanism & Technical Analysis

This vulnerability is classified under CWE-755: Improper Handling of Exceptional Conditions, where the product does not handle or incorrectly handles an exceptional condition. In SIPSorcery, software state validation or input boundaries are circumvented during processing. Review the official source advisory statement below for specific affected components, classes, and reproduction details.

Source Advisory Statement

## 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 → `ParseSTUNMessage` → `ParseSTUNHeader` 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.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. 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

GHSA-pfvm-w89x-94jw Affected SIPSorcery Versions

1 component(s)
Fixed Versions:
10.0.14
Product / Package Ecosystem Affected Versions Fixed Version
SIPSorcery
NuGet
≥ 10.0.5
< 10.0.14
10.0.14

References

Frequently Asked Questions

What is GHSA-pfvm-w89x-94jw?
GHSA-pfvm-w89x-94jw is a security vulnerability in SIPSorcery involving Malformed UDP datagram crashes TurnServer receive loop with no restart, disabling TURN UDP relay for all clients (DoS) under CWE-755: Improper Handling of Exceptional Conditions.
Which SIPSorcery versions are affected?
Affected versions include releases prior to 10.0.14 across affected packages: SIPSorcery.
What version fixes GHSA-pfvm-w89x-94jw?
Upgrading to 10.0.14 (or the latest patched release for your respective branch) resolves the vulnerability.
Is SIPSorcery affected?
Yes, SIPSorcery is affected in releases prior to 10.0.14. Upgrade your dependency to 10.0.14 or later.
What is the CVSS score of GHSA-pfvm-w89x-94jw?
GHSA-pfvm-w89x-94jw has a CVSS v3.1 base score of 7.5 (HIGH) with vector string CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H.
What CWE is associated with GHSA-pfvm-w89x-94jw?
GHSA-pfvm-w89x-94jw is classified under CWE-755: Improper Handling of Exceptional Conditions (The product does not handle or incorrectly handles an exceptional condition.).
How can I check NuGet dependencies for GHSA-pfvm-w89x-94jw?
Run the dependency tree command: 'inspect dependencies for SIPSorcery'. This command lists direct and transitive dependencies in your build configuration so you can verify if a vulnerable version is resolved.
Machine-readable OSV JSON OSV v1.5 Schema
Normalized schema output
{
  "schema_version" : "1.4.0",
  "id" : "GHSA-pfvm-w89x-94jw",
  "modified" : "2026-08-12T19:31:48Z",
  "published" : "2026-08-12T19:31:48Z",
  "aliases" : [ ],
  "summary" : "SIPSorcery: Malformed UDP datagram crashes TurnServer receive loop with no restart, disabling TURN UDP relay for all clients (DoS)",
  "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–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.\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) — 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` → 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 & 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.\n\n## Attack Chain\n1. 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).\n2. Sink: `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.\n3. 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.\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 → AC:L.\n\n## Affected Versions\n`nuget:SIPSorcery <= 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)** — GitHub: @manus-use",
  "severity" : [ {
    "type" : "CVSS_V3",
    "score" : "CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H"
  } ],
  "affected" : [ {
    "package" : {
      "ecosystem" : "NuGet",
      "name" : "SIPSorcery"
    },
    "ranges" : [ {
      "type" : "ECOSYSTEM",
      "events" : [ {
        "introduced" : "10.0.5"
      }, {
        "fixed" : "10.0.14"
      } ]
    } ],
    "database_specific" : {
      "last_known_affected_version_range" : "<= 10.0.13"
    }
  } ],
  "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"
  } ],
  "database_specific" : {
    "cwe_ids" : [ "CWE-248", "CWE-755" ],
    "severity" : "HIGH",
    "github_reviewed" : true,
    "github_reviewed_at" : "2026-08-12T19:31:48Z",
    "nvd_published_at" : null
  }
}