SIPSorcery: Unbounded SCTP SACK gap/duplicate counts cause out-of-bounds read that kills the data-channel receive thread (DoS)
Affects SIPSorcery builds before 10.0.14 that use WebRTC data channels, where a negotiated peer can send a crafted SCTP packet. Fixed in 10.0.14.
Written by anthropic/claude-haiku-5.5 from the sources below. Verify against them.
- Exploited
- No known exploitation
- Fix
- Fixed in 10.0.14
- Who is exposed
- Not reported
Do first: Upgrade to a fixed version: 10.0.14.
- Last modified
- A 0-100 score for how much a CVE matters across the industry: exploitation, exposure, how widely the software is used, severity and whether a fix exists.What do these mean? →
- 25/100 · provisional
- How many real-world setups can hit the bug, from the vendor's advisory and CISA data. It does not know your setup.What do these mean? →
- Unclear
- Whether working attack code is public (Exploit-DB, Metasploit, Nuclei or GitHub). Public code makes attacks easier.What do these mean? →
- None on Exploit-DB, Metasploit or GitHub
Summary
SIPSorcery, a WebRTC, SIP, and VoIP library for C# and .NET, is vulnerable to a denial-of-service flaw in its SCTP data-channel handling. A remote peer can send a malformed SCTP SACK chunk without logging in, which crashes the receive thread and permanently shuts down the SCTP association and all of its data channels.
Read the original description
SIPSorcery is a WebRTC, SIP, and VoIP library for C# and .NET. Prior to 10.0.14, SctpSackChunk.ParseChunk reads the numGapAckBlocks and numDuplicateTSNs fields from an attacker-controlled SCTP SACK chunk without checking that the corresponding entries fit the declared chunk length. A negotiated WebRTC peer can send a checksum-valid malformed SACK chunk that drives the parser beyond the 262144-byte receive buffer. The resulting IndexOutOfRangeException bypasses the recoverable ApplicationException handler in RTCSctpTransport.DoReceive, causing the generic handler to exit the dedicated receive loop and permanently terminate the SCTP association and all data channels. This issue is fixed in 10.0.14.
cve.now Index
- Exploitation?/40Unknown. No CISA SSVC exploitation rating yet
- Exposure17/25No login or user action needed, reachable over the network without a login · Unknown: Advisories don't say whether default setups are affected
- Reach?/20Unknown. No tracked technology or package matched
- Severity7.5/10CVSS 7.5
- No patch0/5No signal
What would change the score
- Would score about 70 if added to CISA KEV
- Would score about 65 if CISA's SSVC rates exploitation active
- Would score about 30 if advisories confirm default setups are exposed
What to do
Upgrade to a fixed version: 10.0.14.
Timeline
- CVE published
- First seen by cve.now
Affected versions
- sipsorcery-org sipsorcery
fixed in 10.0.14
Evidence 3
- Advisory
- Repository
- Repository
Corrections
None so far.
Something wrong on this page? Report an error. Every fix is listed here.
Questions about CVE-2026-123805
Is CVE-2026-123805 being exploited?
It is not in CISA's Known Exploited Vulnerabilities catalog, and CISA's SSVC assessment does not mark exploitation as active. That does not mean it has not been attacked: vendors and researchers can report attacks before CISA lists them. No public exploit code is tracked.Source: cve.now feed data
What does this mean?
A single crafted SCTP SACK chunk with unbounded gap or duplicate counts causes an out-of-bounds read. That read terminates the SCTP receive thread, which permanently kills the SCTP association and all of its data channels, resulting in denial of service.Source: github.com
Which versions are affected by CVE-2026-123805?
sipsorcery: before 10.0.14.Source: cve.now feed data
Am I affected, and how do I check?
Versions of SIPSorcery before 10.0.14 are affected, and the issue concerns WebRTC data channels that have been negotiated with a peer after DTLS setup. To check your version, look at the sipsorcery package version in your project dependencies, for example in your .csproj or packages lock file.Source: github.com
How do I fix CVE-2026-123805?
Upgrade SIPSorcery to version 10.0.14 or later. No workaround is listed in the facts for this issue.Source: github.com