<?xml version='1.0' encoding='UTF-8'?>
<?xml-stylesheet href="/static/style.xsl" type="text/xsl"?>
<feed xmlns="http://www.w3.org/2005/Atom" xml:lang="en">
  <id>https://db.gcve.eu/rss/recent/all/10</id>
  <title>Most recent entries from all</title>
  <updated>2026-11-15T23:46:28.345814+00:00</updated>
  <author>
    <name>Vulnerability-Lookup</name>
    <email>info@gcve.eu</email>
  </author>
  <link href="https://db.gcve.eu" rel="alternate"/>
  <generator uri="https://lkiesow.github.io/python-feedgen" version="1.0.0">python-feedgen</generator>
  <subtitle>Contains only the most 10 recent entries.</subtitle>
  <entry>
    <id>https://db.gcve.eu/vuln/cve-2026-123805</id>
    <title>CVE-2026-123805 — SIPSorcery: Unbounded SCTP SACK gap/duplicate counts cause out-of-bounds read that kills the data-channel receive threa…</title>
    <updated>2026-11-15T23:46:28.349002+00:00</updated>
    <content type="xhtml">
      <div xmlns="http://www.w3.org/1999/xhtml"><p><strong>Affected:</strong> sipsorcery-org sipsorcery</p>
<p>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.</p></div>
    </content>
    <link href="https://db.gcve.eu/vuln/cve-2026-123805"/>
  </entry>
</feed>
