How severe is GHSA-pfvm-w89x-94jw?

GHSA-pfvm-w89x-94jw has a CVSS score of 7.5/10, rated HIGH. Immediate patching is strongly recommended.

Which packages are affected by GHSA-pfvm-w89x-94jw?

GHSA-pfvm-w89x-94jw affects the following packages: SIPSorcery (NuGet). Ecosystems affected: NuGet.

How do I fix GHSA-pfvm-w89x-94jw?

Update SIPSorcery to 10.0.14 or later, then make sure no transitive (indirect) dependency still pins the vulnerable range — O3 confirms GHSA-pfvm-w89x-94jw is resolved across your whole dependency graph.

How do I detect GHSA-pfvm-w89x-94jw in my NuGet dependencies?

Scan your dependency tree (package-lock.json, pnpm-lock.yaml, requirements.txt, go.sum, etc.) for SIPSorcery. O3's reachability analysis confirms whether the vulnerable code path is actually invoked in your application, so you act on real exposure instead of every transitive match.

How do I mitigate GHSA-pfvm-w89x-94jw if there is no patch (or I can't update yet)?

If you can't upgrade right away: gate or disable the affected feature, validate untrusted input at the boundary, and avoid passing attacker-controlled data into the vulnerable path. O3's runtime protection blocks exploitation in production as an interim safeguard until the upgrade lands.

How does O3 Security protect against GHSA-pfvm-w89x-94jw?

O3 pinpoints whether GHSA-pfvm-w89x-94jw is reachable in your code and exactly where to fix it, then blocks exploitation in production at runtime until the patched version is deployed.

Is GHSA-pfvm-w89x-94jw actively exploited in the wild?

No public exploit code has been indexed for GHSA-pfvm-w89x-94jw yet. This does not mean the vulnerability cannot be exploited — absence of public exploits does not imply safety. Apply the recommended fix and use O3 Security to monitor your exposure.

When was GHSA-pfvm-w89x-94jw published, and has it been updated?

GHSA-pfvm-w89x-94jw was published on August 12, 2026 and was last updated on August 12, 2026. Advisory data evolves as severity scores, affected ranges, and exploit intelligence are revised — always check the latest version of the advisory before acting.

.NET

.NET NuGet

Not in CISA KEV

HIGH severity

GHSA-pfvm-w89x-94jw

HIGHFix: sipsorcery-org/sipsorcery@ccb0b5a

GHSA-pfvm-w89x-94jw is a high-severity (CVSS 7.5) vulnerability in SIPSorcery. O3 Security confirms whether GHSA-pfvm-w89x-94jw is actually reachable in your code before you act, and blocks exploitation at runtime until you patch.

SIPSorcery: Malformed UDP datagram crashes TurnServer receive loop with no restart, disabling TURN UDP relay for all clients (DoS)

Published

Aug 12, 2026

Updated

Aug 12, 2026

Affected

1 pkg

Patched

1 / 1

Exploits

None indexed

Exploitation data as of Aug 12, 2026 · OSV.dev, FIRST.org (EPSS)

Real-World Exposure

1 pkg affected

.NETSIPSorcery

Real-time download stats are indexed for npm and PyPI packages. This vulnerability affects NuGet packages — download data is not available via public APIs for these ecosystems.

Description

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

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).
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.
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

Affected Packages

1 total 1 fixed

Ecosystem	Package	Vulnerable range	Fix
.NETNuGet	`SIPSorcery`	≥ 10.0.5&&< 10.0.14	10.0.14

Detection & mitigation playbook

Open-source dependency

Detect
Scan your dependency tree (package-lock.json, pnpm-lock.yaml, requirements.txt, go.sum, etc.) for SIPSorcery. O3's reachability analysis confirms whether the vulnerable code path is actually invoked in your application, so you act on real exposure instead of every transitive match.
Fix
Update SIPSorcery to 10.0.14 or later, then make sure no transitive (indirect) dependency still pins the vulnerable range — O3 confirms GHSA-pfvm-w89x-94jw is resolved across your whole dependency graph.
Workarounds
If you can't upgrade right away: gate or disable the affected feature, validate untrusted input at the boundary, and avoid passing attacker-controlled data into the vulnerable path. O3's runtime protection blocks exploitation in production as an interim safeguard until the upgrade lands.
How O3 protects you
O3 pinpoints whether GHSA-pfvm-w89x-94jw is reachable in your code and exactly where to fix it, then blocks exploitation in production at runtime until the patched version is deployed.

Tailored to GHSA-pfvm-w89x-94jw. Runtime protection reduces exposure until a permanent patch is applied and verified — it complements patching, it doesn't replace it.

Frequently Asked Questions

## 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 on

O3 Security · Impact-Aware SCA

Is GHSA-pfvm-w89x-94jw in your dependencies?

O3 detects GHSA-pfvm-w89x-94jw across NuGet dependencies and uses function-level reachability to confirm whether the vulnerable code path is actually reachable — not just present. No false positives.

Scan my dependencies How O3 SCA works