Skip to content

Commit 7cfc7ad

Browse files
jitsu-netjitsu-net
committed
data/reports: add GO-2026-4958
 - data/reports/GO-2026-4958.yaml Fixes #4958 Change-Id: I2f4ed82b7940d7a000fb8c4850cba12b7bf25e42 Reviewed-on: https://go-review.googlesource.com/c/vulndb/+/783300 Reviewed-by: Nicholas Husin <nsh@golang.org> Reviewed-by: Nicholas Husin <husin@google.com> LUCI-TryBot-Result: golang-scoped@luci-project-accounts.iam.gserviceaccount.com <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
1 parent 899e0cc commit 7cfc7ad

2 files changed

Lines changed: 127 additions & 0 deletions

File tree

‎data/osv/GO-2026-4958.json‎

Lines changed: 75 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -0,0 +1,75 @@
1+
{
2+
"schema_version": "1.3.1",
3+
"id": "GO-2026-4958",
4+
"modified": "0001-01-01T00:00:00Z",
5+
"published": "0001-01-01T00:00:00Z",
6+
"aliases": [
7+
"CVE-2026-35469",
8+
"GHSA-pc3f-x583-g7j2"
9+
],
10+
"summary": "Uncontrolled resource consumption when parsing SPDY frames in github.com/moby/spdystream",
11+
"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.\n\nThree allocation paths in the receive side are affected:\n1. 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.\n2. 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.\n3. Header field size: Individual header name and value lengths are read as 32-bit integers and used directly as allocation sizes with no validation.\n\nBecause 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.",
12+
"affected": [
13+
{
14+
"package": {
15+
"name": "github.com/moby/spdystream",
16+
"ecosystem": "Go"
17+
},
18+
"ranges": [
19+
{
20+
"type": "SEMVER",
21+
"events": [
22+
{
23+
"introduced": "0"
24+
},
25+
{
26+
"fixed": "0.5.1"
27+
}
28+
]
29+
}
30+
],
31+
"ecosystem_specific": {
32+
"imports": [
33+
{
34+
"path": "github.com/moby/spdystream",
35+
"symbols": [
36+
"Connection.Serve",
37+
"NewConnection",
38+
"idleAwareFramer.ReadFrame"
39+
]
40+
},
41+
{
42+
"path": "github.com/moby/spdystream/spdy",
43+
"symbols": [
44+
"Framer.ReadFrame",
45+
"NewFramer"
46+
]
47+
}
48+
]
49+
}
50+
}
51+
],
52+
"references": [
53+
{
54+
"type": "ADVISORY",
55+
"url": "https://github.com/moby/spdystream/security/advisories/GHSA-pc3f-x583-g7j2"
56+
},
57+
{
58+
"type": "FIX",
59+
"url": "https://github.com/moby/spdystream/commit/ef6121f62c730110bf5ae604a865a8613bfb787f"
60+
},
61+
{
62+
"type": "WEB",
63+
"url": "https://github.com/moby/spdystream/releases/tag/v0.5.1"
64+
}
65+
],
66+
"credits": [
67+
{
68+
"name": "Samuel Karp"
69+
}
70+
],
71+
"database_specific": {
72+
"url": "https://pkg.go.dev/vuln/GO-2026-4958",
73+
"review_status": "REVIEWED"
74+
}
75+
}

‎data/reports/GO-2026-4958.yaml‎

Lines changed: 52 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -0,0 +1,52 @@
1+
id: GO-2026-4958
2+
modules:
3+
- module: github.com/moby/spdystream
4+
versions:
5+
- fixed: 0.5.1
6+
vulnerable_at: 0.5.0
7+
packages:
8+
- package: github.com/moby/spdystream
9+
symbols:
10+
- Connection.Serve
11+
- NewConnection
12+
derived_symbols:
13+
- idleAwareFramer.ReadFrame
14+
- package: github.com/moby/spdystream/spdy
15+
symbols:
16+
- Framer.ReadFrame
17+
- NewFramer
18+
summary: Uncontrolled resource consumption when parsing SPDY frames in github.com/moby/spdystream
19+
description: |-
20+
The SPDY/3 frame parser in spdystream does not validate attacker-controlled
21+
counts and lengths before allocating memory. A remote peer that can send SPDY
22+
frames to a service using spdystream can cause the process to allocate gigabytes
23+
of memory with a small number of malformed control frames, leading to an
24+
out-of-memory crash.
25+
26+
Three allocation paths in the receive side are affected:
27+
1. SETTINGS entry count: The SETTINGS frame reader reads a 32-bit numSettings
28+
from the payload and allocates a slice of that size without checking it against
29+
the declared frame length.
30+
2. Header count: parseHeaderValueBlock reads a 32-bit numHeaders from the
31+
decompressed header block and allocates an http.Header map of that size with no
32+
upper bound.
33+
3. Header field size: Individual header name and value lengths are read as
34+
32-bit integers and used directly as allocation sizes with no validation.
35+
36+
Because SPDY header blocks are zlib-compressed, a small on-the-wire payload can
37+
decompress into attacker-controlled bytes that the parser interprets as 32-bit
38+
counts and lengths. A single crafted frame is enough to exhaust process memory.
39+
cves:
40+
- CVE-2026-35469
41+
ghsas:
42+
- GHSA-pc3f-x583-g7j2
43+
credits:
44+
- Samuel Karp
45+
references:
46+
- advisory: https://github.com/moby/spdystream/security/advisories/GHSA-pc3f-x583-g7j2
47+
- fix: https://github.com/moby/spdystream/commit/ef6121f62c730110bf5ae604a865a8613bfb787f
48+
- web: https://github.com/moby/spdystream/releases/tag/v0.5.1
49+
source:
50+
id: GHSA-pc3f-x583-g7j2
51+
created: 2026-05-21T09:33:49.997038-04:00
52+
review_status: REVIEWED

0 commit comments

Comments
 (0)