Action not permitted
Modal body text goes here.
Modal Title
Modal Body
Vulnerability from cleanstart
Multiple security vulnerabilities affect the grafana-mimir-fips package. These issues are resolved in later releases. See references for individual vulnerability details.
{
"affected": [
{
"package": {
"ecosystem": "CleanStart",
"name": "grafana-mimir-fips"
},
"ranges": [
{
"events": [
{
"introduced": "0"
},
{
"fixed": "3.0.6-r0"
}
],
"type": "ECOSYSTEM"
}
]
}
],
"credits": [],
"database_specific": {},
"details": "Multiple security vulnerabilities affect the grafana-mimir-fips package. These issues are resolved in later releases. See references for individual vulnerability details.",
"id": "CLEANSTART-2026-CY26398",
"modified": "2026-05-02T17:44:53Z",
"published": "2026-05-18T13:48:50.177028Z",
"references": [
{
"type": "ADVISORY",
"url": "https://github.com/cleanstart-dev/cleanstart-security-advisories/tree/main/advisories/2026/CLEANSTART-2026-CY26398.json"
},
{
"type": "WEB",
"url": "https://osv.dev/vulnerability/CVE-2026-34986"
},
{
"type": "WEB",
"url": "https://osv.dev/vulnerability/ghsa-78h2-9frx-2jm8"
},
{
"type": "WEB",
"url": "https://osv.dev/vulnerability/ghsa-hfvc-g4fc-pqhx"
},
{
"type": "WEB",
"url": "https://osv.dev/vulnerability/ghsa-mh2q-q3fh-2475"
},
{
"type": "WEB",
"url": "https://osv.dev/vulnerability/ghsa-w8rr-5gcm-pp58"
},
{
"type": "WEB",
"url": "https://osv.dev/vulnerability/ghsa-xmrv-pmrh-hhx2"
},
{
"type": "WEB",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-34986"
}
],
"related": [],
"schema_version": "1.7.3",
"summary": "Security fixes for CVE-2026-34986, ghsa-78h2-9frx-2jm8, ghsa-hfvc-g4fc-pqhx, ghsa-mh2q-q3fh-2475, ghsa-w8rr-5gcm-pp58, ghsa-xmrv-pmrh-hhx2 applied in versions: 3.0.5-r0, 3.0.6-r0",
"upstream": [
"CVE-2026-34986",
"ghsa-78h2-9frx-2jm8",
"ghsa-hfvc-g4fc-pqhx",
"ghsa-mh2q-q3fh-2475",
"ghsa-w8rr-5gcm-pp58",
"ghsa-xmrv-pmrh-hhx2"
]
}
CVE-2026-34986 (GCVE-0-2026-34986)
Vulnerability from cvelistv5 – Published: 2026-04-06 16:22 – Updated: 2026-04-07 14:21- CWE-248 - Uncaught Exception
| URL | Tags |
|---|---|
| https://github.com/go-jose/go-jose/security/advis… | x_refsource_CONFIRM |
| https://pkg.go.dev/github.com/go-jose/go-jose/v4#… | x_refsource_MISC |
{
"containers": {
"adp": [
{
"metrics": [
{
"other": {
"content": {
"id": "CVE-2026-34986",
"options": [
{
"Exploitation": "none"
},
{
"Automatable": "yes"
},
{
"Technical Impact": "partial"
}
],
"role": "CISA Coordinator",
"timestamp": "2026-04-07T14:21:42.477191Z",
"version": "2.0.3"
},
"type": "ssvc"
}
}
],
"providerMetadata": {
"dateUpdated": "2026-04-07T14:21:54.041Z",
"orgId": "134c704f-9b21-4f2e-91b3-4a467353bcc0",
"shortName": "CISA-ADP"
},
"title": "CISA ADP Vulnrichment"
}
],
"cna": {
"affected": [
{
"product": "go-jose",
"vendor": "go-jose",
"versions": [
{
"status": "affected",
"version": "\u003e= 4.0.0, \u003c 4.1.4"
},
{
"status": "affected",
"version": "\u003c 3.0.5"
}
]
}
],
"descriptions": [
{
"lang": "en",
"value": "Go JOSE provides an implementation of the Javascript Object Signing and Encryption set of standards in Go, including support for JSON Web Encryption (JWE), JSON Web Signature (JWS), and JSON Web Token (JWT) standards. Prior to 4.1.4 and 3.0.5, decrypting a JSON Web Encryption (JWE) object will panic if the alg field indicates a key wrapping algorithm (one ending in KW, with the exception of A128GCMKW, A192GCMKW, and A256GCMKW) and the encrypted_key field is empty. The panic happens when cipher.KeyUnwrap() in key_wrap.go attempts to allocate a slice with a zero or negative length based on the length of the encrypted_key. This code path is reachable from ParseEncrypted() / ParseEncryptedJSON() / ParseEncryptedCompact() followed by Decrypt() on the resulting object. Note that the parse functions take a list of accepted key algorithms. If the accepted key algorithms do not include any key wrapping algorithms, parsing will fail and the application will be unaffected. This panic is also reachable by calling cipher.KeyUnwrap() directly with any ciphertext parameter less than 16 bytes long, but calling this function directly is less common. Panics can lead to denial of service. This vulnerability is fixed in 4.1.4 and 3.0.5."
}
],
"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-248",
"description": "CWE-248: Uncaught Exception",
"lang": "en",
"type": "CWE"
}
]
}
],
"providerMetadata": {
"dateUpdated": "2026-04-06T16:22:45.353Z",
"orgId": "a0819718-46f1-4df5-94e2-005712e83aaa",
"shortName": "GitHub_M"
},
"references": [
{
"name": "https://github.com/go-jose/go-jose/security/advisories/GHSA-78h2-9frx-2jm8",
"tags": [
"x_refsource_CONFIRM"
],
"url": "https://github.com/go-jose/go-jose/security/advisories/GHSA-78h2-9frx-2jm8"
},
{
"name": "https://pkg.go.dev/github.com/go-jose/go-jose/v4#pkg-constants",
"tags": [
"x_refsource_MISC"
],
"url": "https://pkg.go.dev/github.com/go-jose/go-jose/v4#pkg-constants"
}
],
"source": {
"advisory": "GHSA-78h2-9frx-2jm8",
"discovery": "UNKNOWN"
},
"title": "Go JOSE affect by a panic in JWE decryption"
}
},
"cveMetadata": {
"assignerOrgId": "a0819718-46f1-4df5-94e2-005712e83aaa",
"assignerShortName": "GitHub_M",
"cveId": "CVE-2026-34986",
"datePublished": "2026-04-06T16:22:45.353Z",
"dateReserved": "2026-03-31T19:38:31.617Z",
"dateUpdated": "2026-04-07T14:21:54.041Z",
"state": "PUBLISHED"
},
"dataType": "CVE_RECORD",
"dataVersion": "5.2"
}
GHSA-78H2-9FRX-2JM8
Vulnerability from github – Published: 2026-04-03 03:28 – Updated: 2026-04-06 23:11Impact
Decrypting a JSON Web Encryption (JWE) object will panic if the alg field indicates a key wrapping algorithm (one ending in KW, with the exception of A128GCMKW, A192GCMKW, and A256GCMKW) and the encrypted_key field is empty. The panic happens when cipher.KeyUnwrap() in key_wrap.go attempts to allocate a slice with a zero or negative length based on the length of the encrypted_key.
This code path is reachable from ParseEncrypted() / ParseEncryptedJSON() / ParseEncryptedCompact() followed by Decrypt() on the resulting object. Note that the parse functions take a list of accepted key algorithms. If the accepted key algorithms do not include any key wrapping algorithms, parsing will fail and the application will be unaffected.
This panic is also reachable by calling cipher.KeyUnwrap() directly with any ciphertext parameter less than 16 bytes long, but calling this function directly is less common.
Panics can lead to denial of service.
Fixed In
4.1.4 and v3.0.5
Workarounds
If the list of keyAlgorithms passed to ParseEncrypted() / ParseEncryptedJSON() / ParseEncryptedCompact() does not include key wrapping algorithms (those ending in KW), your application is unaffected.
If your application uses key wrapping, you can prevalidate to the JWE objects to ensure the encrypted_key field is nonempty. If your application accepts JWE Compact Serialization, apply that validation to the corresponding field of that serialization (the data between the first and second .).
Thanks
Thanks to Datadog's Security team for finding this issue.
{
"affected": [
{
"package": {
"ecosystem": "Go",
"name": "github.com/go-jose/go-jose/v4"
},
"ranges": [
{
"events": [
{
"introduced": "0"
},
{
"fixed": "4.1.4"
}
],
"type": "ECOSYSTEM"
}
]
},
{
"package": {
"ecosystem": "Go",
"name": "github.com/go-jose/go-jose/v3"
},
"ranges": [
{
"events": [
{
"introduced": "0"
},
{
"fixed": "3.0.5"
}
],
"type": "ECOSYSTEM"
}
]
},
{
"package": {
"ecosystem": "Go",
"name": "github.com/go-jose/go-jose"
},
"ranges": [
{
"events": [
{
"introduced": "0"
},
{
"last_affected": "2.6.3"
}
],
"type": "ECOSYSTEM"
}
]
}
],
"aliases": [
"CVE-2026-34986"
],
"database_specific": {
"cwe_ids": [
"CWE-248"
],
"github_reviewed": true,
"github_reviewed_at": "2026-04-03T03:28:56Z",
"nvd_published_at": "2026-04-06T17:17:11Z",
"severity": "HIGH"
},
"details": "### Impact\n\nDecrypting a JSON Web Encryption (JWE) object will panic if the `alg` field indicates a key wrapping algorithm ([one ending in `KW`](https://pkg.go.dev/github.com/go-jose/go-jose/v4#pkg-constants), with the exception of `A128GCMKW`, `A192GCMKW`, and `A256GCMKW`) and the `encrypted_key` field is empty. The panic happens when `cipher.KeyUnwrap()` in `key_wrap.go` attempts to allocate a slice with a zero or negative length based on the length of the `encrypted_key`.\n\nThis code path is reachable from `ParseEncrypted()` / `ParseEncryptedJSON()` / `ParseEncryptedCompact()` followed by `Decrypt()` on the resulting object. Note that the parse functions take a list of accepted key algorithms. If the accepted key algorithms do not include any key wrapping algorithms, parsing will fail and the application will be unaffected.\n\nThis panic is also reachable by calling `cipher.KeyUnwrap()` directly with any `ciphertext` parameter less than 16 bytes long, but calling this function directly is less common.\n\nPanics can lead to denial of service.\n\n### Fixed In\n\n4.1.4 and v3.0.5\n\n### Workarounds\n\nIf the list of `keyAlgorithms` passed to `ParseEncrypted()` / `ParseEncryptedJSON()` / `ParseEncryptedCompact()` does not include key wrapping algorithms (those ending in `KW`), your application is unaffected.\n\nIf your application uses key wrapping, you can prevalidate to the JWE objects to ensure the `encrypted_key` field is nonempty. If your application accepts JWE Compact Serialization, apply that validation to the corresponding field of that serialization (the data between the first and second `.`).\n\n### Thanks\n\nThanks to Datadog\u0027s Security team for finding this issue.",
"id": "GHSA-78h2-9frx-2jm8",
"modified": "2026-04-06T23:11:46Z",
"published": "2026-04-03T03:28:56Z",
"references": [
{
"type": "WEB",
"url": "https://github.com/go-jose/go-jose/security/advisories/GHSA-78h2-9frx-2jm8"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-34986"
},
{
"type": "PACKAGE",
"url": "https://github.com/go-jose/go-jose"
},
{
"type": "WEB",
"url": "https://pkg.go.dev/github.com/go-jose/go-jose/v4#pkg-constants"
}
],
"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": "Go JOSE Panics in JWE decryption"
}
GHSA-HFVC-G4FC-PQHX
Vulnerability from github – Published: 2026-04-08 19:22 – Updated: 2026-04-09 14:29Summary
The fix for GHSA-9h8m-3fm2-qjrq (CVE-2026-24051) changed the Darwin ioreg command to use an absolute path but left the BSD kenv command using a bare name, allowing the same PATH hijacking attack on BSD and Solaris platforms.
Root Cause
sdk/resource/host_id.go line 42:
if result, err := r.execCommand("kenv", "-q", "smbios.system.uuid"); err == nil {
Compare with the fixed Darwin path at line 58:
result, err := r.execCommand("/usr/sbin/ioreg", "-rd1", "-c", "IOPlatformExpertDevice")
The execCommand helper at sdk/resource/host_id_exec.go uses exec.Command(name, arg...) which searches $PATH when the command name contains no path separator.
Affected platforms (per build tag in host_id_bsd.go:4): DragonFly BSD, FreeBSD, NetBSD, OpenBSD, Solaris.
The kenv path is reached when /etc/hostid does not exist (line 38-40), which is common on FreeBSD systems.
Attack
- Attacker has local access to a system running a Go application that imports
go.opentelemetry.io/otel/sdk - Attacker places a malicious
kenvbinary earlier in$PATH - Application initializes OpenTelemetry resource detection at startup
hostIDReaderBSD.read()callsexec.Command("kenv", ...)which resolves to the malicious binary- Arbitrary code executes in the context of the application
Same attack vector and impact as CVE-2026-24051.
Suggested Fix
Use the absolute path:
if result, err := r.execCommand("/bin/kenv", "-q", "smbios.system.uuid"); err == nil {
On FreeBSD, kenv is located at /bin/kenv.
{
"affected": [
{
"database_specific": {
"last_known_affected_version_range": "\u003c= 1.42.0"
},
"package": {
"ecosystem": "Go",
"name": "go.opentelemetry.io/otel/sdk"
},
"ranges": [
{
"events": [
{
"introduced": "1.15.0"
},
{
"fixed": "1.43.0"
}
],
"type": "ECOSYSTEM"
}
]
}
],
"aliases": [
"CVE-2026-39883"
],
"database_specific": {
"cwe_ids": [
"CWE-426"
],
"github_reviewed": true,
"github_reviewed_at": "2026-04-08T19:22:12Z",
"nvd_published_at": "2026-04-08T21:17:00Z",
"severity": "HIGH"
},
"details": "## Summary\n\nThe fix for GHSA-9h8m-3fm2-qjrq (CVE-2026-24051) changed the Darwin `ioreg` command to use an absolute path but left the BSD `kenv` command using a bare name, allowing the same PATH hijacking attack on BSD and Solaris platforms.\n\n## Root Cause\n\n`sdk/resource/host_id.go` line 42:\n\n if result, err := r.execCommand(\"kenv\", \"-q\", \"smbios.system.uuid\"); err == nil {\n\nCompare with the fixed Darwin path at line 58:\n\n result, err := r.execCommand(\"/usr/sbin/ioreg\", \"-rd1\", \"-c\", \"IOPlatformExpertDevice\")\n\nThe `execCommand` helper at `sdk/resource/host_id_exec.go` uses `exec.Command(name, arg...)` which searches `$PATH` when the command name contains no path separator.\n\nAffected platforms (per build tag in `host_id_bsd.go:4`): DragonFly BSD, FreeBSD, NetBSD, OpenBSD, Solaris.\n\nThe `kenv` path is reached when `/etc/hostid` does not exist (line 38-40), which is common on FreeBSD systems.\n\n## Attack\n\n1. Attacker has local access to a system running a Go application that imports `go.opentelemetry.io/otel/sdk`\n2. Attacker places a malicious `kenv` binary earlier in `$PATH`\n3. Application initializes OpenTelemetry resource detection at startup\n4. `hostIDReaderBSD.read()` calls `exec.Command(\"kenv\", ...)` which resolves to the malicious binary\n5. Arbitrary code executes in the context of the application\n\nSame attack vector and impact as CVE-2026-24051.\n\n## Suggested Fix\n\nUse the absolute path:\n\n if result, err := r.execCommand(\"/bin/kenv\", \"-q\", \"smbios.system.uuid\"); err == nil {\n\nOn FreeBSD, `kenv` is located at `/bin/kenv`.",
"id": "GHSA-hfvc-g4fc-pqhx",
"modified": "2026-04-09T14:29:41Z",
"published": "2026-04-08T19:22:12Z",
"references": [
{
"type": "WEB",
"url": "https://github.com/open-telemetry/opentelemetry-go/security/advisories/GHSA-hfvc-g4fc-pqhx"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-39883"
},
{
"type": "PACKAGE",
"url": "https://github.com/open-telemetry/opentelemetry-go"
},
{
"type": "WEB",
"url": "http://github.com/open-telemetry/opentelemetry-go/releases/tag/v1.43.0"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:4.0/AV:L/AC:H/AT:N/PR:L/UI:N/VC:H/VI:H/VA:H/SC:N/SI:N/SA:N",
"type": "CVSS_V4"
}
],
"summary": "opentelemetry-go: BSD kenv command not using absolute path enables PATH hijacking"
}
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-W8RR-5GCM-PP58
Vulnerability from github – Published: 2026-04-08 19:22 – Updated: 2026-04-09 14:29overview:
this report shows that the otlp HTTP exporters (traces/metrics/logs) read the full HTTP response body into an in-memory bytes.Buffer without a size cap.
this is exploitable for memory exhaustion when the configured collector endpoint is attacker-controlled (or a network attacker can mitm the exporter connection).
severity
HIGH
not claiming: this is a remote dos against every default deployment. claiming: if the exporter sends traces to an untrusted collector endpoint (or over a network segment where mitm is realistic), that endpoint can crash the process via a large response body.
callsite (pinned): - exporters/otlp/otlptrace/otlptracehttp/client.go:199 - exporters/otlp/otlptrace/otlptracehttp/client.go:230 - exporters/otlp/otlpmetric/otlpmetrichttp/client.go:170 - exporters/otlp/otlpmetric/otlpmetrichttp/client.go:201 - exporters/otlp/otlplog/otlploghttp/client.go:190 - exporters/otlp/otlplog/otlploghttp/client.go:221
permalinks (pinned): - https://github.com/open-telemetry/opentelemetry-go/blob/248da958375e4dfb4a1105645107be3ef04b1c59/exporters/otlp/otlptrace/otlptracehttp/client.go#L199 - https://github.com/open-telemetry/opentelemetry-go/blob/248da958375e4dfb4a1105645107be3ef04b1c59/exporters/otlp/otlptrace/otlptracehttp/client.go#L230 - https://github.com/open-telemetry/opentelemetry-go/blob/248da958375e4dfb4a1105645107be3ef04b1c59/exporters/otlp/otlpmetric/otlpmetrichttp/client.go#L170 - https://github.com/open-telemetry/opentelemetry-go/blob/248da958375e4dfb4a1105645107be3ef04b1c59/exporters/otlp/otlpmetric/otlpmetrichttp/client.go#L201 - https://github.com/open-telemetry/opentelemetry-go/blob/248da958375e4dfb4a1105645107be3ef04b1c59/exporters/otlp/otlplog/otlploghttp/client.go#L190 - https://github.com/open-telemetry/opentelemetry-go/blob/248da958375e4dfb4a1105645107be3ef04b1c59/exporters/otlp/otlplog/otlploghttp/client.go#L221
root cause:
each exporter client reads resp.Body using io.Copy(&respData, resp.Body) into a bytes.Buffer on both success and error paths, with no upper bound.
impact: a malicious collector can force large transient heap allocations during export (peak memory scales with attacker-chosen response size) and can potentially crash the instrumented process (oom).
affected component: - go.opentelemetry.io/otel/exporters/otlp/otlptrace/otlptracehttp - go.opentelemetry.io/otel/exporters/otlp/otlpmetric/otlpmetrichttp - go.opentelemetry.io/otel/exporters/otlp/otlplog/otlploghttp
repro (local-only):
unzip poc.zip -d poc
cd poc
make canonical resp_bytes=33554432 chunk_delay_ms=0
expected output contains:
[CALLSITE_HIT]: otlptracehttp.UploadTraces::io.Copy(resp.Body)
[PROOF_MARKER]: resp_bytes=33554432 peak_alloc_bytes=118050512
control (same env, patched target):
unzip poc.zip -d poc
cd poc
make control resp_bytes=33554432 chunk_delay_ms=0
expected control output contains:
[CALLSITE_HIT]: otlptracehttp.UploadTraces::io.Copy(resp.Body)
[NC_MARKER]: resp_bytes=33554432 peak_alloc_bytes=512232
attachments: poc.zip (attached)
Fixed in: https://github.com/open-telemetry/opentelemetry-go/pull/8108
{
"affected": [
{
"package": {
"ecosystem": "Go",
"name": "go.opentelemetry.io/otel/exporters/otlp/otlptrace/otlptracehttp"
},
"ranges": [
{
"events": [
{
"introduced": "0"
},
{
"fixed": "1.43.0"
}
],
"type": "ECOSYSTEM"
}
]
},
{
"package": {
"ecosystem": "Go",
"name": "go.opentelemetry.io/otel/exporters/otlp/otlpmetric/otlpmetrichttp"
},
"ranges": [
{
"events": [
{
"introduced": "0"
},
{
"fixed": "1.43.0"
}
],
"type": "ECOSYSTEM"
}
]
},
{
"package": {
"ecosystem": "Go",
"name": "go.opentelemetry.io/otel/exporters/otlp/otlplog/otlploghttp"
},
"ranges": [
{
"events": [
{
"introduced": "0"
},
{
"fixed": "0.19.0"
}
],
"type": "ECOSYSTEM"
}
]
}
],
"aliases": [
"CVE-2026-39882"
],
"database_specific": {
"cwe_ids": [
"CWE-789"
],
"github_reviewed": true,
"github_reviewed_at": "2026-04-08T19:22:01Z",
"nvd_published_at": "2026-04-08T21:17:00Z",
"severity": "MODERATE"
},
"details": "overview:\nthis report shows that the otlp HTTP exporters (traces/metrics/logs) read the full HTTP response body into an in-memory `bytes.Buffer` without a size cap.\n\nthis is exploitable for memory exhaustion when the configured collector endpoint is attacker-controlled (or a network attacker can mitm the exporter connection).\n\nseverity\n\nHIGH\n\nnot claiming: this is a remote dos against every default deployment.\nclaiming: if the exporter sends traces to an untrusted collector endpoint (or over a network segment where mitm is realistic), that endpoint can crash the process via a large response body.\n\ncallsite (pinned):\n- exporters/otlp/otlptrace/otlptracehttp/client.go:199\n- exporters/otlp/otlptrace/otlptracehttp/client.go:230\n- exporters/otlp/otlpmetric/otlpmetrichttp/client.go:170\n- exporters/otlp/otlpmetric/otlpmetrichttp/client.go:201\n- exporters/otlp/otlplog/otlploghttp/client.go:190\n- exporters/otlp/otlplog/otlploghttp/client.go:221\n\npermalinks (pinned):\n- https://github.com/open-telemetry/opentelemetry-go/blob/248da958375e4dfb4a1105645107be3ef04b1c59/exporters/otlp/otlptrace/otlptracehttp/client.go#L199\n- https://github.com/open-telemetry/opentelemetry-go/blob/248da958375e4dfb4a1105645107be3ef04b1c59/exporters/otlp/otlptrace/otlptracehttp/client.go#L230\n- https://github.com/open-telemetry/opentelemetry-go/blob/248da958375e4dfb4a1105645107be3ef04b1c59/exporters/otlp/otlpmetric/otlpmetrichttp/client.go#L170\n- https://github.com/open-telemetry/opentelemetry-go/blob/248da958375e4dfb4a1105645107be3ef04b1c59/exporters/otlp/otlpmetric/otlpmetrichttp/client.go#L201\n- https://github.com/open-telemetry/opentelemetry-go/blob/248da958375e4dfb4a1105645107be3ef04b1c59/exporters/otlp/otlplog/otlploghttp/client.go#L190\n- https://github.com/open-telemetry/opentelemetry-go/blob/248da958375e4dfb4a1105645107be3ef04b1c59/exporters/otlp/otlplog/otlploghttp/client.go#L221\n\nroot cause:\neach exporter client reads `resp.Body` using `io.Copy(\u0026respData, resp.Body)` into a `bytes.Buffer` on both success and error paths, with no upper bound.\n\nimpact:\na malicious collector can force large transient heap allocations during export (peak memory scales with attacker-chosen response size) and can potentially crash the instrumented process (oom).\n\naffected component:\n- go.opentelemetry.io/otel/exporters/otlp/otlptrace/otlptracehttp\n- go.opentelemetry.io/otel/exporters/otlp/otlpmetric/otlpmetrichttp\n- go.opentelemetry.io/otel/exporters/otlp/otlplog/otlploghttp\n\nrepro (local-only):\n\n```bash\nunzip poc.zip -d poc\ncd poc\nmake canonical resp_bytes=33554432 chunk_delay_ms=0\n```\n\nexpected output contains:\n\n```\n[CALLSITE_HIT]: otlptracehttp.UploadTraces::io.Copy(resp.Body)\n[PROOF_MARKER]: resp_bytes=33554432 peak_alloc_bytes=118050512\n```\n\ncontrol (same env, patched target):\n\n```bash\nunzip poc.zip -d poc\ncd poc\nmake control resp_bytes=33554432 chunk_delay_ms=0\n```\n\nexpected control output contains:\n\n```\n[CALLSITE_HIT]: otlptracehttp.UploadTraces::io.Copy(resp.Body)\n[NC_MARKER]: resp_bytes=33554432 peak_alloc_bytes=512232\n```\n\nattachments: poc.zip (attached)\n\n[PR_DESCRIPTION.md](https://github.com/user-attachments/files/25564272/PR_DESCRIPTION.md)\n\n[attack_scenario.md](https://github.com/user-attachments/files/25564273/attack_scenario.md)\n\n[poc.zip](https://github.com/user-attachments/files/25564271/poc.zip)\n\n\nFixed in: https://github.com/open-telemetry/opentelemetry-go/pull/8108",
"id": "GHSA-w8rr-5gcm-pp58",
"modified": "2026-04-09T14:29:37Z",
"published": "2026-04-08T19:22:01Z",
"references": [
{
"type": "WEB",
"url": "https://github.com/open-telemetry/opentelemetry-go/security/advisories/GHSA-w8rr-5gcm-pp58"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-39882"
},
{
"type": "WEB",
"url": "https://github.com/open-telemetry/opentelemetry-go/pull/8108"
},
{
"type": "PACKAGE",
"url": "https://github.com/open-telemetry/opentelemetry-go"
},
{
"type": "WEB",
"url": "http://github.com/open-telemetry/opentelemetry-go/releases/tag/v1.43.0"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:A/AC:H/PR:N/UI:N/S:U/C:N/I:N/A:H",
"type": "CVSS_V3"
}
],
"summary": "opentelemetry-go: OTLP HTTP exporters read unbounded HTTP response bodies"
}
GHSA-XMRV-PMRH-HHX2
Vulnerability from github – Published: 2026-04-08 00:18 – Updated: 2026-04-08 00:18CVSSv3.1 Rating: [Medium] CVSSv3.1 Score: [5.9] CVSSv3.1 Vector String: [CVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:U/C:N/I:N/A:H]
Summary and Impact
An issue exists in the the EventStream header decoder in AWS SDK for Go v2 in versions predating 2026-03-23. An actor can send a malformed EventStream response frame containing a crafted header value type byte outside the valid range, which can cause the host process to terminate.
Impacted versions: < 2026-03-23
Patches
This issue has been addressed in versions 2026-03-23 and above. We recommend upgrading to the latest version and ensuring any forked or derivative code is patched to incorporate the new fixes.
Workarounds
Not Applicable
References
If you have any questions or comments about this advisory, we ask that you contact [AWS/Amazon] Security via our vulnerability reporting page or directly via email to aws-security@amazon.com. Please do not create a public GitHub issue.
{
"affected": [
{
"package": {
"ecosystem": "Go",
"name": "github.com/aws/aws-sdk-go-v2/aws/protocol/eventstream"
},
"ranges": [
{
"events": [
{
"introduced": "0"
},
{
"fixed": "1.7.8"
}
],
"type": "ECOSYSTEM"
}
]
},
{
"package": {
"ecosystem": "Go",
"name": "github.com/aws/aws-sdk-go-v2/service/bedrockagentcore"
},
"ranges": [
{
"events": [
{
"introduced": "0"
},
{
"fixed": "1.15.2"
}
],
"type": "ECOSYSTEM"
}
]
},
{
"package": {
"ecosystem": "Go",
"name": "github.com/aws/aws-sdk-go-v2/service/bedrockagentruntime"
},
"ranges": [
{
"events": [
{
"introduced": "0"
},
{
"fixed": "1.51.8"
}
],
"type": "ECOSYSTEM"
}
]
},
{
"package": {
"ecosystem": "Go",
"name": "github.com/aws/aws-sdk-go-v2/service/bedrockruntime"
},
"ranges": [
{
"events": [
{
"introduced": "0"
},
{
"fixed": "1.50.4"
}
],
"type": "ECOSYSTEM"
}
]
},
{
"package": {
"ecosystem": "Go",
"name": "github.com/aws/aws-sdk-go-v2/service/cloudwatchlogs"
},
"ranges": [
{
"events": [
{
"introduced": "0"
},
{
"fixed": "1.65.0"
}
],
"type": "ECOSYSTEM"
}
]
},
{
"package": {
"ecosystem": "Go",
"name": "github.com/aws/aws-sdk-go-v2/service/iotsitewise"
},
"ranges": [
{
"events": [
{
"introduced": "0"
},
{
"fixed": "1.52.19"
}
],
"type": "ECOSYSTEM"
}
]
},
{
"package": {
"ecosystem": "Go",
"name": "github.com/aws/aws-sdk-go-v2/service/kinesis"
},
"ranges": [
{
"events": [
{
"introduced": "0"
},
{
"fixed": "1.43.5"
}
],
"type": "ECOSYSTEM"
}
]
},
{
"package": {
"ecosystem": "Go",
"name": "github.com/aws/aws-sdk-go-v2/service/lambda"
},
"ranges": [
{
"events": [
{
"introduced": "0"
},
{
"fixed": "1.88.5"
}
],
"type": "ECOSYSTEM"
}
]
},
{
"package": {
"ecosystem": "Go",
"name": "github.com/aws/aws-sdk-go-v2/service/lexruntimev2"
},
"ranges": [
{
"events": [
{
"introduced": "0"
},
{
"fixed": "1.35.15"
}
],
"type": "ECOSYSTEM"
}
]
},
{
"package": {
"ecosystem": "Go",
"name": "github.com/aws/aws-sdk-go-v2/service/s3"
},
"ranges": [
{
"events": [
{
"introduced": "0"
},
{
"fixed": "1.97.3"
}
],
"type": "ECOSYSTEM"
}
]
},
{
"package": {
"ecosystem": "Go",
"name": "github.com/aws/aws-sdk-go-v2/service/sagemakerruntime"
},
"ranges": [
{
"events": [
{
"introduced": "0"
},
{
"fixed": "1.39.6"
}
],
"type": "ECOSYSTEM"
}
]
},
{
"package": {
"ecosystem": "Go",
"name": "github.com/aws/aws-sdk-go-v2/service/transcribestreaming"
},
"ranges": [
{
"events": [
{
"introduced": "0"
},
{
"fixed": "1.34.5"
}
],
"type": "ECOSYSTEM"
}
]
}
],
"aliases": [],
"database_specific": {
"cwe_ids": [
"CWE-20"
],
"github_reviewed": true,
"github_reviewed_at": "2026-04-08T00:18:56Z",
"nvd_published_at": null,
"severity": "MODERATE"
},
"details": "**CVSSv3.1 Rating**: [Medium]\n**CVSSv3.1 Score**: [5.9]\n**CVSSv3.1 Vector String**: [CVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:U/C:N/I:N/A:H]\n\n## Summary and Impact\nAn issue exists in the the EventStream header decoder in AWS SDK for Go v2 in versions predating [2026-03-23](https://github.com/aws/aws-sdk-go-v2/releases/tag/release-2026-03-23). An actor can send a malformed EventStream response frame containing a crafted header value type byte outside the valid range, which can cause the host process to terminate.\n\nImpacted versions: \u003c [2026-03-23](https://github.com/aws/aws-sdk-go-v2/releases/tag/release-2026-03-23)\n\n## Patches\nThis issue has been addressed in versions [2026-03-23](https://github.com/aws/aws-sdk-go-v2/releases/tag/release-2026-03-23) and above. We recommend upgrading to the latest version and ensuring any forked or derivative code is patched to incorporate the new fixes. \n\n## Workarounds\nNot Applicable\n\n## References\nIf you have any questions or comments about this advisory, we ask that you contact [AWS/Amazon] Security via our [vulnerability reporting page](https://aws.amazon.com/security/vulnerability-reporting) or directly via email to [aws-security@amazon.com](mailto:aws-security@amazon.com). Please do not create a public GitHub issue.",
"id": "GHSA-xmrv-pmrh-hhx2",
"modified": "2026-04-08T00:18:57Z",
"published": "2026-04-08T00:18:56Z",
"references": [
{
"type": "WEB",
"url": "https://github.com/aws/aws-sdk-go-v2/security/advisories/GHSA-xmrv-pmrh-hhx2"
},
{
"type": "PACKAGE",
"url": "https://github.com/aws/aws-sdk-go-v2"
},
{
"type": "WEB",
"url": "https://github.com/aws/aws-sdk-go-v2/releases/tag/release-2026-03-23"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:U/C:N/I:N/A:H",
"type": "CVSS_V3"
}
],
"summary": "Denial of Service due to Panic in AWS SDK for Go v2 SDK EventStream Decoder"
}
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.