Action not permitted
Modal body text goes here.
Modal Title
Modal Body
Vulnerability from cleanstart
Package k8ssandra-client-fips version 0.8.11-r0 fixes 4 vulnerabilities: ghsa-hr2v-4r36-88hr, ghsa-pc3f-x583-g7j2, ghsa-mh2q-q3fh-2475, CVE-2026-35206
| URL | Type | |
|---|---|---|
{
"affected": [
{
"package": {
"ecosystem": "Alpine",
"name": "k8ssandra-client-fips"
},
"ranges": [
{
"events": [
{
"introduced": "0"
},
{
"fixed": "0.8.11-r0"
}
],
"type": "ECOSYSTEM"
}
],
"versions": [
"0.8.11-r0"
]
}
],
"credits": [],
"database_specific": {},
"details": "Package k8ssandra-client-fips version 0.8.11-r0 fixes 4 vulnerabilities: ghsa-hr2v-4r36-88hr, ghsa-pc3f-x583-g7j2, ghsa-mh2q-q3fh-2475, CVE-2026-35206",
"id": "CLEANSTART-2026-GQ87651",
"modified": "2026-07-30T09:30:51Z",
"published": "2026-07-30T07:10:53Z",
"references": [
{
"type": "WEB",
"url": "https://github.com/k8ssandra/k8ssandra-client"
}
],
"related": [],
"schema_version": "1.7.3",
"summary": "Security fixes in k8ssandra-client-fips 0.8.11-r0",
"upstream": [
"ghsa-hr2v-4r36-88hr",
"ghsa-pc3f-x583-g7j2",
"ghsa-mh2q-q3fh-2475",
"CVE-2026-35206"
]
}
CVE-2026-35206 (GCVE-0-2026-35206)
Vulnerability from cvelistv5 – Published: 2026-04-09 21:02 – Updated: 2026-04-14 14:45- CWE-22 - Improper Limitation of a Pathname to a Restricted Directory ('Path Traversal')
| URL | Tags |
|---|---|
| https://github.com/helm/helm/security/advisories/… | x_refsource_CONFIRM |
| https://github.com/helm/helm/commit/4e7994d446718… | x_refsource_MISC |
| https://github.com/helm/helm/releases/tag/v4.1.4 | x_refsource_MISC |
{
"containers": {
"adp": [
{
"metrics": [
{
"other": {
"content": {
"id": "CVE-2026-35206",
"options": [
{
"Exploitation": "none"
},
{
"Automatable": "no"
},
{
"Technical Impact": "partial"
}
],
"role": "CISA Coordinator",
"timestamp": "2026-04-14T14:45:03.230344Z",
"version": "2.0.3"
},
"type": "ssvc"
}
}
],
"providerMetadata": {
"dateUpdated": "2026-04-14T14:45:12.096Z",
"orgId": "134c704f-9b21-4f2e-91b3-4a467353bcc0",
"shortName": "CISA-ADP"
},
"title": "CISA ADP Vulnrichment"
}
],
"cna": {
"affected": [
{
"product": "helm",
"vendor": "helm",
"versions": [
{
"status": "affected",
"version": "\u003e= 4.0.0, \u003c 4.1.4"
},
{
"status": "affected",
"version": "\u003c 3.20.2"
}
]
}
],
"descriptions": [
{
"lang": "en",
"value": "Helm is a package manager for Charts for Kubernetes. In Helm versions \u003c=3.20.1 and \u003c=4.1.3, a specially crafted Chart will cause helm pull --untar [chart URL | repo/chartname] to write the Chart\u0027s contents to the immediate output directory (as defaulted to the current working directory; or as given by the --destination and --untardir flags), rather than the expected output directory suffixed by the chart\u0027s name. This vulnerability is fixed in 3.20.2 and 4.1.4."
}
],
"metrics": [
{
"cvssV4_0": {
"attackComplexity": "LOW",
"attackRequirements": "NONE",
"attackVector": "LOCAL",
"baseScore": 4.8,
"baseSeverity": "MEDIUM",
"privilegesRequired": "NONE",
"subAvailabilityImpact": "NONE",
"subConfidentialityImpact": "NONE",
"subIntegrityImpact": "NONE",
"userInteraction": "PASSIVE",
"vectorString": "CVSS:4.0/AV:L/AC:L/AT:N/PR:N/UI:P/VC:N/VI:L/VA:L/SC:N/SI:N/SA:N",
"version": "4.0",
"vulnAvailabilityImpact": "LOW",
"vulnConfidentialityImpact": "NONE",
"vulnIntegrityImpact": "LOW"
}
}
],
"problemTypes": [
{
"descriptions": [
{
"cweId": "CWE-22",
"description": "CWE-22: Improper Limitation of a Pathname to a Restricted Directory (\u0027Path Traversal\u0027)",
"lang": "en",
"type": "CWE"
}
]
}
],
"providerMetadata": {
"dateUpdated": "2026-04-09T21:02:13.594Z",
"orgId": "a0819718-46f1-4df5-94e2-005712e83aaa",
"shortName": "GitHub_M"
},
"references": [
{
"name": "https://github.com/helm/helm/security/advisories/GHSA-hr2v-4r36-88hr",
"tags": [
"x_refsource_CONFIRM"
],
"url": "https://github.com/helm/helm/security/advisories/GHSA-hr2v-4r36-88hr"
},
{
"name": "https://github.com/helm/helm/commit/4e7994d4467182f535b6797c94b5b0e994a91436",
"tags": [
"x_refsource_MISC"
],
"url": "https://github.com/helm/helm/commit/4e7994d4467182f535b6797c94b5b0e994a91436"
},
{
"name": "https://github.com/helm/helm/releases/tag/v4.1.4",
"tags": [
"x_refsource_MISC"
],
"url": "https://github.com/helm/helm/releases/tag/v4.1.4"
}
],
"source": {
"advisory": "GHSA-hr2v-4r36-88hr",
"discovery": "UNKNOWN"
},
"title": "Helm Chart extraction output directory collapse via `Chart.yaml` name dot-segment"
}
},
"cveMetadata": {
"assignerOrgId": "a0819718-46f1-4df5-94e2-005712e83aaa",
"assignerShortName": "GitHub_M",
"cveId": "CVE-2026-35206",
"datePublished": "2026-04-09T21:02:13.594Z",
"dateReserved": "2026-04-01T18:48:58.937Z",
"dateUpdated": "2026-04-14T14:45:12.096Z",
"state": "PUBLISHED"
},
"dataType": "CVE_RECORD",
"dataVersion": "5.2"
}
GHSA-HR2V-4R36-88HR
Vulnerability from github – Published: 2026-04-10 15:33 – Updated: 2026-04-10 15:33Helm is a package manager for Charts for Kubernetes. In Helm versions <=3.20.1 and <=4.1.3, a specially crafted Chart will cause helm pull --untar [chart URL | repo/chartname] to write the Chart's contents to the immediate output directory (as defaulted to the current working directory; or as given by the --destination and --untardir flags), rather than the expected output directory suffixed by the chart's name.
Impact
The bug enables writing the Chart's contents (unpackaged/untar'ed) to the output directory <output dir>/, instead of the expected <output dir>/<chart name>/, potentially overwriting the contents of the targeted directory.
Note: a chart name containing POSIX dot-dot, or dot-dot and slashes (as if to refer to parent directories) do not resolve beyond the output directory as designed.
Patches
This issue has been resolved in Helm v3.20.2 and v4.1.3
A Chart with an unexpected name (those specified to be "." or ".."), or a Chart name which results in a non-unique directory will be rejected.
Workarounds
Ensure the the name of the Chart does not comprise/contain POSIX pathname special directory references ie. dot-dot ("..") or dot ("."). In addition, ensuring that the pull --untar flag (or equivalent SDK option) refers to a unique/empty output directory prevents chart extraction from inadvertently overwriting existing files within the specified directory.
Credits
Oleh Konko @1seal
{
"affected": [
{
"database_specific": {
"last_known_affected_version_range": "\u003c= 4.1.3"
},
"package": {
"ecosystem": "Go",
"name": "helm.sh/helm/v4"
},
"ranges": [
{
"events": [
{
"introduced": "0"
},
{
"fixed": "4.1.4"
}
],
"type": "ECOSYSTEM"
}
]
},
{
"database_specific": {
"last_known_affected_version_range": "\u003c= 3.20.1"
},
"package": {
"ecosystem": "Go",
"name": "helm.sh/helm/v3"
},
"ranges": [
{
"events": [
{
"introduced": "0"
},
{
"fixed": "3.20.2"
}
],
"type": "ECOSYSTEM"
}
]
}
],
"aliases": [
"CVE-2026-35206"
],
"database_specific": {
"cwe_ids": [
"CWE-22"
],
"github_reviewed": true,
"github_reviewed_at": "2026-04-10T15:33:09Z",
"nvd_published_at": "2026-04-09T21:16:09Z",
"severity": "MODERATE"
},
"details": "Helm is a package manager for Charts for Kubernetes. In Helm versions \u003c=3.20.1 and \u003c=4.1.3, a specially crafted Chart will cause `helm pull --untar [chart URL | repo/chartname]` to write the Chart\u0027s contents to the immediate output directory (as defaulted to the current working directory; or as given by the `--destination` and `--untardir` flags), rather than the expected output directory suffixed by the chart\u0027s name.\n\n### Impact\n\nThe bug enables writing the Chart\u0027s contents (unpackaged/untar\u0027ed) to the output directory `\u003coutput dir\u003e/`, instead of the expected `\u003coutput dir\u003e/\u003cchart name\u003e/`, potentially overwriting the contents of the targeted directory.\n\nNote: a chart name containing POSIX dot-dot, or dot-dot and slashes (as if to refer to parent directories) do not resolve beyond the output directory as designed.\n\n### Patches\n\nThis issue has been resolved in Helm v3.20.2 and v4.1.3\n\nA Chart with an unexpected name (those specified to be \".\" or \"..\"), or a Chart name which results in a non-unique directory will be rejected.\n\n### Workarounds\n\nEnsure the the name of the Chart does not comprise/contain POSIX pathname special directory references ie. dot-dot (\"..\") or dot (\".\"). In addition, ensuring that the `pull --untar` flag (or equivalent SDK option) refers to a unique/empty output directory prevents chart extraction from inadvertently overwriting existing files within the specified directory.\n\n### Credits\n\nOleh Konko\n@1seal",
"id": "GHSA-hr2v-4r36-88hr",
"modified": "2026-04-10T15:33:09Z",
"published": "2026-04-10T15:33:09Z",
"references": [
{
"type": "WEB",
"url": "https://github.com/helm/helm/security/advisories/GHSA-hr2v-4r36-88hr"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-35206"
},
{
"type": "WEB",
"url": "https://github.com/helm/helm/commit/4e7994d4467182f535b6797c94b5b0e994a91436"
},
{
"type": "PACKAGE",
"url": "https://github.com/helm/helm"
},
{
"type": "WEB",
"url": "https://github.com/helm/helm/releases/tag/v4.1.4"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:4.0/AV:L/AC:L/AT:N/PR:N/UI:P/VC:N/VI:L/VA:L/SC:N/SI:N/SA:N",
"type": "CVSS_V4"
}
],
"summary": "Helm Chart extraction output directory collapse via `Chart.yaml` name dot-segment"
}
GHSA-MH2Q-Q3FH-2475
Vulnerability from github – Published: 2026-04-07 20:12 – Updated: 2026-04-24 20:04multi-value baggage: header extraction parses each header field-value independently and aggregates members across values. this allows an attacker to amplify cpu and allocations by sending many baggage: header lines, even when each individual value is within the 8192-byte per-value parse limit.
severity
HIGH (availability / remote request amplification)
relevant links
- repository: https://github.com/open-telemetry/opentelemetry-go
- pinned callsite: https://github.com/open-telemetry/opentelemetry-go/blob/1ee4a4126dbdd1bc79e9fae072fa488beffac52a/propagation/baggage.go#L58
vulnerability details
pins: open-telemetry/opentelemetry-go@1ee4a4126dbdd1bc79e9fae072fa488beffac52a as-of: 2026-02-04 policy: direct (no program scope provided)
callsite: propagation/baggage.go:58 (extractMultiBaggage)
attacker control: inbound HTTP request headers (many baggage field-values) → propagation.HeaderCarrier.Values("baggage") → repeated baggage.Parse + member aggregation
root cause
extractMultiBaggage iterates over all baggage header field-values and parses each one independently, then appends members into a shared slice. the 8192-byte parsing cap applies per header value, but the multi-value path repeats that work once per header line (bounded only by the server/proxy header byte limit).
impact
in a default net/http configuration (max header bytes 1mb), a single request with many baggage: header field-values can cause large per-request allocations and increased latency.
example from the attached PoC harness (darwin/arm64; 80 values; 40 requests):
- canonical:
per_req_alloc_bytes=10315458andp95_ms=7 - control:
per_req_alloc_bytes=133429andp95_ms=0
proof of concept
canonical:
mkdir -p poc
unzip poc.zip -d poc
cd poc
make test
output (excerpt):
[CALLSITE_HIT]: propagation/baggage.go:58 extractMultiBaggage
[PROOF_MARKER]: baggage_multi_value_amplification p95_ms=7 per_req_alloc_bytes=10315458 per_req_allocs=16165
control:
cd poc
make control
control output (excerpt):
[NC_MARKER]: baggage_single_value_baseline p95_ms=0 per_req_alloc_bytes=133429 per_req_allocs=480
expected: multiple baggage header field-values should be semantically equivalent to a single comma-joined baggage value and should not multiply parsing/alloc work within the effective header byte budget.
actual: multiple baggage header field-values trigger repeated parsing and member aggregation, causing high per-request allocations and increased latency even when each individual value is within 8192 bytes.
fix recommendation
avoid repeated parsing across multi-values by enforcing a global budget and/or normalizing multi-values into a single value before parsing. one mitigation approach is to treat multi-values as a single comma-joined string and cap total parsed bytes (for example 8192 bytes total).
fix accepted when: under the default PoC harness settings, canonical stays within 2x of control for per_req_alloc_bytes and per_req_allocs, and p95_ms stays below 2ms.
{
"affected": [
{
"database_specific": {
"last_known_affected_version_range": "\u003c= 1.40.0"
},
"package": {
"ecosystem": "Go",
"name": "go.opentelemetry.io/otel"
},
"ranges": [
{
"events": [
{
"introduced": "1.36.0"
},
{
"fixed": "1.41.0"
}
],
"type": "ECOSYSTEM"
}
]
}
],
"aliases": [
"CVE-2026-29181"
],
"database_specific": {
"cwe_ids": [
"CWE-400",
"CWE-770"
],
"github_reviewed": true,
"github_reviewed_at": "2026-04-07T20:12:57Z",
"nvd_published_at": "2026-04-07T21:17:16Z",
"severity": "HIGH"
},
"details": "multi-value `baggage:` header extraction parses each header field-value independently and aggregates members across values. this allows an attacker to amplify cpu and allocations by sending many `baggage:` header lines, even when each individual value is within the 8192-byte per-value parse limit.\n\n## severity\n\nHIGH (availability / remote request amplification)\n\n## relevant links\n\n- repository: https://github.com/open-telemetry/opentelemetry-go\n- pinned callsite: https://github.com/open-telemetry/opentelemetry-go/blob/1ee4a4126dbdd1bc79e9fae072fa488beffac52a/propagation/baggage.go#L58\n\n## vulnerability details\n\n**pins:** open-telemetry/opentelemetry-go@1ee4a4126dbdd1bc79e9fae072fa488beffac52a\n**as-of:** 2026-02-04\n**policy:** direct (no program scope provided)\n\n**callsite:** propagation/baggage.go:58 (`extractMultiBaggage`)\n**attacker control:** inbound HTTP request headers (many `baggage` field-values) \u2192 `propagation.HeaderCarrier.Values(\"baggage\")` \u2192 repeated `baggage.Parse` + member aggregation\n\n### root cause\n\n`extractMultiBaggage` iterates over all `baggage` header field-values and parses each one independently, then appends members into a shared slice. the 8192-byte parsing cap applies per header value, but the multi-value path repeats that work once per header line (bounded only by the server/proxy header byte limit).\n\n### impact\n\nin a default `net/http` configuration (max header bytes 1mb), a single request with many `baggage:` header field-values can cause large per-request allocations and increased latency.\n\nexample from the attached PoC harness (darwin/arm64; 80 values; 40 requests):\n\n- canonical: `per_req_alloc_bytes=10315458` and `p95_ms=7`\n- control: `per_req_alloc_bytes=133429` and `p95_ms=0`\n\n## proof of concept\n\ncanonical:\n\n```bash\nmkdir -p poc\nunzip poc.zip -d poc\ncd poc\nmake test\n```\n\noutput (excerpt):\n\n```\n[CALLSITE_HIT]: propagation/baggage.go:58 extractMultiBaggage\n[PROOF_MARKER]: baggage_multi_value_amplification p95_ms=7 per_req_alloc_bytes=10315458 per_req_allocs=16165\n```\n\ncontrol:\n\n```bash\ncd poc\nmake control\n```\n\ncontrol output (excerpt):\n\n```\n[NC_MARKER]: baggage_single_value_baseline p95_ms=0 per_req_alloc_bytes=133429 per_req_allocs=480\n```\n\n**expected:** multiple `baggage` header field-values should be semantically equivalent to a single comma-joined `baggage` value and should not multiply parsing/alloc work within the effective header byte budget.\n**actual:** multiple `baggage` header field-values trigger repeated parsing and member aggregation, causing high per-request allocations and increased latency even when each individual value is within 8192 bytes.\n\n## fix recommendation\n\navoid repeated parsing across multi-values by enforcing a global budget and/or normalizing multi-values into a single value before parsing. one mitigation approach is to treat multi-values as a single comma-joined string and cap total parsed bytes (for example 8192 bytes total).\n\n**fix accepted when:** under the default PoC harness settings, canonical stays within 2x of control for `per_req_alloc_bytes` and `per_req_allocs`, and `p95_ms` stays below 2ms.\n\n\n[poc.zip](https://github.com/user-attachments/files/25079945/poc.zip)\n[PR_DESCRIPTION.md](https://github.com/user-attachments/files/25079946/PR_DESCRIPTION.md)",
"id": "GHSA-mh2q-q3fh-2475",
"modified": "2026-04-24T20:04:24Z",
"published": "2026-04-07T20:12:57Z",
"references": [
{
"type": "WEB",
"url": "https://github.com/open-telemetry/opentelemetry-go/security/advisories/GHSA-mh2q-q3fh-2475"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-29181"
},
{
"type": "WEB",
"url": "https://github.com/open-telemetry/opentelemetry-go/pull/7880"
},
{
"type": "WEB",
"url": "https://github.com/open-telemetry/opentelemetry-go/commit/aa1894e09e3fe66860c7885cb40f98901b35277f"
},
{
"type": "PACKAGE",
"url": "https://github.com/open-telemetry/opentelemetry-go"
},
{
"type": "WEB",
"url": "https://github.com/open-telemetry/opentelemetry-go/releases/tag/v1.41.0"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H",
"type": "CVSS_V3"
}
],
"summary": "OpenTelemetry-Go: multi-value `baggage` header extraction causes excessive allocations (remote dos amplification)"
}
GHSA-PC3F-X583-G7J2
Vulnerability from github – Published: 2026-04-16 20:44 – Updated: 2026-06-08 23:36The 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.
{
"affected": [
{
"database_specific": {
"last_known_affected_version_range": "\u003c= 0.5.0"
},
"package": {
"ecosystem": "Go",
"name": "github.com/moby/spdystream"
},
"ranges": [
{
"events": [
{
"introduced": "0"
},
{
"fixed": "0.5.1"
}
],
"type": "ECOSYSTEM"
}
]
}
],
"aliases": [
"CVE-2026-35469"
],
"database_specific": {
"cwe_ids": [
"CWE-770"
],
"github_reviewed": true,
"github_reviewed_at": "2026-04-16T20:44:01Z",
"nvd_published_at": "2026-04-16T22:16:37Z",
"severity": "HIGH"
},
"details": "The SPDY/3 frame parser in spdystream does not validate\nattacker-controlled counts and lengths before allocating memory. A\nremote peer that can send SPDY frames to a service using spdystream can\ncause the process to allocate gigabytes of memory with a small number of\nmalformed control frames, leading to an out-of-memory crash.\n\u00a0\nThree allocation paths in the receive side are affected:\n1. **SETTINGS entry count** -- The SETTINGS frame reader reads a 32-bit\n`numSettings` from the payload and allocates a slice of that size\nwithout checking it against the declared frame length. An attacker\ncan set `numSettings` to a value far exceeding the actual payload,\ntriggering a large allocation before any setting data is read.\n\u00a0\n2. **Header count** -- `parseHeaderValueBlock` reads a 32-bit\n`numHeaders` from the decompressed header block and allocates an\n`http.Header` map of that size with no upper bound.\n\u00a0\n3. **Header field size** -- Individual header name and value lengths are\nread as 32-bit integers and used directly as allocation sizes with\nno validation.\n\u00a0\nBecause SPDY header blocks are zlib-compressed, a small on-the-wire\npayload can decompress into attacker-controlled bytes that the parser\ninterprets as 32-bit counts and lengths. A single crafted frame is\nenough to exhaust process memory.\n## Impact\n\u00a0Any program that accepts SPDY connections using spdystream -- directly\nor through a dependent library -- is affected. A remote peer that can\nsend SPDY frames to the service can crash the process with a single\ncrafted SPDY control frame, causing denial of service.\n## Affected versions\n\u00a0`github.com/moby/spdystream` \u003c= v0.5.0\n## Fix\n\u00a0v0.5.1 addresses the receive-side allocation bugs and adds related\nhardening:\n\u00a0\n**Core fixes:**\n\u00a0\n- **SETTINGS entry-count validation** -- The SETTINGS frame reader now\nchecks that `numSettings` is consistent with the declared frame\nlength (`numSettings \u003c= (length-4)/8`) before allocating.\n\u00a0\n- **Header count limit** -- `parseHeaderValueBlock` enforces a maximum\nnumber of headers per frame (default: 1000).\n\u00a0\n- **Header field size limit** -- Individual header name and value\nlengths are checked against a per-field size limit (default: 1 MiB)\nbefore allocation.\n\u00a0\n- **Connection closure on protocol error** -- The connection read loop\nnow closes the underlying `net.Conn` when it encounters an\n`InvalidControlFrame` error, preventing further exploitation on the\nsame connection.\n\u00a0\n**Additional hardening:**\n\u00a0\n- **Write-side bounds checks** -- All frame write methods now verify\nthat payloads fit within the 24-bit length field, preventing the\nlibrary from producing invalid frames.\n\u00a0\n**Configurable limits:**\n\u00a0\n- Callers can adjust the defaults using `NewConnectionWithOptions` or\nthe lower-level `spdy.NewFramerWithOptions` with functional options:\n`WithMaxControlFramePayloadSize`, `WithMaxHeaderFieldSize`, and\n`WithMaxHeaderCount`.\n\u00a0",
"id": "GHSA-pc3f-x583-g7j2",
"modified": "2026-06-08T23:36:28Z",
"published": "2026-04-16T20:44:01Z",
"references": [
{
"type": "WEB",
"url": "https://github.com/moby/spdystream/security/advisories/GHSA-pc3f-x583-g7j2"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-35469"
},
{
"type": "WEB",
"url": "https://github.com/moby/spdystream/commit/ef6121f62c730110bf5ae604a865a8613bfb787f"
},
{
"type": "PACKAGE",
"url": "https://github.com/moby/spdystream"
},
{
"type": "WEB",
"url": "https://github.com/moby/spdystream/releases/tag/v0.5.1"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "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",
"type": "CVSS_V4"
}
],
"summary": "SpdyStream: DOS on CRI"
}
Sightings
| Author | Source | Type | Date | Other |
|---|
Nomenclature
- Seen: The vulnerability was mentioned, discussed, or observed by the user.
- Confirmed: The vulnerability has been validated from an analyst's perspective.
- Published Proof of Concept: A public proof of concept is available for this vulnerability.
- Exploited: The vulnerability was observed as exploited by the user who reported the sighting.
- Patched: The vulnerability was observed as successfully patched by the user who reported the sighting.
- Not exploited: The vulnerability was not observed as exploited by the user who reported the sighting.
- Not confirmed: The user expressed doubt about the validity of the vulnerability.
- Not patched: The vulnerability was not observed as successfully patched by the user who reported the sighting.