How severe is GHSA-jwjp-4649-v8jp?

GHSA-jwjp-4649-v8jp has a CVSS score of 7.5/10, rated HIGH. Immediate patching is strongly recommended.

Which packages are affected by GHSA-jwjp-4649-v8jp?

GHSA-jwjp-4649-v8jp affects the following packages: SIPSorcery (NuGet). Ecosystems affected: NuGet.

How do I fix GHSA-jwjp-4649-v8jp?

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

How do I detect GHSA-jwjp-4649-v8jp 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-jwjp-4649-v8jp 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-jwjp-4649-v8jp?

O3 pinpoints whether GHSA-jwjp-4649-v8jp 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-jwjp-4649-v8jp actively exploited in the wild?

No public exploit code has been indexed for GHSA-jwjp-4649-v8jp 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-jwjp-4649-v8jp published, and has it been updated?

GHSA-jwjp-4649-v8jp 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-jwjp-4649-v8jp

HIGHFix: sipsorcery-org/sipsorcery@a246655

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

SIPSorcery vulnerable to Denial of Service via out-of-bounds read in SCTP SACK chunk parsing

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

SctpSackChunk.ParseChunk reads the numGapAckBlocks and numDuplicateTSNs fields (each up to 65535) directly from an attacker-controlled SCTP SACK chunk and loops that many times reading 4 bytes per iteration, with no validation of the counts against the chunk length or the receive buffer. A single crafted SACK chunk from a negotiated WebRTC peer forces reads past the end of the 262144-byte receive buffer, raising IndexOutOfRangeException, which is not caught by the recoverable handler and terminates the dedicated SCTP receive thread — permanently killing the SCTP association and all data channels.

Root Cause

src/SIPSorcery/net/SCTP/Chunks/SctpSackChunk.cs:

ushort numGapAckBlocks = NetConvert.ParseUInt16(buffer, startPosn + 8); (:141)
ushort numDuplicateTSNs = NetConvert.ParseUInt16(buffer, startPosn + 10); (:142)
gap-ack loop (:146) and duplicate-TSN loop (:154) index the buffer via NetConvert.ParseUInt16/32 (buffer[posn], no bounds check — sys/Net/NetConvert.cs:30,41). SctpPacket.ParseChunks (SctpPacket.cs:195-203) only validates chunkLength >= 4 and posn+chunkLength <= length; the counts inside the value are never checked. RTCSctpTransport.DoReceive calls SctpPacket.Parse(recvBuffer, 0, bytesRead) on a reused recvBuffer = new byte[262144].

Impact

IndexOutOfRangeException is a SystemException, not ApplicationException, so the recoverable catch (ApplicationException) { … continue; } at RTCSctpTransport.cs:345 is skipped and control falls to the generic catch (Exception) { … break; } at :356. The break exits the receive loop, DoReceive returns, and the dedicated _receiveThread = new Thread(DoReceive) (:173, started once) exits with no restart → the SCTP association and every data channel are permanently dead (denial of service).

Proof of Concept

A negotiated WebRTC peer (post-DTLS) sends a checksum-valid SCTP packet: 12-byte common header + a SACK chunk (type 3) with chunkLength=16, numGapAckBlocks=0xFFFF, numDuplicateTSNs=0xFFFF. CRC32C is attacker-computable. The gap-ack loop reaches buffer[262144] on a 262144-byte array (valid indices 0..262143) → IndexOutOfRangeException.

Attack Chain

Entry: post-DTLS negotiated peer sends a checksum-valid SCTP packet with a SACK chunk (chunkLength=16, numGapAckBlocks=0xFFFF). Guard: VerifyChecksum (CRC32C). Bypass: CRC32C is computable by the sender.
Processing: DoReceive (RTCSctpTransport.cs:286) reads into reused recvBuffer (262144 bytes, :280) → SctpPacket.Parse(recvBuffer, 0, bytesRead) (:302) → ParseChunks → SACK dispatch (SctpChunk.Parse :340-341) → SctpSackChunk.ParseChunk. Guard: ParseChunks checks only chunkLength>=4 and posn+chunkLength<=length (SctpPacket.cs:195-203). Bypass: chunkLength=16 is well-formed; the counts are never validated.
Sink: gap-ack loop (SctpSackChunk.cs:146) calls NetConvert.ParseUInt16(buffer, reportPosn) with reportPosn starting at startPosn(16)+FIXED_PARAMETERS(12)=28, climbing +4 each iteration. Guard: none on the count. Bypass: NetConvert.ParseUInt16 (NetConvert.cs:30) indexes buffer[posn] unchecked.
Impact: at iteration 65529, reportPosn = 28 + 65529*4 = 262144 → buffer[262144] → IndexOutOfRangeException → generic catch at RTCSctpTransport.cs:356 → break → receive thread exits, no restart → association permanently dead.

Bypass Evidence

Unchecked counts at SctpSackChunk.cs:141-142; loops at :146,:154.
NetConvert.ParseUInt16 unchecked indexing (NetConvert.cs:30).
ParseChunks validates only chunkLength (SctpPacket.cs:195-203).
OOB math: 28 + 65535*4 = 262168 > 262144; buffer is 262144 (DEFAULT_ADVERTISED_RECEIVE_WINDOW, SctpAssociation.cs:62). numGapAckBlocks alone suffices — the dup-TSN loop is not needed.
DoReceive catch split: recoverable catch(ApplicationException) at :345 (continue) vs generic catch(Exception) at :356 (break); _receiveThread started once at :176.

Affected Versions

nuget:SIPSorcery <= 10.0.13 (verified present on release tag v10.0.13 and HEAD da944543).

Dedup

NOT a duplicate of GHSA-qmvg-569h-hqrh — that fix (fe5a1fa) touched only SctpPacket.cs (the chunk-cursor zero-length infinite loop, CWE-835). This is a distinct out-of-bounds read (CWE-125) in SctpSackChunk count loops, untouched by that fix.

Suggested Fix

Validate startPosn + FIXED_PARAMETERS_LENGTH + numGapAckBlocks*4 + numDuplicateTSNs*4 <= posn + chunkLen before the loops, and/or make NetConvert.Parse* bounds-checked, and/or treat IndexOutOfRangeException/ArgumentException as recoverable in DoReceive.

Reported by zx (Jace) — GitHub: @manus-use

Affected Packages

1 total 1 fixed

Ecosystem	Package	Vulnerable range	Fix
.NETNuGet	`SIPSorcery`	all versions	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-jwjp-4649-v8jp 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-jwjp-4649-v8jp 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-jwjp-4649-v8jp. Runtime protection reduces exposure until a permanent patch is applied and verified — it complements patching, it doesn't replace it.

Frequently Asked Questions

## Summary `SctpSackChunk.ParseChunk` reads the `numGapAckBlocks` and `numDuplicateTSNs` fields (each up to 65535) directly from an attacker-controlled SCTP SACK chunk and loops that many times reading 4 bytes per iteration, with no validation of the counts against the chunk length or the receive buffer. A single crafted SACK chunk from a negotiated WebRTC peer forces reads past the end of the 262144-byte receive buffer, raising `IndexOutOfRangeException`, which is not caught by the recoverable handler and terminates the dedicated SCTP receive thread — permanently killing the SCTP association

O3 Security · Impact-Aware SCA

Is GHSA-jwjp-4649-v8jp in your dependencies?

O3 detects GHSA-jwjp-4649-v8jp 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