{"answers":{"affected":"2 open source packages ship an affected version, including SIPSorcery.","exploited":"There is no known exploitation of GHSA-jwjp-4649-v8jp in the wild and no public exploit code.","fix":"Upgrade SIPSorcery to 10.0.14 or later.","what":"GHSA-jwjp-4649-v8jp is a denial of service vulnerability in SIPSorcery, published on 12 Aug 2026. Any signed-in user can exploit it over the network, with no action from the victim."},"fix_prompt":"Check this codebase for GHSA-jwjp-4649-v8jp and fix it if it is affected.\n\nWhat it is: GHSA-jwjp-4649-v8jp is a denial of service vulnerability in SIPSorcery, published on 12 Aug 2026. Any signed-in user can exploit it over the network, with no action from the victim.\nExploitation: There is no known exploitation of GHSA-jwjp-4649-v8jp in the wild and no public exploit code.\n\nAffected packages and fixed versions:\n- SIPSorcery (NuGet): affected all versions; fixed in 10.0.14\n- SIPSorcery (NuGet): affected all versions; fixed in 10.0.14\n\nTask:\n1. Search the dependency manifests and lockfiles (for example package.json, package-lock.json, requirements.txt, poetry.lock, uv.lock, pom.xml, build.gradle, go.mod, Cargo.lock, Gemfile.lock) and any Dockerfiles for the affected packages, including transitive dependencies.\n2. If an affected version is in use, upgrade it to the fixed version for its release line with the project's package manager, so the lockfile is regenerated. Prefer the smallest upgrade that fixes it.\n3. If there is no fix, or the upgrade would break the build, do not guess: explain the risk and the safest workaround instead.\n4. Run the tests and summarise what changed and why.\n5. If nothing in the project is affected, say so and change nothing.\n\nReference: https://insights.sbomify.com/GHSA-jwjp-4649-v8jp/ (Markdown: https://insights.sbomify.com/GHSA-jwjp-4649-v8jp/index.md)","id":"GHSA-jwjp-4649-v8jp","markdown":"https://insights.sbomify.com/GHSA-jwjp-4649-v8jp/index.md","name":"GHSA-jwjp-4649-v8jp","record":{"aliases":[],"analysis":{"component_type":"library","fix_type":"upgrade","impacts":["denial_of_service"],"network_reachable":"yes","non_default_config":false,"product_category":"WebRTC library","requires_auth":"low_privilege","summary":"A remote attacker can crash the SCTP receive thread and terminate all data channels by sending a crafted SACK chunk with invalid block counts.","user_interaction":"not_required","vuln_class":"denial_of_service"},"analysis_generated_by":"qwen3.8-flash-next","assigner":null,"cpe":[],"cvss":{"score":null,"severity":null,"source":null,"vector":null,"version":null},"cwes":[],"description":"## Summary\n`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.\n\n## Root Cause\n`src/SIPSorcery/net/SCTP/Chunks/SctpSackChunk.cs`:\n- `ushort numGapAckBlocks = NetConvert.ParseUInt16(buffer, startPosn + 8);` (:141)\n- `ushort numDuplicateTSNs = NetConvert.ParseUInt16(buffer, startPosn + 10);` (:142)\n- 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`).\n`SctpPacket.ParseChunks` (SctpPacket.cs:195-203) only validates `chunkLength \u003e= 4` and `posn+chunkLength \u003c= length`; the counts inside the value are never checked. `RTCSctpTransport.DoReceive` calls `SctpPacket.Parse(recvBuffer, 0, bytesRead)` on a reused `recvBuffer = new byte[262144]`.\n\n## Impact\n`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).\n\n## Proof of Concept\nA 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`.\n\n## Attack Chain\n1. 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.\n2. 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\u003e=4` and `posn+chunkLength\u003c=length` (SctpPacket.cs:195-203). Bypass: `chunkLength=16` is well-formed; the counts are never validated.\n3. 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.\n4. 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.\n\n## Bypass Evidence\n- Unchecked counts at SctpSackChunk.cs:141-142; loops at :146,:154.\n- `NetConvert.ParseUInt16` unchecked indexing (NetConvert.cs:30).\n- `ParseChunks` validates only `chunkLength` (SctpPacket.cs:195-203).\n- OOB math: `28 + 65535*4 = 262168 \u003e 262144`; buffer is 262144 (`DEFAULT_ADVERTISED_RECEIVE_WINDOW`, SctpAssociation.cs:62). `numGapAckBlocks` alone suffices — the dup-TSN loop is not needed.\n- `DoReceive` catch split: recoverable `catch(ApplicationException)` at :345 (`continue`) vs generic `catch(Exception)` at :356 (`break`); `_receiveThread` started once at :176.\n\n## Affected Versions\n`nuget:SIPSorcery \u003c= 10.0.13` (verified present on release tag v10.0.13 and HEAD da944543).\n\n## Dedup\nNOT 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.\n\n## Suggested Fix\nValidate `startPosn + FIXED_PARAMETERS_LENGTH + numGapAckBlocks*4 + numDuplicateTSNs*4 \u003c= posn + chunkLen` before the loops, and/or make `NetConvert.Parse*` bounds-checked, and/or treat `IndexOutOfRangeException`/`ArgumentException` as recoverable in `DoReceive`.\n\n---\nReported by **zx (Jace)** — GitHub: @manus-use","ecosystems":["NuGet"],"exploits":{"exploitdb":null,"first_seen":null,"github_poc":null,"max_poc_stars":null,"metasploit":null,"nuclei":null,"refs":[],"tier":null},"has_fix":true,"headline":"SIPSorcery vulnerable to Denial of Service via out-of-bounds read in SCTP SACK chunk parsing","id":"GHSA-jwjp-4649-v8jp","indexable":true,"kev":null,"kind":"advisory","links":{"ecosystem":"NuGet","product":null,"products":[],"type":"denial_of_service","year":"2026"},"n_packages":2,"n_references":null,"packages":[{"ecosystem":"NuGet","fixed":["10.0.14"],"introduced":["0"],"last_affected":[],"package":"SIPSorcery","purl":null,"source":"GHSA-jwjp-4649-v8jp"},{"ecosystem":"NuGet","fixed":["10.0.14"],"introduced":["0"],"last_affected":[],"package":"SIPSorcery","purl":"pkg:nuget/SIPSorcery","source":"GHSA-jwjp-4649-v8jp"}],"products":null,"published":"2026-08-12","related":[],"sources":[{"class":"attribution","licence":"CC BY 4.0","name":"GitHub Advisory Database","prefix":"GHSA"}],"ssvc":{"automatable":null,"exploitation":null,"technical_impact":null},"state":null,"updated":null,"vendors":null},"summary":"A remote attacker can crash the SCTP receive thread and terminate all data channels by sending a crafted SACK chunk with invalid block counts.","url":"https://insights.sbomify.com/GHSA-jwjp-4649-v8jp/"}