{"id":"GHSA-mx64-mj3q-7prj","revision":null,"records":[{"revision":"f2ab53265c9747069961f40f7f2107d8","observedAt":"2026-10-24T13:19:41.952+00:00","statement":{"source":"osv","id":"GHSA-mx64-mj3q-7prj","aliases":["GO-2026-5048"],"title":"iskorotkov/avro: Denial-of-Service Vulnerability in Decoder","description":"# Memory Exhaustion via Unbounded Map Allocations in Avro Decoder\n\n## Summary\n\nThe Avro map decoder accepted attacker-controlled block-element counts from the wire format and grew the destination map without enforcing an upper bound. The slice decoder already had `Config.MaxSliceAllocSize` for the equivalent attack against arrays; the map decoder had no analogous limit, so a producer could declare an arbitrarily large map (in one block, or chunked across many sub-limit blocks) and exhaust process memory until the OOM killer fired.\n\nThe fix introduces `Config.MaxMapAllocSize` with cumulative enforcement across block boundaries. **The new limit is opt-in**: the field defaults to zero, which preserves the previous unbounded behavior for backward compatibility. **Upgrading to `v2.33.0` alone does not mitigate the issue** — consumers of untrusted Avro data must explicitly set `MaxMapAllocSize` on their `avro.Config`.\n\n## Description\n\nAvro maps are encoded as a sequence of blocks; each block declares a `long` element count followed by that many key/value pairs. The decoder uses these counts both to size the destination map and as the loop bound for reading entries.\n\nPre-fix, the map decoder enforced no upper limit at any layer:\n\n- No per-block element-count check.\n- No cumulative across-block element-count check.\n- No memory-budget check before `make(map[...]..., n)` or before growing the map.\n\nThe slice decoder had been hardened via `Config.MaxSliceAllocSize` and tracked cumulatively across blocks; the map decoder was a missing-by-symmetry gap. Even a partial per-block bound on maps would have been insufficient on its own — Avro permits encoding a logical map as many small blocks, so a producer could split a 10 GB map into 10,000 sub-MaxMapAllocSize blocks and still drive total allocation past any single-block threshold. The fix tracks cumulative entry count at block-header boundaries — *before* the block's entries are decoded into the map — and errors out before allocation when the running total would exceed the configured cap.\n\nTwo decoder variants were affected, both in `codec_map.go`:\n\n- `mapDecoder.Decode` — string-keyed maps.\n- `mapDecoderUnmarshaler.Decode` — `encoding.TextUnmarshaler`-keyed maps (e.g. `map[CustomKey]V` where `*CustomKey` implements `UnmarshalText`).\n\n## Affected components\n\n| File | Symbol | Pre-fix behavior | Post-fix behavior |\n|------|--------|------------------|-------------------|\n| `config.go` | `Config.MaxMapAllocSize` | Field did not exist | New `int` field; default zero means unlimited (back-compat) |\n| `codec_map.go` | `mapDecoder.Decode` | Read block count, grew map unbounded | Validates cumulative count against `MaxMapAllocSize` at each block header |\n| `codec_map.go` | `mapDecoderUnmarshaler.Decode` | Same | Same |\n\nPR [#5](https://github.com/iskorotkov/avro/pull/5) (`fix/map-alloc-chunking-bypass`) covers both decoders and adds chunking-attack tests for both. The same PR also adds the previously-missing chunking-attack test coverage for the slice path in `534c7518` — the slice *logic* was already correct, only its test coverage was incomplete.\n\n## Technical details\n\nThe fix mirrors the slice decoder's pattern:\n\n1. At each block header, read the element count as `int64`.\n2. Add it to a running total maintained across the block loop.\n3. If the running total exceeds `Config.MaxMapAllocSize` (when nonzero), return an error before allocating any of that block's entries.\n4. Otherwise, decode the block's entries into the map.\n\nPer-block enforcement alone would be bypassable by chunking; cumulative tracking closes that. The check sits at the block-header read, *before* per-entry allocation, so a single oversized block also cannot allocate first and then fail post-hoc.\n\n`Config.MaxMapAllocSize` semantics match `Config.MaxSliceAllocSize`: zero means unlimited, any positive value is the cumulative cap on element count (not byte size).\n\n## Fixed behavior\n\n`v2.33.0` adds the `MaxMapAllocSize` configuration field and the cumulative-enforcement logic in both map decoders. Both decoders return a descriptive error when the cumulative entry count would exceed the configured cap; no entries are allocated past the limit.\n\nTests added in PR #5 cover, for both `mapDecoder` and `mapDecoderUnmarshaler`:\n\n- Single-block allocation exceeding the limit (rejected before allocation).\n- Chunking attack: multiple sub-limit blocks whose cumulative count exceeds the limit (rejected at the block-header that crosses the threshold).\n- Multi-block under the limit (decoded normally).\n\n## Affected versions\n\n- `github.com/hamba/avro/v2` — all versions up to and including `v2.31.0` (repository is read-only upstream).\n- `github.com/iskorotkov/avro/v2` — all versions prior to `v2.33.0`. Note: `v2.33.0` and later are vulnerable *by default* and only protected when `MaxMapAllocSize` is explicitly configured — see Mitigation.\n\n## Fixed versions\n\n`github.com/iskorotkov/avro/v2` `v2.33.0` and later, **with `Config.MaxMapAllocSize` explicitly set to a non-zero value**.\n\nA bare upgrade to `v2.33.0` without setting `MaxMapAllocSize` leaves the decoder in the same unbounded state as `v2.32.0`. This is a backward-compatibility choice; a future major version may flip the default. Until then, treat this advisory as requiring both an upgrade *and* a configuration change.\n\nThere is no upstream fix for `github.com/hamba/avro/v2` — module path is archived. Migrate to the fork as described under Mitigation.\n\n## Mitigation\n\nMigrate from `github.com/hamba/avro/v2` to `github.com/iskorotkov/avro/v2 >= v2.33.0` **and** configure an allocation cap appropriate for your schema. The recommended approach for processes that decode untrusted input is a dedicated frozen config, used at every relevant call site, rather than mutating `avro.DefaultConfig`:\n\n```go\ncfg := avro.Config{\n    MaxByteSliceSize:  102_400,\n    MaxSliceAllocSize: 10_000,\n    MaxMapAllocSize:   10_000,\n}.Freeze()\n\ndecoder := cfg.NewDecoder(schema, reader)\n```\n\nChoose the values based on the largest legitimate map your schema produces; a value 2–10× that ceiling provides headroom for benign variance while still bounding worst-case memory.\n\nFor consumers that prefer the original import path, a `replace` directive in `go.mod` is supported:\n\n```\nreplace github.com/hamba/avro/v2 => github.com/iskorotkov/avro/v2 v2.33.0\n```\n\n`replace` is honoured only for the **main** module of a build — transitive consumers must add their own `replace`, or migrate the import path directly.\n\nIf you cannot upgrade immediately, the only structural workarounds are out-of-band: run decoders in memory-constrained child processes or cgroups so an OOM is contained, reject inputs from sources without resource controls, and apply per-request decode deadlines so a runaway decode at least times out before the OOM killer fires.\n\n## Proof-of-concept input\n\nTwo attack shapes, both targeting `map[string]int`:\n\n**Single-block, oversize block count.** Emit one block header declaring `n = 2³¹ − 1` (or any value whose `n × averageEntrySize` exceeds available memory) followed by truncated entries. Pre-fix, the decoder pre-allocates `make(map[string]int, n)`, which fails or stalls long before EOF is reached.\n\n**Chunking bypass.** Emit `k` blocks each declaring `n / k` elements, with `n / k` below any plausible per-block threshold but `n` itself well into the GB range. Pre-fix, the decoder happily grows the map block-by-block until the OS kills the process. Post-fix with `MaxMapAllocSize = 10_000`, the decoder rejects whichever block-header read pushes cumulative count past 10,000.\n\nEither shape can be produced by hand-crafting the wire bytes; no `iskorotkov/avro` writer is needed to generate them.\n\n## References\n\n- Fix PR: [iskorotkov/avro#5](https://github.com/iskorotkov/avro/pull/5)\n- Fix commit: [`5192df9`](https://github.com/iskorotkov/avro/commit/5192df96a158999344ac96ebcb1f7461d626f6d7) (`codec_map.go`, `config.go`, tests)\n- Slice-path chunking-attack test coverage added in the same PR: [`534c7518`](https://github.com/iskorotkov/avro/commit/534c7518152a893d8b4dea962669bd1123308a00)\n- Release: [`v2.33.0`](https://github.com/iskorotkov/avro/releases/tag/v2.33.0)\n- Security policy: [`SECURITY.md`](https://github.com/iskorotkov/avro/blob/main/SECURITY.md)\n- Related advisories on this fork: [`GHSA-mc57-h6j3-3hmv`](https://github.com/iskorotkov/avro/security/advisories/GHSA-mc57-h6j3-3hmv) (integer overflow), [`GHSA-w8j3-pq8g-8m7w`](https://github.com/iskorotkov/avro/security/advisories/GHSA-w8j3-pq8g-8m7w) (CPU exhaustion — the same chunked-payload shape may trigger both before allocation pressure kicks in)\n- Cross-module precedent on `hamba/avro`: [`GO-2023-1930`](https://pkg.go.dev/vuln/GO-2023-1930) / `CVE-2023-37475` / `GHSA-9x44-9pgq-cf45`\n- Upstream (read-only): [`hamba/avro`](https://github.com/hamba/avro)\n\n## Credits\n\n- **Fix author** (commit `5192df9`, PR #5 — `MaxMapAllocSize` config field, cumulative enforcement in both map decoders, chunking-attack tests for slices and maps): Ivan Korotkov ([@iskorotkov](https://github.com/iskorotkov))\n- **Review** (commit `a5fbddcb`, \"address review comments\"): Daniel Błażewicz ([@klajok](https://github.com/klajok))\n\n## Timeline\n\n- **2026-04-30** — `MaxMapAllocSize` introduced (`5192df9`); chunking-attack test coverage for slices added (`534c7518`).\n- **2026-05-01** — PR #5 merged into `main`.\n- **2026-05-06** — `v2.33.0` tagged and released.\n- **2026-05-07** — Advisory published.\n- **2026-05-15** — Advisory revised.","state":0,"publishedAt":"2026-05-18T12:59:58+00:00","modifiedAt":"2026-09-10T03:50:47.1051802+00:00","affected":[{"ecosystem":"Go","name":"github.com/iskorotkov/avro/v2","ranges":[{"type":"SEMVER","events":[{"kind":"introduced","version":"0"},{"kind":"fixed","version":"2.33.0"}]}],"versions":[],"rawVersionEvidence":null}],"metrics":[{"system":"CVSS_V3","vector":"CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H","score":null,"severity":null},{"system":"CVSS_V4","vector":"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","score":null,"severity":null},{"system":"Publisher rating","vector":null,"score":null,"severity":"HIGH"}],"references":["https://github.com/iskorotkov/avro/security/advisories/GHSA-mx64-mj3q-7prj","https://github.com/iskorotkov/avro"],"sourceUrl":"https://github.com/advisories/GHSA-mx64-mj3q-7prj","license":"GitHub Advisory Database · CC-BY-4.0","key":"osv:GHSA-mx64-mj3q-7prj","identifiers":["GHSA-mx64-mj3q-7prj","GO-2026-5048"]},"retained":false,"historicalAffected":[]},{"revision":"92048fbd21614f9ebad6ada35060bd3b","observedAt":"2026-10-24T13:19:41.952+00:00","statement":{"source":"osv","id":"GO-2026-5048","aliases":["GHSA-mx64-mj3q-7prj"],"title":"Denial of service via unbounded map allocations in github.com/iskorotkov/avro/v2 and github.com/hamba/avro/v2","description":"The Avro map decoder accepts attacker-controlled block-element counts from the wire format and grows the destination map without enforcing an upper bound. A producer can declare an arbitrarily large map (in one block, or chunked across many sub-limit blocks) and exhaust process memory until the OOM killer fires.\n\nThe fix introduces Config.MaxMapAllocSize with cumulative enforcement across block boundaries. The new limit is opt-in: the field defaults to zero, which preserves the previous unbounded behavior for backward compatibility. Upgrading to v2.33.0 alone does not mitigate the issue; consumers of untrusted Avro data must explicitly set MaxMapAllocSize on their avro.Config.","state":0,"publishedAt":"2026-07-27T16:16:22+00:00","modifiedAt":"2026-08-05T03:41:56.4672+00:00","affected":[{"ecosystem":"Go","name":"github.com/iskorotkov/avro/v2","ranges":[{"type":"SEMVER","events":[{"kind":"introduced","version":"0"},{"kind":"fixed","version":"2.33.0"}]}],"versions":[],"rawVersionEvidence":null},{"ecosystem":"Go","name":"github.com/hamba/avro/v2","ranges":[{"type":"SEMVER","events":[{"kind":"introduced","version":"0"}]}],"versions":[],"rawVersionEvidence":null}],"metrics":[],"references":["https://github.com/iskorotkov/avro/security/advisories/GHSA-mx64-mj3q-7prj","https://github.com/iskorotkov/avro/commit/5192df96a158999344ac96ebcb1f7461d626f6d7"],"sourceUrl":"https://osv.dev/vulnerability/GO-2026-5048","license":"OSV · upstream source license applies","key":"osv:GO-2026-5048","identifiers":["GO-2026-5048","GHSA-mx64-mj3q-7prj"]},"retained":false,"historicalAffected":[]}],"coverage":[{"source":"cisa-kev:global","scope":"Complete CISA KEV catalog; all vendors. Missing entries do not establish absence of exploitation.","generation":"2026-11-15T09:26:06.7525529+00:00","complete":true,"records":1781,"lastAttemptAt":"2026-11-15T09:26:06.7525529+00:00","lastSuccessAt":"2026-11-15T09:26:06.9410933+00:00","error":null,"lastVerifiedAt":"2026-11-15T09:26:06.941094+00:00","snapshotPublishedAt":null,"importing":false,"stagedRecords":0,"checkedIdentifiers":null,"expectedIdentifiers":null,"failedIdentifiers":null},{"source":"cve-program","scope":"Official CVE Program baseline and cumulative hourly delta; all vendors, published and rejected records","generation":"cve-7de4d7559a5263003f03d9f70577ab06f92ba4178309f26fce53e22a4a959294-9e3d838f79cf8ff38c78723122cff976bed4490ddcf297ed0587cd3b1d7c5b04","complete":true,"records":425783,"lastAttemptAt":"2026-11-15T09:26:06.228816+00:00","lastSuccessAt":"2026-11-15T09:26:06.1945365+00:00","error":null,"lastVerifiedAt":"2026-11-15T09:26:06.228816+00:00","snapshotPublishedAt":"2026-11-15T08:30:19+00:00","importing":false,"stagedRecords":0,"checkedIdentifiers":null,"expectedIdentifiers":null,"failedIdentifiers":null},{"source":"euvd","scope":"Rolling EUVD lookups of CVE aliases in current public OSV archives; 500 identifiers per refresh, rechecked after 48 hours. Not a global EUVD catalog. Successful not-found lookups count as checked; they do not imply withdrawal or safety. No reader inventory is sent.","generation":"enrichment-70bdd2599b1b4c169943a3485d3aa02c","complete":false,"records":13821,"lastAttemptAt":"2026-11-15T09:37:23.8744104+00:00","lastSuccessAt":"2026-11-15T09:37:24.3863422+00:00","error":null,"lastVerifiedAt":"2026-11-15T09:37:24.3863422+00:00","snapshotPublishedAt":null,"importing":false,"stagedRecords":0,"checkedIdentifiers":null,"expectedIdentifiers":null,"failedIdentifiers":null},{"source":"first-epss:nuget","scope":"FIRST EPSS for explicit CVE aliases in the collected public NuGet archive. Not a global EPSS backfill.","generation":"2026-11-15T09:26:06.7525529+00:00","complete":true,"records":1125,"lastAttemptAt":"2026-11-15T09:26:06.7525529+00:00","lastSuccessAt":"2026-11-15T09:26:06.9427316+00:00","error":null,"lastVerifiedAt":"2026-11-15T09:26:06.9427319+00:00","snapshotPublishedAt":null,"importing":false,"stagedRecords":0,"checkedIdentifiers":null,"expectedIdentifiers":null,"failedIdentifiers":null},{"source":"nvd","scope":"Rolling NVD lookups of CVE aliases in current public OSV archives; 500 identifiers per refresh, rechecked after 48 hours. Not a global NVD catalog. Successful not-found lookups count as checked; they do not imply withdrawal or safety. No reader inventory is sent.","generation":"enrichment-39f2794893ce49af81edbfe444e36bd6","complete":true,"records":13833,"lastAttemptAt":"2026-11-15T09:26:11.2401689+00:00","lastSuccessAt":"2026-11-15T08:26:34.303+00:00","error":null,"lastVerifiedAt":"2026-11-15T08:26:34.303+00:00","snapshotPublishedAt":null,"importing":false,"stagedRecords":0,"checkedIdentifiers":13874,"expectedIdentifiers":13874,"failedIdentifiers":0},{"source":"osv:Go","scope":"Complete OSV Go ecosystem archive, including withdrawn and malicious-package source records; statement counts are not unique CVE counts","generation":"go-64eea06dbd27de8464d5dbce1b78cc794cc59e2d901516ae0d3ea76e624cdae0","complete":true,"records":9955,"lastAttemptAt":"2026-11-15T09:26:06.4945342+00:00","lastSuccessAt":"2026-11-14T13:57:23.1208135+00:00","error":null,"lastVerifiedAt":"2026-11-15T09:26:06.4945342+00:00","snapshotPublishedAt":"2026-11-14T13:17:57+00:00","importing":false,"stagedRecords":0,"checkedIdentifiers":null,"expectedIdentifiers":null,"failedIdentifiers":null},{"source":"osv:NuGet","scope":"Complete OSV NuGet ecosystem archive, including GitHub Advisory Database records; NuGet version matching only","generation":"nuget-f4424d7d4861b1af1404bd15abcb83f295dcd003412a9340ca99dc8200aa148a","complete":true,"records":2014,"lastAttemptAt":"2026-11-15T09:26:06.2866573+00:00","lastSuccessAt":"2026-11-13T19:57:08.2864435+00:00","error":null,"lastVerifiedAt":"2026-11-15T09:26:06.2866573+00:00","snapshotPublishedAt":"2026-11-13T19:33:10+00:00","importing":false,"stagedRecords":0,"checkedIdentifiers":null,"expectedIdentifiers":null,"failedIdentifiers":null},{"source":"osv:crates.io","scope":"Complete OSV crates.io ecosystem archive, including withdrawn and malicious-package source records; statement counts are not unique CVE counts","generation":"crates.io-012aff9b2fb349d53e2c4bace6ca57956b6f5f9d82c1dc9fdc1c9b3c738f8977","complete":true,"records":3148,"lastAttemptAt":"2026-11-15T09:26:06.6048599+00:00","lastSuccessAt":"2026-11-14T04:57:03.8279646+00:00","error":null,"lastVerifiedAt":"2026-11-15T09:26:06.6048599+00:00","snapshotPublishedAt":"2026-11-14T03:02:50+00:00","importing":false,"stagedRecords":0,"checkedIdentifiers":null,"expectedIdentifiers":null,"failedIdentifiers":null},{"source":"osv:npm","scope":"Complete OSV npm ecosystem archive, including withdrawn and malicious-package source records; statement counts are not unique CVE counts","generation":"npm-878f718ccd076f540460423958c8e379b139b997b45858275573ecc4d702fe9a","complete":true,"records":232474,"lastAttemptAt":"2026-11-15T09:26:06.3921691+00:00","lastSuccessAt":"2026-11-15T05:33:06.8241102+00:00","error":null,"lastVerifiedAt":"2026-11-15T09:26:06.3921691+00:00","snapshotPublishedAt":"2026-11-15T04:33:08+00:00","importing":false,"stagedRecords":0,"checkedIdentifiers":null,"expectedIdentifiers":null,"failedIdentifiers":null}]}