Skip to content

Update module github.com/moby/spdystream to v0.5.1 [SECURITY]#1156

Open
renovate[bot] wants to merge 1 commit into
masterfrom
renovate/go-github.com-moby-spdystream-vulnerability
Open

Update module github.com/moby/spdystream to v0.5.1 [SECURITY]#1156
renovate[bot] wants to merge 1 commit into
masterfrom
renovate/go-github.com-moby-spdystream-vulnerability

Conversation

@renovate

@renovate renovate Bot commented Jun 15, 2026

Copy link
Copy Markdown
Contributor

This PR contains the following updates:

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

Warning

Some dependencies could not be looked up. Check the Dependency Dashboard for more information.


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


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


Configuration

📅 Schedule: (UTC)

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

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

Rebasing: Never, 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.

@renovate renovate Bot added the security label Jun 15, 2026
@github-actions

Copy link
Copy Markdown

✅ Load Test Results (quick)

✅ Load Test Results: ALL TESTS PASSED

🚀 Quick Test (S1, S4, S6) — Use /loadtest for full suite

3/3 passed (100%)

Scenario Description Actions Errors
S1 S1: 143 burst updates, each triggers 1 dep... 143/143 0
S4 S4: 143 no-op updates, all should be skipped 0 0
S6 S6: Restart test - 142 updates during restart 139 0

📦 Download detailed results


Artifacts: Download

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

Projects

None yet

Development

Successfully merging this pull request may close these issues.

0 participants