Vulnerability-Lookup

Vulnerability from cleanstart

Published

2026-05-18 13:34

Modified

2026-05-08 10:44

Summary

Security fixes for CVE-2026-29181, CVE-2026-33186, CVE-2026-35469, ghsa-hr2v-4r36-88hr, ghsa-mh2q-q3fh-2475, ghsa-p77j-4mvh-x3m3, ghsa-pc3f-x583-g7j2 applied in versions: 26.1.4-r0, 26.3.3-r0

Details

Multiple security vulnerabilities affect the linkerd2 package. These issues are resolved in later releases. See references for individual vulnerability details.

References

URL

Type

	https://github.com/cleanstart-dev/cleanstart-secu…	ADVISORY
	https://osv.dev/vulnerability/CVE-2026-29181	WEB
	https://osv.dev/vulnerability/CVE-2026-33186	WEB
	https://osv.dev/vulnerability/CVE-2026-35469	WEB
	https://osv.dev/vulnerability/ghsa-hr2v-4r36-88hr	WEB
	https://osv.dev/vulnerability/ghsa-mh2q-q3fh-2475	WEB
	https://osv.dev/vulnerability/ghsa-p77j-4mvh-x3m3	WEB
	https://osv.dev/vulnerability/ghsa-pc3f-x583-g7j2	WEB
	https://nvd.nist.gov/vuln/detail/CVE-2026-29181	WEB
	https://nvd.nist.gov/vuln/detail/CVE-2026-33186	WEB
	https://nvd.nist.gov/vuln/detail/CVE-2026-35469	WEB

JSON

To clipboard

{
  "affected": [
    {
      "package": {
        "ecosystem": "CleanStart",
        "name": "linkerd2"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            },
            {
              "fixed": "26.3.3-r0"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "credits": [],
  "database_specific": {},
  "details": "Multiple security vulnerabilities affect the linkerd2 package. These issues are resolved in later releases. See references for individual vulnerability details.",
  "id": "CLEANSTART-2026-QX43073",
  "modified": "2026-05-08T10:44:52Z",
  "published": "2026-05-18T13:34:42.816592Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://github.com/cleanstart-dev/cleanstart-security-advisories/tree/main/advisories/2026/CLEANSTART-2026-QX43073.json"
    },
    {
      "type": "WEB",
      "url": "https://osv.dev/vulnerability/CVE-2026-29181"
    },
    {
      "type": "WEB",
      "url": "https://osv.dev/vulnerability/CVE-2026-33186"
    },
    {
      "type": "WEB",
      "url": "https://osv.dev/vulnerability/CVE-2026-35469"
    },
    {
      "type": "WEB",
      "url": "https://osv.dev/vulnerability/ghsa-hr2v-4r36-88hr"
    },
    {
      "type": "WEB",
      "url": "https://osv.dev/vulnerability/ghsa-mh2q-q3fh-2475"
    },
    {
      "type": "WEB",
      "url": "https://osv.dev/vulnerability/ghsa-p77j-4mvh-x3m3"
    },
    {
      "type": "WEB",
      "url": "https://osv.dev/vulnerability/ghsa-pc3f-x583-g7j2"
    },
    {
      "type": "WEB",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-29181"
    },
    {
      "type": "WEB",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-33186"
    },
    {
      "type": "WEB",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-35469"
    }
  ],
  "related": [],
  "schema_version": "1.7.3",
  "summary": "Security fixes for CVE-2026-29181, CVE-2026-33186, CVE-2026-35469, ghsa-hr2v-4r36-88hr, ghsa-mh2q-q3fh-2475, ghsa-p77j-4mvh-x3m3, ghsa-pc3f-x583-g7j2 applied in versions: 26.1.4-r0, 26.3.3-r0",
  "upstream": [
    "CVE-2026-29181",
    "CVE-2026-33186",
    "CVE-2026-35469",
    "ghsa-hr2v-4r36-88hr",
    "ghsa-mh2q-q3fh-2475",
    "ghsa-p77j-4mvh-x3m3",
    "ghsa-pc3f-x583-g7j2"
  ]
}

CVE-2026-29181 (GCVE-0-2026-29181)

Vulnerability from cvelistv5 – Published: 2026-04-07 20:29 – Updated: 2026-04-08 15:37

Title

OpenTelemetry-Go multi-value `baggage` header extraction causes excessive allocations (remote dos amplification)

Summary

OpenTelemetry-Go is the Go implementation of OpenTelemetry. From 1.36.0 to 1.40.0, 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. This vulnerability is fixed in 1.41.0.

Severity

7.5 (High)


                        
                          CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H

CWE

CWE-770 - Allocation of Resources Without Limits or Throttling

Assigner

GitHub_M

References

1 reference

URL	Tags
https://github.com/open-telemetry/opentelemetry-g…	x_refsource_CONFIRM

Impacted products

1 product

Vendor	Product	Version
open-telemetry	opentelemetry-go	Affected: >= 1.36.0, < 1.41.0

Show details on NVD website

JSON

To clipboard

{
  "containers": {
    "adp": [
      {
        "metrics": [
          {
            "other": {
              "content": {
                "id": "CVE-2026-29181",
                "options": [
                  {
                    "Exploitation": "poc"
                  },
                  {
                    "Automatable": "yes"
                  },
                  {
                    "Technical Impact": "partial"
                  }
                ],
                "role": "CISA Coordinator",
                "timestamp": "2026-04-08T15:36:53.783712Z",
                "version": "2.0.3"
              },
              "type": "ssvc"
            }
          }
        ],
        "providerMetadata": {
          "dateUpdated": "2026-04-08T15:37:02.444Z",
          "orgId": "134c704f-9b21-4f2e-91b3-4a467353bcc0",
          "shortName": "CISA-ADP"
        },
        "title": "CISA ADP Vulnrichment"
      }
    ],
    "cna": {
      "affected": [
        {
          "product": "opentelemetry-go",
          "vendor": "open-telemetry",
          "versions": [
            {
              "status": "affected",
              "version": "\u003e= 1.36.0, \u003c 1.41.0"
            }
          ]
        }
      ],
      "descriptions": [
        {
          "lang": "en",
          "value": "OpenTelemetry-Go is the Go implementation of OpenTelemetry. From 1.36.0 to 1.40.0, 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. This vulnerability is fixed in 1.41.0."
        }
      ],
      "metrics": [
        {
          "cvssV3_1": {
            "attackComplexity": "LOW",
            "attackVector": "NETWORK",
            "availabilityImpact": "HIGH",
            "baseScore": 7.5,
            "baseSeverity": "HIGH",
            "confidentialityImpact": "NONE",
            "integrityImpact": "NONE",
            "privilegesRequired": "NONE",
            "scope": "UNCHANGED",
            "userInteraction": "NONE",
            "vectorString": "CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H",
            "version": "3.1"
          }
        }
      ],
      "problemTypes": [
        {
          "descriptions": [
            {
              "cweId": "CWE-770",
              "description": "CWE-770: Allocation of Resources Without Limits or Throttling",
              "lang": "en",
              "type": "CWE"
            }
          ]
        }
      ],
      "providerMetadata": {
        "dateUpdated": "2026-04-07T20:29:13.933Z",
        "orgId": "a0819718-46f1-4df5-94e2-005712e83aaa",
        "shortName": "GitHub_M"
      },
      "references": [
        {
          "name": "https://github.com/open-telemetry/opentelemetry-go/security/advisories/GHSA-mh2q-q3fh-2475",
          "tags": [
            "x_refsource_CONFIRM"
          ],
          "url": "https://github.com/open-telemetry/opentelemetry-go/security/advisories/GHSA-mh2q-q3fh-2475"
        }
      ],
      "source": {
        "advisory": "GHSA-mh2q-q3fh-2475",
        "discovery": "UNKNOWN"
      },
      "title": "OpenTelemetry-Go multi-value `baggage` header extraction causes excessive allocations (remote dos amplification)"
    }
  },
  "cveMetadata": {
    "assignerOrgId": "a0819718-46f1-4df5-94e2-005712e83aaa",
    "assignerShortName": "GitHub_M",
    "cveId": "CVE-2026-29181",
    "datePublished": "2026-04-07T20:29:13.933Z",
    "dateReserved": "2026-03-04T14:44:00.713Z",
    "dateUpdated": "2026-04-08T15:37:02.444Z",
    "state": "PUBLISHED"
  },
  "dataType": "CVE_RECORD",
  "dataVersion": "5.2"
}

CVE-2026-33186 (GCVE-0-2026-33186)

Vulnerability from cvelistv5 – Published: 2026-03-20 22:23 – Updated: 2026-03-24 18:09

Title

gRPC-Go has an authorization bypass via missing leading slash in :path

Summary

gRPC-Go is the Go language implementation of gRPC. Versions prior to 1.79.3 have an authorization bypass resulting from improper input validation of the HTTP/2 `:path` pseudo-header. The gRPC-Go server was too lenient in its routing logic, accepting requests where the `:path` omitted the mandatory leading slash (e.g., `Service/Method` instead of `/Service/Method`). While the server successfully routed these requests to the correct handler, authorization interceptors (including the official `grpc/authz` package) evaluated the raw, non-canonical path string. Consequently, "deny" rules defined using canonical paths (starting with `/`) failed to match the incoming request, allowing it to bypass the policy if a fallback "allow" rule was present. This affects gRPC-Go servers that use path-based authorization interceptors, such as the official RBAC implementation in `google.golang.org/grpc/authz` or custom interceptors relying on `info.FullMethod` or `grpc.Method(ctx)`; AND that have a security policy contains specific "deny" rules for canonical paths but allows other requests by default (a fallback "allow" rule). The vulnerability is exploitable by an attacker who can send raw HTTP/2 frames with malformed `:path` headers directly to the gRPC server. The fix in version 1.79.3 ensures that any request with a `:path` that does not start with a leading slash is immediately rejected with a `codes.Unimplemented` error, preventing it from reaching authorization interceptors or handlers with a non-canonical path string. While upgrading is the most secure and recommended path, users can mitigate the vulnerability using one of the following methods: Use a validating interceptor (recommended mitigation); infrastructure-level normalization; and/or policy hardening.

Severity

9.1 (Critical)


                        
                          CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:N

CWE

CWE-285 - Improper Authorization

Assigner

GitHub_M

References

1 reference

URL	Tags
https://github.com/grpc/grpc-go/security/advisori…	x_refsource_CONFIRM

Impacted products

1 product

Vendor	Product	Version
grpc	grpc-go	Affected: < 1.79.3

Show details on NVD website

JSON

To clipboard

{
  "containers": {
    "adp": [
      {
        "metrics": [
          {
            "other": {
              "content": {
                "id": "CVE-2026-33186",
                "options": [
                  {
                    "Exploitation": "none"
                  },
                  {
                    "Automatable": "yes"
                  },
                  {
                    "Technical Impact": "partial"
                  }
                ],
                "role": "CISA Coordinator",
                "timestamp": "2026-03-24T18:08:38.989284Z",
                "version": "2.0.3"
              },
              "type": "ssvc"
            }
          }
        ],
        "providerMetadata": {
          "dateUpdated": "2026-03-24T18:09:13.422Z",
          "orgId": "134c704f-9b21-4f2e-91b3-4a467353bcc0",
          "shortName": "CISA-ADP"
        },
        "title": "CISA ADP Vulnrichment"
      }
    ],
    "cna": {
      "affected": [
        {
          "product": "grpc-go",
          "vendor": "grpc",
          "versions": [
            {
              "status": "affected",
              "version": "\u003c 1.79.3"
            }
          ]
        }
      ],
      "descriptions": [
        {
          "lang": "en",
          "value": "gRPC-Go is the Go language implementation of gRPC. Versions prior to 1.79.3 have an authorization bypass resulting from improper input validation of the HTTP/2 `:path` pseudo-header. The gRPC-Go server was too lenient in its routing logic, accepting requests where the `:path` omitted the mandatory leading slash (e.g., `Service/Method` instead of `/Service/Method`). While the server successfully routed these requests to the correct handler, authorization interceptors (including the official `grpc/authz` package) evaluated the raw, non-canonical path string. Consequently, \"deny\" rules defined using canonical paths (starting with `/`) failed to match the incoming request, allowing it to bypass the policy if a fallback \"allow\" rule was present. This affects gRPC-Go servers that use path-based authorization interceptors, such as the official RBAC implementation in `google.golang.org/grpc/authz` or custom interceptors relying on `info.FullMethod` or `grpc.Method(ctx)`; AND that have a security policy contains specific \"deny\" rules for canonical paths but allows other requests by default (a fallback \"allow\" rule). The vulnerability is exploitable by an attacker who can send raw HTTP/2 frames with malformed `:path` headers directly to the gRPC server. The fix in version 1.79.3 ensures that any request with a `:path` that does not start with a leading slash is immediately rejected with a `codes.Unimplemented` error, preventing it from reaching authorization interceptors or handlers with a non-canonical path string. While upgrading is the most secure and recommended path, users can mitigate the vulnerability using one of the following methods: Use a validating interceptor (recommended mitigation); infrastructure-level normalization; and/or policy hardening."
        }
      ],
      "metrics": [
        {
          "cvssV3_1": {
            "attackComplexity": "LOW",
            "attackVector": "NETWORK",
            "availabilityImpact": "NONE",
            "baseScore": 9.1,
            "baseSeverity": "CRITICAL",
            "confidentialityImpact": "HIGH",
            "integrityImpact": "HIGH",
            "privilegesRequired": "NONE",
            "scope": "UNCHANGED",
            "userInteraction": "NONE",
            "vectorString": "CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:N",
            "version": "3.1"
          }
        }
      ],
      "problemTypes": [
        {
          "descriptions": [
            {
              "cweId": "CWE-285",
              "description": "CWE-285: Improper Authorization",
              "lang": "en",
              "type": "CWE"
            }
          ]
        }
      ],
      "providerMetadata": {
        "dateUpdated": "2026-03-20T22:23:32.147Z",
        "orgId": "a0819718-46f1-4df5-94e2-005712e83aaa",
        "shortName": "GitHub_M"
      },
      "references": [
        {
          "name": "https://github.com/grpc/grpc-go/security/advisories/GHSA-p77j-4mvh-x3m3",
          "tags": [
            "x_refsource_CONFIRM"
          ],
          "url": "https://github.com/grpc/grpc-go/security/advisories/GHSA-p77j-4mvh-x3m3"
        }
      ],
      "source": {
        "advisory": "GHSA-p77j-4mvh-x3m3",
        "discovery": "UNKNOWN"
      },
      "title": "gRPC-Go has an authorization bypass via missing leading slash in :path"
    }
  },
  "cveMetadata": {
    "assignerOrgId": "a0819718-46f1-4df5-94e2-005712e83aaa",
    "assignerShortName": "GitHub_M",
    "cveId": "CVE-2026-33186",
    "datePublished": "2026-03-20T22:23:32.147Z",
    "dateReserved": "2026-03-17T22:16:36.720Z",
    "dateUpdated": "2026-03-24T18:09:13.422Z",
    "state": "PUBLISHED"
  },
  "dataType": "CVE_RECORD",
  "dataVersion": "5.2"
}

CVE-2026-35469 (GCVE-0-2026-35469)

Vulnerability from cvelistv5 – Published: 2026-04-16 21:19 – Updated: 2026-04-17 12:37

Title

SpdyStream: DOS on CRI

Summary

spdystream is a Go library for multiplexing streams over SPDY connections. In versions 0.5.0 and below, the SPDY/3 frame parser does not validate attacker-controlled counts and lengths before allocating memory. Three allocation paths are affected: the SETTINGS frame entry count, the header count in parseHeaderValueBlock, and individual header field sizes — all read as 32-bit integers and used directly as allocation sizes with no bounds checking. Because SPDY header blocks are zlib-compressed, a small on-the-wire payload can decompress into large attacker-controlled values. A remote peer that can send SPDY frames to a service using spdystream can exhaust process memory and cause an out-of-memory crash with a single crafted control frame. This issue has been fixed in version 0.5.1.

Severity

8.7 (High)


                        
                          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

CWE

CWE-770 - Allocation of Resources Without Limits or Throttling

Assigner

GitHub_M

References

2 references

URL	Tags
https://github.com/moby/spdystream/security/advis…	x_refsource_CONFIRM
https://github.com/moby/spdystream/releases/tag/v0.5.1	x_refsource_MISC

Impacted products

1 product

Vendor	Product	Version
moby	spdystream	Affected: < 0.5.1

Show details on NVD website

JSON

To clipboard

{
  "containers": {
    "adp": [
      {
        "metrics": [
          {
            "other": {
              "content": {
                "id": "CVE-2026-35469",
                "options": [
                  {
                    "Exploitation": "none"
                  },
                  {
                    "Automatable": "yes"
                  },
                  {
                    "Technical Impact": "partial"
                  }
                ],
                "role": "CISA Coordinator",
                "timestamp": "2026-04-17T12:37:18.505269Z",
                "version": "2.0.3"
              },
              "type": "ssvc"
            }
          }
        ],
        "providerMetadata": {
          "dateUpdated": "2026-04-17T12:37:27.329Z",
          "orgId": "134c704f-9b21-4f2e-91b3-4a467353bcc0",
          "shortName": "CISA-ADP"
        },
        "title": "CISA ADP Vulnrichment"
      }
    ],
    "cna": {
      "affected": [
        {
          "product": "spdystream",
          "vendor": "moby",
          "versions": [
            {
              "status": "affected",
              "version": "\u003c 0.5.1"
            }
          ]
        }
      ],
      "descriptions": [
        {
          "lang": "en",
          "value": "spdystream is a Go library for multiplexing streams over SPDY connections. In versions 0.5.0 and below, the SPDY/3 frame parser does not validate attacker-controlled counts and lengths before allocating memory. Three allocation paths are affected: the SETTINGS frame entry count, the header count in parseHeaderValueBlock, and individual header field sizes \u2014 all read as 32-bit integers and used directly as allocation sizes with no bounds checking. Because SPDY header blocks are zlib-compressed, a small on-the-wire payload can decompress into large attacker-controlled values. A remote peer that can send SPDY frames to a service using spdystream can exhaust process memory and cause an out-of-memory crash with a single crafted control frame. This issue has been fixed in version 0.5.1."
        }
      ],
      "metrics": [
        {
          "cvssV4_0": {
            "attackComplexity": "LOW",
            "attackRequirements": "NONE",
            "attackVector": "NETWORK",
            "baseScore": 8.7,
            "baseSeverity": "HIGH",
            "privilegesRequired": "NONE",
            "subAvailabilityImpact": "NONE",
            "subConfidentialityImpact": "NONE",
            "subIntegrityImpact": "NONE",
            "userInteraction": "NONE",
            "vectorString": "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",
            "version": "4.0",
            "vulnAvailabilityImpact": "HIGH",
            "vulnConfidentialityImpact": "NONE",
            "vulnIntegrityImpact": "NONE"
          }
        }
      ],
      "problemTypes": [
        {
          "descriptions": [
            {
              "cweId": "CWE-770",
              "description": "CWE-770: Allocation of Resources Without Limits or Throttling",
              "lang": "en",
              "type": "CWE"
            }
          ]
        }
      ],
      "providerMetadata": {
        "dateUpdated": "2026-04-16T21:19:23.516Z",
        "orgId": "a0819718-46f1-4df5-94e2-005712e83aaa",
        "shortName": "GitHub_M"
      },
      "references": [
        {
          "name": "https://github.com/moby/spdystream/security/advisories/GHSA-pc3f-x583-g7j2",
          "tags": [
            "x_refsource_CONFIRM"
          ],
          "url": "https://github.com/moby/spdystream/security/advisories/GHSA-pc3f-x583-g7j2"
        },
        {
          "name": "https://github.com/moby/spdystream/releases/tag/v0.5.1",
          "tags": [
            "x_refsource_MISC"
          ],
          "url": "https://github.com/moby/spdystream/releases/tag/v0.5.1"
        }
      ],
      "source": {
        "advisory": "GHSA-pc3f-x583-g7j2",
        "discovery": "UNKNOWN"
      },
      "title": "SpdyStream: DOS on CRI"
    }
  },
  "cveMetadata": {
    "assignerOrgId": "a0819718-46f1-4df5-94e2-005712e83aaa",
    "assignerShortName": "GitHub_M",
    "cveId": "CVE-2026-35469",
    "datePublished": "2026-04-16T21:19:23.516Z",
    "dateReserved": "2026-04-02T20:49:44.452Z",
    "dateUpdated": "2026-04-17T12:37:27.329Z",
    "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:33

Summary

Helm Chart extraction output directory collapse via `Chart.yaml` name dot-segment

Details

Helm 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

Severity

4.8 (Medium)


                  
                    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

Show details on source website

JSON

To clipboard

{
  "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:04

Summary

OpenTelemetry-Go: multi-value `baggage` header extraction causes excessive allocations (remote dos amplification)

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.

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=10315458 and p95_ms=7
control: per_req_alloc_bytes=133429 and p95_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.

poc.zip PR_DESCRIPTION.md

Severity

7.5 (High)


                  
                    CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H

Show details on source website

JSON

To clipboard

{
  "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-P77J-4MVH-X3M3

Vulnerability from github – Published: 2026-03-18 20:10 – Updated: 2026-03-25 18:12

Summary

gRPC-Go has an authorization bypass via missing leading slash in :path

Details

Impact

What kind of vulnerability is it? Who is impacted?

It is an Authorization Bypass resulting from Improper Input Validation of the HTTP/2 :path pseudo-header.

The gRPC-Go server was too lenient in its routing logic, accepting requests where the :path omitted the mandatory leading slash (e.g., Service/Method instead of /Service/Method). While the server successfully routed these requests to the correct handler, authorization interceptors (including the official grpc/authz package) evaluated the raw, non-canonical path string. Consequently, "deny" rules defined using canonical paths (starting with /) failed to match the incoming request, allowing it to bypass the policy if a fallback "allow" rule was present.

Who is impacted? This affects gRPC-Go servers that meet both of the following criteria: 1. They use path-based authorization interceptors, such as the official RBAC implementation in google.golang.org/grpc/authz or custom interceptors relying on info.FullMethod or grpc.Method(ctx). 2. Their security policy contains specific "deny" rules for canonical paths but allows other requests by default (a fallback "allow" rule).

The vulnerability is exploitable by an attacker who can send raw HTTP/2 frames with malformed :path headers directly to the gRPC server.

Patches

Has the problem been patched? What versions should users upgrade to?

Yes, the issue has been patched. The fix ensures that any request with a :path that does not start with a leading slash is immediately rejected with a codes.Unimplemented error, preventing it from reaching authorization interceptors or handlers with a non-canonical path string.

Users should upgrade to the following versions (or newer): * v1.79.3 * The latest master branch.

It is recommended that all users employing path-based authorization (especially grpc/authz) upgrade as soon as the patch is available in a tagged release.

Workarounds

Is there a way for users to fix or remediate the vulnerability without upgrading?

While upgrading is the most secure and recommended path, users can mitigate the vulnerability using one of the following methods:

1. Use a Validating Interceptor (Recommended Mitigation)

Add an "outermost" interceptor to your server that validates the path before any other authorization logic runs:

func pathValidationInterceptor(ctx context.Context, req any, info *grpc.UnaryServerInfo, handler grpc.UnaryHandler) (any, error) {
    if info.FullMethod == "" || info.FullMethod[0] != '/' {
        return nil, status.Errorf(codes.Unimplemented, "malformed method name")
    }   
    return handler(ctx, req)
}

// Ensure this is the FIRST interceptor in your chain
s := grpc.NewServer(
    grpc.ChainUnaryInterceptor(pathValidationInterceptor, authzInterceptor),
)

2. Infrastructure-Level Normalization

If your gRPC server is behind a reverse proxy or load balancer (such as Envoy, NGINX, or an L7 Cloud Load Balancer), ensure it is configured to enforce strict HTTP/2 compliance for pseudo-headers and reject or normalize requests where the :path header does not start with a leading slash.

3. Policy Hardening

Switch to a "default deny" posture in your authorization policies (explicitly listing all allowed paths and denying everything else) to reduce the risk of bypasses via malformed inputs.

Severity

9.1 (Critical)


                  
                    CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:N

Show details on source website

JSON

To clipboard

{
  "affected": [
    {
      "package": {
        "ecosystem": "Go",
        "name": "google.golang.org/grpc"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            },
            {
              "fixed": "1.79.3"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [
    "CVE-2026-33186"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-285"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2026-03-18T20:10:29Z",
    "nvd_published_at": "2026-03-20T23:16:45Z",
    "severity": "CRITICAL"
  },
  "details": "### Impact\n_What kind of vulnerability is it? Who is impacted?_\n\nIt is an **Authorization Bypass** resulting from **Improper Input Validation** of the HTTP/2 `:path` pseudo-header.\n\nThe gRPC-Go server was too lenient in its routing logic, accepting requests where the `:path` omitted the mandatory leading slash (e.g., `Service/Method` instead of `/Service/Method`). While the server successfully routed these requests to the correct handler, authorization interceptors (including the official `grpc/authz` package) evaluated the raw, non-canonical path string. Consequently, \"deny\" rules defined using canonical paths (starting with `/`) failed to match the incoming request, allowing it to bypass the policy if a fallback \"allow\" rule was present.\n\n**Who is impacted?**\nThis affects gRPC-Go servers that meet both of the following criteria:\n1. They use path-based authorization interceptors, such as the official RBAC implementation in `google.golang.org/grpc/authz` or custom interceptors relying on `info.FullMethod` or `grpc.Method(ctx)`.\n2. Their security policy contains specific \"deny\" rules for canonical paths but allows other requests by default (a fallback \"allow\" rule).\n\nThe vulnerability is exploitable by an attacker who can send raw HTTP/2 frames with malformed `:path` headers directly to the gRPC server.\n\n### Patches\n_Has the problem been patched? What versions should users upgrade to?_\n\nYes, the issue has been patched. The fix ensures that any request with a `:path` that does not start with a leading slash is immediately rejected with a `codes.Unimplemented` error, preventing it from reaching authorization interceptors or handlers with a non-canonical path string.\n\nUsers should upgrade to the following versions (or newer):\n* **v1.79.3**\n* The latest **master** branch.\n\nIt is recommended that all users employing path-based authorization (especially `grpc/authz`) upgrade as soon as the patch is available in a tagged release.\n\n### Workarounds\n_Is there a way for users to fix or remediate the vulnerability without upgrading?_\n\nWhile upgrading is the most secure and recommended path, users can mitigate the vulnerability using one of the following methods:\n\n#### 1. Use a Validating Interceptor (Recommended Mitigation)\nAdd an \"outermost\" interceptor to your server that validates the path before any other authorization logic runs:\n\n```go\nfunc pathValidationInterceptor(ctx context.Context, req any, info *grpc.UnaryServerInfo, handler grpc.UnaryHandler) (any, error) {\n    if info.FullMethod == \"\" || info.FullMethod[0] != \u0027/\u0027 {\n        return nil, status.Errorf(codes.Unimplemented, \"malformed method name\")\n    }   \n    return handler(ctx, req)\n}\n\n// Ensure this is the FIRST interceptor in your chain\ns := grpc.NewServer(\n    grpc.ChainUnaryInterceptor(pathValidationInterceptor, authzInterceptor),\n)\n```\n\n#### 2. Infrastructure-Level Normalization\nIf your gRPC server is behind a reverse proxy or load balancer (such as Envoy, NGINX, or an L7 Cloud Load Balancer), ensure it is configured to enforce strict HTTP/2 compliance for pseudo-headers and reject or normalize requests where the `:path` header does not start with a leading slash.\n\n#### 3. Policy Hardening\nSwitch to a \"default deny\" posture in your authorization policies (explicitly listing all allowed paths and denying everything else) to reduce the risk of bypasses via malformed inputs.",
  "id": "GHSA-p77j-4mvh-x3m3",
  "modified": "2026-03-25T18:12:09Z",
  "published": "2026-03-18T20:10:29Z",
  "references": [
    {
      "type": "WEB",
      "url": "https://github.com/grpc/grpc-go/security/advisories/GHSA-p77j-4mvh-x3m3"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-33186"
    },
    {
      "type": "PACKAGE",
      "url": "https://github.com/grpc/grpc-go"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:N",
      "type": "CVSS_V3"
    }
  ],
  "summary": "gRPC-Go has an authorization bypass via missing leading slash in :path"
}

GHSA-PC3F-X583-G7J2

Vulnerability from github – Published: 2026-04-16 20:44 – Updated: 2026-04-24 20:35

Summary

SpdyStream: DOS on CRI

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

8.7 (High)


                  
                    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

Show details on source website

JSON

To clipboard

{
  "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-04-24T20:35:19Z",
  "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": "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.

Detection rules are retrieved from Rulezet.

Action not permitted

Vulnerability from cleanstart

CVE-2026-29181 (GCVE-0-2026-29181)

CVE-2026-33186 (GCVE-0-2026-33186)

CVE-2026-35469 (GCVE-0-2026-35469)

GHSA-HR2V-4R36-88HR

Impact

Patches

Workarounds

Credits

GHSA-MH2Q-Q3FH-2475

severity

relevant links

vulnerability details

root cause

impact

proof of concept

fix recommendation

GHSA-P77J-4MVH-X3M3

Impact

Patches

Workarounds

1. Use a Validating Interceptor (Recommended Mitigation)

2. Infrastructure-Level Normalization

3. Policy Hardening

GHSA-PC3F-X583-G7J2

Impact

Affected versions

Fix

Tags

Sightings

Nomenclature