chore(deps): update module github.com/moby/spdystream to v0.5.1 [security]

[renovate]

This PR contains the following updates:

Package	Change	Age	Confidence
github.com/moby/spdystream	v0.5.0 → v0.5.1

---

SpdyStream: DOS on CRI

CVE-2026-35469 / GHSA-pc3f-x583-g7j2

More information

Details

The SPDY/3 frame parser in spdystream does not validate
attacker-controlled counts and lengths before allocating memory. A
remote peer that can send SPDY frames to a service using spdystream can
cause the process to allocate gigabytes of memory with a small number of
malformed control frames, leading to an out-of-memory crash.
 
Three allocation paths in the receive side are affected:

1. SETTINGS entry count -- The SETTINGS frame reader reads a 32-bit
   numSettings from the payload and allocates a slice of that size
   without checking it against the declared frame length. An attacker
   can set numSettings to a value far exceeding the actual payload,
   triggering a large allocation before any setting data is read.
    
2. Header count -- parseHeaderValueBlock reads a 32-bit
   numHeaders from the decompressed header block and allocates an
   http.Header map of that size with no upper bound.
    
3. Header field size -- Individual header name and value lengths are
   read as 32-bit integers and used directly as allocation sizes with
   no validation.
    
   Because SPDY header blocks are zlib-compressed, a small on-the-wire
   payload can decompress into attacker-controlled bytes that the parser
   interprets as 32-bit counts and lengths. A single crafted frame is
   enough to exhaust process memory.

Impact

 Any program that accepts SPDY connections using spdystream -- directly
or through a dependent library -- is affected. A remote peer that can
send SPDY frames to the service can crash the process with a single
crafted SPDY control frame, causing denial of service.

Affected versions

 github.com/moby/spdystream <= v0.5.0

Fix

 v0.5.1 addresses the receive-side allocation bugs and adds related
hardening:
 
Core fixes:
 

• SETTINGS entry-count validation -- The SETTINGS frame reader now
  checks that numSettings is consistent with the declared frame
  length (numSettings <= (length-4)/8) before allocating.
   
• Header count limit -- parseHeaderValueBlock enforces a maximum
  number of headers per frame (default: 1000).
   
• Header field size limit -- Individual header name and value
  lengths are checked against a per-field size limit (default: 1 MiB)
  before allocation.
   
• Connection closure on protocol error -- The connection read loop
  now closes the underlying net.Conn when it encounters an
  InvalidControlFrame error, preventing further exploitation on the
  same connection.
   
  Additional hardening:
   
• Write-side bounds checks -- All frame write methods now verify
  that payloads fit within the 24-bit length field, preventing the
  library from producing invalid frames.
   
  Configurable limits:
   
• Callers can adjust the defaults using NewConnectionWithOptions or
  the lower-level spdy.NewFramerWithOptions with functional options:
  WithMaxControlFramePayloadSize, WithMaxHeaderFieldSize, and
  WithMaxHeaderCount.
   

Severity

• CVSS Score: 8.7 / 10 (High)
• Vector String: CVSS:4.0/AV:N/AC:L/AT:N/PR:N/UI:N/VC:N/VI:N/VA:H/SC:N/SI:N/SA:N

References

• https://github.com/moby/spdystream/security/advisories/GHSA-pc3f-x583-g7j2
• https://github.com/advisories/GHSA-pc3f-x583-g7j2

This data is provided by the GitHub Advisory Database (CC-BY 4.0).

---

SpdyStream: DOS on CRI

CVE-2026-35469 / GHSA-pc3f-x583-g7j2

More information

Details

The SPDY/3 frame parser in spdystream does not validate
attacker-controlled counts and lengths before allocating memory. A
remote peer that can send SPDY frames to a service using spdystream can
cause the process to allocate gigabytes of memory with a small number of
malformed control frames, leading to an out-of-memory crash.
 
Three allocation paths in the receive side are affected:

1. SETTINGS entry count -- The SETTINGS frame reader reads a 32-bit
   numSettings from the payload and allocates a slice of that size
   without checking it against the declared frame length. An attacker
   can set numSettings to a value far exceeding the actual payload,
   triggering a large allocation before any setting data is read.
    
2. Header count -- parseHeaderValueBlock reads a 32-bit
   numHeaders from the decompressed header block and allocates an
   http.Header map of that size with no upper bound.
    
3. Header field size -- Individual header name and value lengths are
   read as 32-bit integers and used directly as allocation sizes with
   no validation.
    
   Because SPDY header blocks are zlib-compressed, a small on-the-wire
   payload can decompress into attacker-controlled bytes that the parser
   interprets as 32-bit counts and lengths. A single crafted frame is
   enough to exhaust process memory.

Impact

 Any program that accepts SPDY connections using spdystream -- directly
or through a dependent library -- is affected. A remote peer that can
send SPDY frames to the service can crash the process with a single
crafted SPDY control frame, causing denial of service.

Affected versions

 github.com/moby/spdystream <= v0.5.0

Fix

 v0.5.1 addresses the receive-side allocation bugs and adds related
hardening:
 
Core fixes:
 

• SETTINGS entry-count validation -- The SETTINGS frame reader now
  checks that numSettings is consistent with the declared frame
  length (numSettings <= (length-4)/8) before allocating.
   
• Header count limit -- parseHeaderValueBlock enforces a maximum
  number of headers per frame (default: 1000).
   
• Header field size limit -- Individual header name and value
  lengths are checked against a per-field size limit (default: 1 MiB)
  before allocation.
   
• Connection closure on protocol error -- The connection read loop
  now closes the underlying net.Conn when it encounters an
  InvalidControlFrame error, preventing further exploitation on the
  same connection.
   
  Additional hardening:
   
• Write-side bounds checks -- All frame write methods now verify
  that payloads fit within the 24-bit length field, preventing the
  library from producing invalid frames.
   
  Configurable limits:
   
• Callers can adjust the defaults using NewConnectionWithOptions or
  the lower-level spdy.NewFramerWithOptions with functional options:
  WithMaxControlFramePayloadSize, WithMaxHeaderFieldSize, and
  WithMaxHeaderCount.
   

Severity

• CVSS Score: 8.7 / 10 (High)
• Vector String: CVSS:4.0/AV:N/AC:L/AT:N/PR:N/UI:N/VC:N/VI:N/VA:H/SC:N/SI:N/SA:N

References

• https://github.com/moby/spdystream/security/advisories/GHSA-pc3f-x583-g7j2
• https://github.com/moby/spdystream

This data is provided by OSV and the GitHub Advisory Database (CC-BY 4.0).

---

Release Notes

moby/spdystream (github.com/moby/spdystream)

v0.5.1

Compare Source

What's Changed

• spdy: fix duplicate license headers, add LICENSE, PATENTS, and update NOTICE #​106
• ci: update actions and test against latest Go versions #​107
• use ioutil.Discard for go1.13 compatibility #​109

Full Changelog: moby/spdystream@v0.5.0...v0.5.1

---

Configuration

📅 Schedule: (UTC)

• Branch creation
  • ""
• Automerge
  • At any time (no schedule defined)

🚦 Automerge: Disabled by config. Please merge this manually once you are satisfied.

♻ Rebasing: Whenever PR is behind base branch, or you tick the rebase/retry checkbox.

🔕 Ignore: Close this PR and you won't be reminded about this update again.

---

• If you want to rebase/retry this PR, check this box

---

This PR was generated by Mend Renovate. View the repository job log.

[CLAassistant]

Thank you for your submission! We really appreciate it. Like many open source projects, we ask that you sign our Contributor License Agreement before we can accept your contribution.
_{You have signed the CLA already but the status is still pending? Let us recheck it.}

[codecov-commenter]

Codecov Report

✅ All modified and coverable lines are covered by tests.
✅ Project coverage is 32.53%. Comparing base (efae4a8) to head (62903bb).

Additional details and impacted files

@@           Coverage Diff           @@
##             main    #2018   +/-   ##
=======================================
  Coverage   32.53%   32.53%           
=======================================
  Files          77       77           
  Lines        8758     8758           
=======================================
  Hits         2849     2849           
  Misses       5713     5713           
  Partials      196      196           

☔ View full report in Codecov by Sentry.
📢 Have feedback on the report? Share it here.

🚀 New features to boost your workflow:

• ❄️ Test Analytics: Detect flaky tests, report on failures, and find test suite problems.