<?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>Sun, 11 Oct 2026 04:43:28 +0000</lastBuildDate>
    <item>
      <title>CVE-2026-32952 — go-ntlmssp NTLM challenges can panic on malformed payloads</title>
      <link>https://vulnerability.circl.lu/vuln/cve-2026-32952</link>
      <description>&lt;p&gt;&lt;strong&gt;Affected:&lt;/strong&gt; Azure go-ntlmssp&lt;/p&gt;
&lt;p&gt;go-ntlmssp is a Go package that provides NTLM/Negotiate authentication over HTTP. Prior to version 0.1.1, a malicious NTLM challenge message can causes an slice out of bounds panic, which can crash any Go process using `ntlmssp.Negotiator` as an HTTP transport. Version 0.1.1 patches the issue.&lt;/p&gt;</description>
      <content:encoded>&lt;p&gt;&lt;strong&gt;Affected:&lt;/strong&gt; Azure go-ntlmssp&lt;/p&gt;
&lt;p&gt;go-ntlmssp is a Go package that provides NTLM/Negotiate authentication over HTTP. Prior to version 0.1.1, a malicious NTLM challenge message can causes an slice out of bounds panic, which can crash any Go process using `ntlmssp.Negotiator` as an HTTP transport. Version 0.1.1 patches the issue.&lt;/p&gt;</content:encoded>
      <guid isPermaLink="false">https://vulnerability.circl.lu/vuln/cve-2026-32952</guid>
    </item>
    <item>
      <title>GHSA-mh2q-q3fh-2475 — OpenTelemetry-Go: multi-value `baggage` header extraction causes excessive allocations (remote dos amplification)</title>
      <link>https://vulnerability.circl.lu/vuln/ghsa-mh2q-q3fh-2475</link>
      <description>&lt;p&gt;&lt;strong&gt;Affected:&lt;/strong&gt; Go: go.opentelemetry.io/otel&lt;/p&gt;
&lt;p&gt;multi-value `baggage:` header extraction parses each header field-value independently and aggregates members across values. this allows an attacker to amplify cpu and allocations by sending many `baggage:` header lines, even when each individual value is within the 8192-byte per-value parse limit.&lt;/p&gt;
&lt;p&gt;## severity&lt;/p&gt;
&lt;p&gt;HIGH (availability / remote request amplification)&lt;/p&gt;
&lt;p&gt;## relevant links&lt;/p&gt;
&lt;p&gt;- repository: https://github.com/open-telemetry/opentelemetry-go
- pinned callsite: https://github.com/open-telemetry/opentelemetry-go/blob/1ee4a4126dbdd1bc79e9fae072fa488beffac52a/propagation/baggage.go#L58&lt;/p&gt;
&lt;p&gt;## vulnerability details&lt;/p&gt;
&lt;p&gt;**pins:** open-telemetry/opentelemetry-go@1ee4a4126dbdd1bc79e9fae072fa488beffac52a
**as-of:** 2026-02-04
**policy:** direct (no program scope provided)&lt;/p&gt;
&lt;p&gt;**callsite:** propagation/baggage.go:58 (`extractMultiBaggage`)
**attacker control:** inbound HTTP request headers (many `baggage` field-values) → `propagation.HeaderCarrier.Values(&amp;#34;baggage&amp;#34;)` → repeated `baggage.Parse` + member aggregation&lt;/p&gt;
&lt;p&gt;### root cause&lt;/p&gt;
&lt;p&gt;`extractMultiBaggage` iterates over all `baggage` header field-values and parses each one independently, then appends members into a shared slice. the 8192-byte parsing cap applies per header value, but the multi-value path repeats that work once per header line (bounded only by the server/proxy header byte limit).&lt;/p&gt;
&lt;p&gt;### impact&lt;/p&gt;
&lt;p&gt;in a default `net/http` configuration (max header bytes 1mb), a single request with many `baggage:` header field-values can cause large per…&lt;/p&gt;</description>
      <content:encoded>&lt;p&gt;&lt;strong&gt;Affected:&lt;/strong&gt; Go: go.opentelemetry.io/otel&lt;/p&gt;
&lt;p&gt;multi-value `baggage:` header extraction parses each header field-value independently and aggregates members across values. this allows an attacker to amplify cpu and allocations by sending many `baggage:` header lines, even when each individual value is within the 8192-byte per-value parse limit.&lt;/p&gt;
&lt;p&gt;## severity&lt;/p&gt;
&lt;p&gt;HIGH (availability / remote request amplification)&lt;/p&gt;
&lt;p&gt;## relevant links&lt;/p&gt;
&lt;p&gt;- repository: https://github.com/open-telemetry/opentelemetry-go
- pinned callsite: https://github.com/open-telemetry/opentelemetry-go/blob/1ee4a4126dbdd1bc79e9fae072fa488beffac52a/propagation/baggage.go#L58&lt;/p&gt;
&lt;p&gt;## vulnerability details&lt;/p&gt;
&lt;p&gt;**pins:** open-telemetry/opentelemetry-go@1ee4a4126dbdd1bc79e9fae072fa488beffac52a
**as-of:** 2026-02-04
**policy:** direct (no program scope provided)&lt;/p&gt;
&lt;p&gt;**callsite:** propagation/baggage.go:58 (`extractMultiBaggage`)
**attacker control:** inbound HTTP request headers (many `baggage` field-values) → `propagation.HeaderCarrier.Values(&amp;#34;baggage&amp;#34;)` → repeated `baggage.Parse` + member aggregation&lt;/p&gt;
&lt;p&gt;### root cause&lt;/p&gt;
&lt;p&gt;`extractMultiBaggage` iterates over all `baggage` header field-values and parses each one independently, then appends members into a shared slice. the 8192-byte parsing cap applies per header value, but the multi-value path repeats that work once per header line (bounded only by the server/proxy header byte limit).&lt;/p&gt;
&lt;p&gt;### impact&lt;/p&gt;
&lt;p&gt;in a default `net/http` configuration (max header bytes 1mb), a single request with many `baggage:` header field-values can cause large per…&lt;/p&gt;</content:encoded>
      <guid isPermaLink="false">https://vulnerability.circl.lu/vuln/ghsa-mh2q-q3fh-2475</guid>
    </item>
  </channel>
</rss>
