<?xml version='1.0' encoding='UTF-8'?>
<?xml-stylesheet href="/static/style.xsl" type="text/xsl"?>
<rss xmlns:atom="http://www.w3.org/2005/Atom" xmlns:content="http://purl.org/rss/1.0/modules/content/" version="2.0">
  <channel>
    <title>Most recent entries from all</title>
    <link>https://vulnerability.circl.lu</link>
    <description>Contains only the most 10 recent entries.</description>
    <docs>http://www.rssboard.org/rss-specification</docs>
    <generator>python-feedgen</generator>
    <language>en</language>
    <lastBuildDate>Thu, 01 Oct 2026 11:42:20 +0000</lastBuildDate>
    <item>
      <title>fkie_cve-2026-58268</title>
      <link>https://vulnerability.circl.lu/vuln/fkie_cve-2026-58268</link>
      <description>&lt;p&gt;SIPGO is a library for writing SIP services in the GO language. Prior to 1.4.1, ParserStream.parseSingle in sip/parser_stream.go allocates a SIP body buffer from the client-controlled Content-Length header before ParseMaxMessageLength is enforced. An unauthenticated peer can send a stream-transport message over TCP, TLS, WS, or WSS with an oversized declared length, causing excessive memory allocation and denial of service before the body is read. This issue is fixed in version 1.4.1.&lt;/p&gt;</description>
      <content:encoded>&lt;p&gt;SIPGO is a library for writing SIP services in the GO language. Prior to 1.4.1, ParserStream.parseSingle in sip/parser_stream.go allocates a SIP body buffer from the client-controlled Content-Length header before ParseMaxMessageLength is enforced. An unauthenticated peer can send a stream-transport message over TCP, TLS, WS, or WSS with an oversized declared length, causing excessive memory allocation and denial of service before the body is read. This issue is fixed in version 1.4.1.&lt;/p&gt;</content:encoded>
      <guid isPermaLink="false">https://vulnerability.circl.lu/vuln/fkie_cve-2026-58268</guid>
    </item>
    <item>
      <title>GHSA-pg59-5vwg-4jxq — SIPGO: DoS via unvalidated Content-Length in the stream parser</title>
      <link>https://vulnerability.circl.lu/vuln/ghsa-pg59-5vwg-4jxq</link>
      <description>&lt;p&gt;&lt;strong&gt;Affected:&lt;/strong&gt; Go: github.com/emiago/sipgo&lt;/p&gt;
&lt;p&gt;### Summary&lt;/p&gt;
&lt;p&gt;The stream parser allocates the SIP body buffer from the `Content-Length` header before validating its size, which can lead to an unauthenticated DoS.&lt;/p&gt;
&lt;p&gt;### Details&lt;/p&gt;
&lt;p&gt;`ParserStream.parseSingle` allocates the body buffer from the declared `Content-Length` with no size check (https://github.com/emiago/sipgo/blob/v1.4.0/sip/parser_stream.go#L195):&lt;/p&gt;
&lt;p&gt;```go
body := make([]byte, contentLength)   // contentLength is client-controlled, up to 2^32-1 (uint32)
```&lt;/p&gt;
&lt;p&gt;The `ParseMaxMessageLength` (65535) check is in the caller `ParseNext` (https://github.com/emiago/sipgo/blob/v1.4.0/sip/parser_stream.go#L132), and only runs after `parseSingle` has already allocated the buffer.&lt;/p&gt;
&lt;p&gt;### PoC&lt;/p&gt;
&lt;p&gt;Tested on emiago/sipgo v1.4.0 (latest).&lt;/p&gt;
&lt;p&gt;Send a single message with a large `Content-Length` and no body to a SIP server:&lt;/p&gt;
&lt;p&gt;```
INVITE sip:victim@example.com SIP/2.0
Via: SIP/2.0/TCP attacker.example;branch=z9hG4bK1
From: &amp;lt;sip:attacker@attacker.example&amp;gt;;tag=1
To: &amp;lt;sip:victim@example.com&amp;gt;
Call-ID: 1@attacker.example
CSeq: 1 INVITE
Content-Length: 4000000000                     // &amp;lt;- a large Content-Length&lt;/p&gt;
&lt;p&gt;```&lt;/p&gt;
&lt;p&gt;### Suggested Fix&lt;/p&gt;
&lt;p&gt;Validate `contentLength` against `ParseMaxMessageLength` before the allocation.&lt;/p&gt;
&lt;p&gt;### Impact&lt;/p&gt;
&lt;p&gt;Unauthenticated DoS. Any service using `sipgo` with a stream transport (TCP/TLS/WS/WSS) can be forced to run out of memory.&lt;/p&gt;</description>
      <content:encoded>&lt;p&gt;&lt;strong&gt;Affected:&lt;/strong&gt; Go: github.com/emiago/sipgo&lt;/p&gt;
&lt;p&gt;### Summary&lt;/p&gt;
&lt;p&gt;The stream parser allocates the SIP body buffer from the `Content-Length` header before validating its size, which can lead to an unauthenticated DoS.&lt;/p&gt;
&lt;p&gt;### Details&lt;/p&gt;
&lt;p&gt;`ParserStream.parseSingle` allocates the body buffer from the declared `Content-Length` with no size check (https://github.com/emiago/sipgo/blob/v1.4.0/sip/parser_stream.go#L195):&lt;/p&gt;
&lt;p&gt;```go
body := make([]byte, contentLength)   // contentLength is client-controlled, up to 2^32-1 (uint32)
```&lt;/p&gt;
&lt;p&gt;The `ParseMaxMessageLength` (65535) check is in the caller `ParseNext` (https://github.com/emiago/sipgo/blob/v1.4.0/sip/parser_stream.go#L132), and only runs after `parseSingle` has already allocated the buffer.&lt;/p&gt;
&lt;p&gt;### PoC&lt;/p&gt;
&lt;p&gt;Tested on emiago/sipgo v1.4.0 (latest).&lt;/p&gt;
&lt;p&gt;Send a single message with a large `Content-Length` and no body to a SIP server:&lt;/p&gt;
&lt;p&gt;```
INVITE sip:victim@example.com SIP/2.0
Via: SIP/2.0/TCP attacker.example;branch=z9hG4bK1
From: &amp;lt;sip:attacker@attacker.example&amp;gt;;tag=1
To: &amp;lt;sip:victim@example.com&amp;gt;
Call-ID: 1@attacker.example
CSeq: 1 INVITE
Content-Length: 4000000000                     // &amp;lt;- a large Content-Length&lt;/p&gt;
&lt;p&gt;```&lt;/p&gt;
&lt;p&gt;### Suggested Fix&lt;/p&gt;
&lt;p&gt;Validate `contentLength` against `ParseMaxMessageLength` before the allocation.&lt;/p&gt;
&lt;p&gt;### Impact&lt;/p&gt;
&lt;p&gt;Unauthenticated DoS. Any service using `sipgo` with a stream transport (TCP/TLS/WS/WSS) can be forced to run out of memory.&lt;/p&gt;</content:encoded>
      <guid isPermaLink="false">https://vulnerability.circl.lu/vuln/ghsa-pg59-5vwg-4jxq</guid>
    </item>
  </channel>
</rss>
