Skip to content

chore(deps): bump github.com/moby/spdystream from 0.5.0 to 0.5.1#16300

Merged
renovate[bot] merged 1 commit into
release-2.12from
renovate/release-2.12-go-github.com-moby-spdystream-vulnerability
Apr 20, 2026
Merged

chore(deps): bump github.com/moby/spdystream from 0.5.0 to 0.5.1#16300
renovate[bot] merged 1 commit into
release-2.12from
renovate/release-2.12-go-github.com-moby-spdystream-vulnerability

Conversation

@renovate
Copy link
Copy Markdown
Contributor

@renovate renovate Bot commented Apr 19, 2026

This PR contains the following updates:

Package Type Change Age Adoption
github.com/moby/spdystream indirect v0.5.0v0.5.1 age adoption

GitHub Vulnerability Alerts

CVE-2026-35469

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

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

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: Enabled.

Rebasing: Whenever PR becomes conflicted, 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.

Signed-off-by: renovate[bot] <29139614+renovate[bot]@users.noreply.github.com>
@renovate renovate Bot added area/security Related to security issues, fixes, or improvements dependencies Pull requests that update a dependency file release-2.12 labels Apr 19, 2026
@renovate renovate Bot requested a review from a team as a code owner April 19, 2026 12:32
@renovate renovate Bot added dependencies Pull requests that update a dependency file release-2.12 labels Apr 19, 2026
@renovate renovate Bot requested review from Automaat and bartsmykla April 19, 2026 12:32
@renovate renovate Bot added the area/security Related to security issues, fixes, or improvements label Apr 19, 2026
@renovate renovate Bot enabled auto-merge (squash) April 19, 2026 12:32
@renovate renovate Bot merged commit f512112 into release-2.12 Apr 20, 2026
15 checks passed
@renovate renovate Bot deleted the renovate/release-2.12-go-github.com-moby-spdystream-vulnerability branch April 20, 2026 07:32
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

area/security Related to security issues, fixes, or improvements dependencies Pull requests that update a dependency file release-2.12

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant