Skip to content

chore(deps): update module github.com/moby/spdystream to v0.5.1 [security] (release-1.13)#353

Closed
phisco-renovate[bot] wants to merge 1 commit into
release-1.13from
renovate/release-1.13-go-github.com-moby-spdystream-vulnerability
Closed

chore(deps): update module github.com/moby/spdystream to v0.5.1 [security] (release-1.13)#353
phisco-renovate[bot] wants to merge 1 commit into
release-1.13from
renovate/release-1.13-go-github.com-moby-spdystream-vulnerability

Conversation

@phisco-renovate
Copy link
Copy Markdown

@phisco-renovate phisco-renovate Bot commented Apr 17, 2026 •
edited
Loading

This PR contains the following updates:

Package Change Age Confidence
github.com/moby/spdystream v0.2.0 → v0.5.1 age confidence

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 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

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

Security

Fix memory amplification in SPDY frame parsing leads to denial of service (CVE-2026-35469 / GHSA-pc3f-x583-g7j2)

Changes
  • 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

v0.5.0: [v0.5.0] Avoid leaking timeout timer channels and update github actions

Compare Source

What's Changed

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

v0.4.0: [v0.4.0] fix goroutine leak and remove unused code

Compare Source

What's Changed

New Contributors

Full Changelog: moby/spdystream@v0.3.0...v0.4.0

v0.3.0: [v0.3.0] Release with fixes for a race condition

Compare Source

What's Changed

New Contributors

Full Changelog: moby/spdystream@v0.2.0...v0.3.0

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 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 has been generated by Mend Renovate.

@phisco-renovate
Copy link
Copy Markdown
Author

phisco-renovate Bot commented Apr 17, 2026

⚠️ Artifact update problem

Renovate failed to update artifacts related to this branch. You probably do not want to merge this PR as-is.

♻ Renovate will retry this branch, including artifacts, only when one of the following happens:

  • any of the package files in this branch needs updating, or
  • the branch becomes conflicted, or
  • you click the rebase/retry checkbox if found above, or
  • you rename this PR's title to start with "rebase!" to trigger it manually

The artifact failure details are included below:

File name: go.mod
Command failed: install-tool golang $(grep -oP ^toolchain go\K.+ go.mod)
File name: go.mod
Command failed: make generate
# golang.org/x/tools/internal/tokeninternal
/home/ubuntu/go/pkg/mod/golang.org/x/tools@v0.11.0/internal/tokeninternal/tokeninternal.go:78:9: invalid array length -delta * delta (constant -256 of type int64)
apis/generate.go:45: running "go": exit status 1
make[1]: *** [build/makelib/golang.mk:240: go.generate] Error 1
make: *** [build/makelib/common.mk:434: generate] Error 2

@phisco phisco closed this May 6, 2026
@phisco phisco deleted the renovate/release-1.13-go-github.com-moby-spdystream-vulnerability branch May 6, 2026 12:19
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Reviewers

No reviews

Assignees

No one assigned

Labels

automated

Projects

None yet

Milestone

No milestone

Development

Successfully merging this pull request may close these issues.

1 participant

@phisco