{"id":"CVE-2026-46384","aliases":["EUVD-2026-33443","GHSA-mc57-h6j3-3hmv","GO-2026-5047","ROOT-APP-GOBINARY-CVE-2026-46384","SUSE-SU-2026:23216-1","SUSE-SU-2026:23227-1","openSUSE-SU-2026:21551-1"],"status":"published","title":"iskorotkov/avro: Integer Overflow in Avro Decoder","description":"iskorotkov/avro is a fast Go Avro codec. Prior to 2.33.0, several Avro decoder paths read attacker-controlled 64-bit values from the wire format and either narrowed them to platform-sized int before bounds-checking, or summed them with overflow-prone signed-int arithmetic. On 32-bit targets (GOARCH=386, arm, mips, wasm, etc.), the truncation paths can silently bypass byte-slice limits, select the wrong union branch, or hit the OCF negative-make panic via wrap. Three sub-issues are not 32-bit-specific: cumulative-size arithmetic overflow in arrayDecoder.Decode / mapDecoder.Decode / mapDecoderUnmarshaler.Decode (wraps at math.MaxInt64 on amd64 / arm64 and bypasses MaxSliceAllocSize / MaxMapAllocSize), math.MinInt negation in block-header handling, and make([]byte, size) with a negative size in OCF block reads — all three panic or bypass caps on any platform, giving an attacker a denial-of-service primitive there. This vulnerability is fixed in 2.33.0.","severity":{"version":"4.0","score":8.7,"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","level":"high","assessor":"cna","from":"cve"},"epss":{"day":"2026-11-11","score":0.00549,"percentile":0.46434,"model":"v2026.06.15"},"facts":{"in_kev":false,"known_exploited":false,"public_exploit":false,"fix_available":true},"cwes":["CWE-1284","CWE-190","CWE-191","CWE-681"],"published":"2026-05-18T16:22:27Z","modified":"2026-10-29T08:15:03Z","fixes":[{"ecosystem":"Go","package":"github.com/iskorotkov/avro/v2","fixed_in":["2.33.0"],"sources":["ghsa","osv"]},{"ecosystem":"Root:Go","package":"github.com/hamba/avro/v2","fixed_in":["v2.31.0-aikido.2"],"sources":["osv"]},{"ecosystem":"Root:Go","package":"rootio-github.com/hamba/avro/v2","fixed_in":["v2.31.0-root.io.2"],"sources":["osv"]}],"affected":[{"source":"ghsa","ecosystem":"Go","package":"github.com/iskorotkov/avro/v2","ranges":[{"type":"ECOSYSTEM","events":[{"introduced":"0"},{"fixed":"2.33.0"}]}]},{"source":"osv","ecosystem":"Go","package":"github.com/iskorotkov/avro/v2","ranges":[{"type":"SEMVER","events":[{"introduced":"0"},{"fixed":"2.33.0"}]}]},{"source":"osv","ecosystem":"Go","package":"github.com/iskorotkov/avro/v2","ranges":[{"type":"SEMVER","events":[{"introduced":"0"},{"fixed":"2.33.0"}]}]},{"source":"osv","ecosystem":"Go","package":"github.com/hamba/avro/v2","ranges":[{"type":"SEMVER","events":[{"introduced":"0"}]}]},{"source":"osv","ecosystem":"Root:Go","package":"github.com/hamba/avro/v2","ranges":[{"type":"ECOSYSTEM","events":[{"introduced":"0"},{"fixed":"v2.31.0-aikido.2"}]}]},{"source":"osv","ecosystem":"Root:Go","package":"rootio-github.com/hamba/avro/v2","ranges":[{"type":"ECOSYSTEM","events":[{"introduced":"0"},{"fixed":"v2.31.0-root.io.2"}]}]},{"source":"osv","ecosystem":"SUSE:Linux Enterprise Server 16.0","package":"govulncheck-vulndb","ranges":[{"type":"ECOSYSTEM","events":[{"introduced":"0"},{"fixed":"0.0.20260727T201416-160000.1.1"}]}],"bundled":77},{"source":"osv","ecosystem":"SUSE:Linux Enterprise Server for SAP applications 16.0","package":"govulncheck-vulndb","ranges":[{"type":"ECOSYSTEM","events":[{"introduced":"0"},{"fixed":"0.0.20260727T201416-160000.1.1"}]}],"bundled":77},{"source":"osv","ecosystem":"SUSE:Linux Enterprise Server 16.0","package":"govulncheck-vulndb","ranges":[{"type":"ECOSYSTEM","events":[{"introduced":"0"},{"fixed":"0.0.20260727T201416-160000.1.1"}]}],"bundled":77},{"source":"osv","ecosystem":"SUSE:Linux Enterprise Server for SAP applications 16.0","package":"govulncheck-vulndb","ranges":[{"type":"ECOSYSTEM","events":[{"introduced":"0"},{"fixed":"0.0.20260727T201416-160000.1.1"}]}],"bundled":77},{"source":"osv","ecosystem":"openSUSE:Leap 16.0","package":"govulncheck-vulndb","ranges":[{"type":"ECOSYSTEM","events":[{"introduced":"0"},{"fixed":"0.0.20260727T201416-160000.1.1"}]}],"bundled":77}],"products":[{"vendor":"hamba","product":"avro"},{"vendor":"iskorotkov","product":"avro"},{"vendor":"red hat","product":"cryostat 4 on rhel 9"},{"vendor":"red hat","product":"multicluster global hub 1.4.5"},{"vendor":"red hat","product":"multicluster global hub 1.6.5"},{"vendor":"red hat","product":"multicluster global hub 1.7.0"},{"vendor":"red hat","product":"red hat advanced cluster management for kubernetes 2.11"},{"vendor":"red hat","product":"red hat advanced cluster management for kubernetes 2.13"},{"vendor":"red hat","product":"red hat advanced cluster management for kubernetes 2.16"},{"vendor":"red hat","product":"red hat advanced cluster management for kubernetes 2.17"},{"vendor":"red hat","product":"red hat enterprise linux 10"},{"vendor":"red hat","product":"red hat enterprise linux 8"},{"vendor":"red hat","product":"red hat enterprise linux 9"},{"vendor":"red hat","product":"red hat hardened images"},{"vendor":"red hat","product":"red hat multicluster global hub 1.5.3"}],"references":[{"url":"https://github.com/iskorotkov/avro/security/advisories/GHSA-mc57-h6j3-3hmv","tags":["x_refsource_CONFIRM","advisory","web"]},{"url":"https://access.redhat.com/security/cve/CVE-2026-46384","tags":["vdb-entry","x_refsource_REDHAT","advisory"]},{"url":"https://bugzilla.redhat.com/show_bug.cgi?id=2483482","tags":["issue-tracking","x_refsource_REDHAT","report"]},{"url":"https://security.access.redhat.com/data/csaf/v2/vex/2026/cve-2026-46384.json","tags":["x_sadp-csaf-vex","web"]},{"url":"https://access.redhat.com/errata/RHSA-2026:48151","tags":["vendor-advisory","x_refsource_REDHAT","advisory"]},{"url":"https://access.redhat.com/errata/RHSA-2026:41030","tags":["vendor-advisory","x_refsource_REDHAT","advisory"]},{"url":"https://access.redhat.com/errata/RHSA-2026:44622","tags":["vendor-advisory","x_refsource_REDHAT","advisory"]},{"url":"https://access.redhat.com/errata/RHSA-2026:47149","tags":["vendor-advisory","x_refsource_REDHAT","advisory"]},{"url":"https://access.redhat.com/errata/RHSA-2026:53530","tags":["vendor-advisory","x_refsource_REDHAT","advisory"]},{"url":"https://access.redhat.com/errata/RHSA-2026:41064","tags":["vendor-advisory","x_refsource_REDHAT","advisory"]},{"url":"https://access.redhat.com/errata/RHSA-2026:30651","tags":["vendor-advisory","x_refsource_REDHAT","advisory"]},{"url":"https://access.redhat.com/errata/RHSA-2026:57191","tags":["vendor-advisory","x_refsource_REDHAT","advisory"]},{"url":"https://access.redhat.com/errata/RHSA-2026:60386","tags":["vendor-advisory","x_refsource_REDHAT","advisory"]},{"url":"https://access.redhat.com/errata/RHSA-2026:42852","tags":["vendor-advisory","x_refsource_REDHAT","advisory"]},{"url":"https://nvd.nist.gov/vuln/detail/CVE-2026-46384","tags":["advisory"]},{"url":"https://github.com/advisories/GHSA-mc57-h6j3-3hmv"},{"url":"https://github.com/CVEProject/cvelistV5/tree/main/cves/2026/46xxx/CVE-2026-46384.json","tags":["advisory"]},{"url":"https://github.com/iskorotkov/avro","tags":["package"]},{"url":"https://github.com/iskorotkov/avro/commit/bed99b315ec097a1a5eb7ae074ef57a91848c583","tags":["fix"]},{"url":"https://github.com/iskorotkov/avro/commit/e1a570f9a8a4fe4b1bc2b4b1fb6d24e4a5f04358","tags":["fix"]},{"url":"https://www.suse.com/support/update/announcement/2026/suse-su-202623216-1/","tags":["advisory"]},{"url":"https://www.suse.com/security/cve/CVE-2026-2303","tags":["web"]},{"url":"https://www.suse.com/security/cve/CVE-2026-23603","tags":["web"]},{"url":"https://www.suse.com/security/cve/CVE-2026-24451","tags":["web"]},{"url":"https://www.suse.com/security/cve/CVE-2026-25038","tags":["web"]},{"url":"https://www.suse.com/security/cve/CVE-2026-29181","tags":["web"]},{"url":"https://www.suse.com/security/cve/CVE-2026-30246","tags":["web"]},{"url":"https://www.suse.com/security/cve/CVE-2026-32952","tags":["web"]},{"url":"https://www.suse.com/security/cve/CVE-2026-34783","tags":["web"]},{"url":"https://www.suse.com/security/cve/CVE-2026-35204","tags":["web"]},{"url":"https://www.suse.com/security/cve/CVE-2026-35205","tags":["web"]},{"url":"https://www.suse.com/security/cve/CVE-2026-35206","tags":["web"]},{"url":"https://www.suse.com/security/cve/CVE-2026-37462","tags":["web"]},{"url":"https://www.suse.com/security/cve/CVE-2026-39883","tags":["web"]},{"url":"https://www.suse.com/security/cve/CVE-2026-40611","tags":["web"]},{"url":"https://www.suse.com/security/cve/CVE-2026-40890","tags":["web"]},{"url":"https://www.suse.com/security/cve/CVE-2026-41178","tags":["web"]},{"url":"https://www.suse.com/security/cve/CVE-2026-41506","tags":["web"]},{"url":"https://www.suse.com/security/cve/CVE-2026-41642","tags":["web"]},{"url":"https://www.suse.com/security/cve/CVE-2026-41643","tags":["web"]},{"url":"https://www.suse.com/security/cve/CVE-2026-42285","tags":["web"]},{"url":"https://www.suse.com/security/cve/CVE-2026-42306","tags":["web"]},{"url":"https://www.suse.com/security/cve/CVE-2026-42328","tags":["web"]},{"url":"https://www.suse.com/security/cve/CVE-2026-42554","tags":["web"]},{"url":"https://www.suse.com/security/cve/CVE-2026-42931","tags":["web"]},{"url":"https://www.suse.com/security/cve/CVE-2026-44166","tags":["web"]},{"url":"https://www.suse.com/security/cve/CVE-2026-44283","tags":["web"]},{"url":"https://www.suse.com/security/cve/CVE-2026-44301","tags":["web"]},{"url":"https://www.suse.com/security/cve/CVE-2026-44332","tags":["web"]},{"url":"https://www.suse.com/security/cve/CVE-2026-44517","tags":["web"]},{"url":"https://www.suse.com/security/cve/CVE-2026-44740","tags":["web"]},{"url":"https://www.suse.com/security/cve/CVE-2026-44973","tags":["web"]},{"url":"https://www.suse.com/security/cve/CVE-2026-45022","tags":["web"]},{"url":"https://www.suse.com/security/cve/CVE-2026-45045","tags":["web"]},{"url":"https://www.suse.com/security/cve/CVE-2026-45135","tags":["web"]},{"url":"https://www.suse.com/security/cve/CVE-2026-45571","tags":["web"]},{"url":"https://www.suse.com/security/cve/CVE-2026-46384","tags":["web"]},{"url":"https://www.suse.com/security/cve/CVE-2026-46385","tags":["web"]},{"url":"https://www.suse.com/security/cve/CVE-2026-48978","tags":["web"]},{"url":"https://www.suse.com/security/cve/CVE-2026-49837","tags":["web"]},{"url":"https://www.suse.com/security/cve/CVE-2026-49838","tags":["web"]},{"url":"https://www.suse.com/security/cve/CVE-2026-50151","tags":["web"]},{"url":"https://www.suse.com/security/cve/CVE-2026-50162","tags":["web"]},{"url":"https://www.suse.com/security/cve/CVE-2026-50163","tags":["web"]},{"url":"https://www.suse.com/security/cve/CVE-2026-50274","tags":["web"]},{"url":"https://www.suse.com/security/cve/CVE-2026-52844","tags":["web"]},{"url":"https://www.suse.com/security/cve/CVE-2026-52845","tags":["web"]},{"url":"https://www.suse.com/security/cve/CVE-2026-52846","tags":["web"]},{"url":"https://www.suse.com/security/cve/CVE-2026-53624","tags":["web"]},{"url":"https://www.suse.com/security/cve/CVE-2026-54063","tags":["web"]},{"url":"https://www.suse.com/security/cve/CVE-2026-54448","tags":["web"]},{"url":"https://www.suse.com/security/cve/CVE-2026-55982","tags":["web"]},{"url":"https://www.suse.com/security/cve/CVE-2026-55984","tags":["web"]},{"url":"https://www.suse.com/security/cve/CVE-2026-55987","tags":["web"]},{"url":"https://www.suse.com/security/cve/CVE-2026-56750","tags":["web"]},{"url":"https://www.suse.com/security/cve/CVE-2026-58417","tags":["web"]},{"url":"https://www.suse.com/security/cve/CVE-2026-58418","tags":["web"]},{"url":"https://www.suse.com/security/cve/CVE-2026-58421","tags":["web"]},{"url":"https://www.suse.com/security/cve/CVE-2026-58425","tags":["web"]},{"url":"https://www.suse.com/security/cve/CVE-2026-58426","tags":["web"]},{"url":"https://www.suse.com/security/cve/CVE-2026-58427","tags":["web"]},{"url":"https://www.suse.com/security/cve/CVE-2026-58431","tags":["web"]},{"url":"https://www.suse.com/security/cve/CVE-2026-58432","tags":["web"]},{"url":"https://www.suse.com/security/cve/CVE-2026-58434","tags":["web"]},{"url":"https://www.suse.com/security/cve/CVE-2026-58435","tags":["web"]},{"url":"https://www.suse.com/security/cve/CVE-2026-58438","tags":["web"]},{"url":"https://www.suse.com/security/cve/CVE-2026-58439","tags":["web"]},{"url":"https://www.suse.com/security/cve/CVE-2026-58441","tags":["web"]},{"url":"https://www.suse.com/security/cve/CVE-2026-58442","tags":["web"]},{"url":"https://www.suse.com/security/cve/CVE-2026-58443","tags":["web"]},{"url":"https://www.suse.com/security/cve/CVE-2026-58445","tags":["web"]},{"url":"https://www.suse.com/security/cve/CVE-2026-58507","tags":["web"]},{"url":"https://www.suse.com/security/cve/CVE-2026-58510","tags":["web"]},{"url":"https://www.suse.com/security/cve/CVE-2026-59766","tags":["web"]},{"url":"https://www.suse.com/security/cve/CVE-2026-6993","tags":["web"]},{"url":"https://www.suse.com/security/cve/CVE-2026-7020","tags":["web"]},{"url":"https://www.suse.com/security/cve/CVE-2026-7482","tags":["web"]},{"url":"https://www.suse.com/security/cve/CVE-2026-8276","tags":["web"]},{"url":"https://www.suse.com/support/update/announcement/2026/suse-su-202623227-1/","tags":["advisory"]},{"url":"","tags":["advisory"]}],"sources":{"cve":[{"id":"CVE-2026-46384","title":"iskorotkov/avro: Integer Overflow in Avro Decoder","description":"iskorotkov/avro is a fast Go Avro codec. Prior to 2.33.0, several Avro decoder paths read attacker-controlled 64-bit values from the wire format and either narrowed them to platform-sized int before bounds-checking, or summed them with overflow-prone signed-int arithmetic. On 32-bit targets (GOARCH=386, arm, mips, wasm, etc.), the truncation paths can silently bypass byte-slice limits, select the wrong union branch, or hit the OCF negative-make panic via wrap. Three sub-issues are not 32-bit-specific: cumulative-size arithmetic overflow in arrayDecoder.Decode / mapDecoder.Decode / mapDecoderUnmarshaler.Decode (wraps at math.MaxInt64 on amd64 / arm64 and bypasses MaxSliceAllocSize / MaxMapAllocSize), math.MinInt negation in block-header handling, and make([]byte, size) with a negative size in OCF block reads — all three panic or bypass caps on any platform, giving an attacker a denial-of-service primitive there. This vulnerability is fixed in 2.33.0.","status":"published","published":"2026-05-29T19:58:21.535Z","modified":"2026-09-09T12:04:43.443Z","cvss":[{"version":"4.0","score":8.7,"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","level":"high","assessor":"cna"},{"version":"3.1","score":7.5,"vector":"CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H","level":"high","assessor":"adp"}],"cwes":["CWE-190","CWE-190"],"updated_at":"2026-11-02T13:47:06.353366Z"}],"euvd":[{"id":"EUVD-2026-33443","description":"iskorotkov/avro is a fast Go Avro codec. Prior to 2.33.0, several Avro decoder paths read attacker-controlled 64-bit values from the wire format and either narrowed them to platform-sized int before bounds-checking, or summed them with overflow-prone signed-int arithmetic. On 32-bit targets (GOARCH=386, arm, mips, wasm, etc.), the truncation paths can silently bypass byte-slice limits, select the wrong union branch, or hit the OCF negative-make panic via wrap. Three sub-issues are not 32-bit-specific: cumulative-size arithmetic overflow in arrayDecoder.Decode / mapDecoder.Decode / mapDecoderUnmarshaler.Decode (wraps at math.MaxInt64 on amd64 / arm64 and bypasses MaxSliceAllocSize / MaxMapAllocSize), math.MinInt negation in block-header handling, and make([]byte, size) with a negative size in OCF block reads — all three panic or bypass caps on any platform, giving an attacker a denial-of-service primitive there. This vulnerability is fixed in 2.33.0.","status":"published","published":"2026-05-29T19:58:21Z","modified":"2026-09-09T12:04:43Z","cvss":[{"version":"4.0","score":8.7,"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","level":"high"}],"updated_at":"2026-11-02T17:28:27.763941Z"}],"ghsa":[{"id":"GHSA-mc57-h6j3-3hmv","title":"iskorotkov/avro: Integer Overflow in Decoder","description":"# Integer Overflow in Avro Decoder\n\n## Summary\n\nSeveral Avro decoder paths read attacker-controlled 64-bit values from the wire format and either narrowed them to platform-sized `int` before bounds-checking, or summed them with overflow-prone signed-`int` arithmetic. On 32-bit targets (`GOARCH=386`, `arm`, `mips`, `wasm`, etc.), the truncation paths can silently bypass byte-slice limits, select the wrong union branch, or hit the OCF negative-`make` panic via wrap. Three sub-issues are not 32-bit-specific: cumulative-size arithmetic overflow in `arrayDecoder.Decode` / `mapDecoder.Decode` / `mapDecoderUnmarshaler.Decode` (wraps at `math.MaxInt64` on amd64 / arm64 and bypasses `MaxSliceAllocSize` / `MaxMapAllocSize`), `math.MinInt` negation in block-header handling, and `make([]byte, size)` with a negative size in OCF block reads — all three panic or bypass caps on any platform, giving an attacker a denial-of-service primitive there.\n\nExploitation requires only an untrusted Avro stream. No primitives reach beyond denial-of-service on current code paths; see the union-index discussion below for a caveat.\n\n\n## Description\n\nSix call sites in the decoder accepted `int64` values from the Avro wire format and converted to `int` before validation. On a 32-bit build any wire value with magnitude `≥ 2³¹` truncates and the post-conversion value bears no useful relationship to the original. A value of `(1\u003c\u003c32) + 5` narrows to `5`; `1\u003c\u003c32` narrows to `0`; values just past `MaxInt32` narrow to large negatives.\n\nThis is distinct from the existing `Config.MaxSliceAllocSize`, `Config.MaxByteSliceSize`, and the new `Config.MaxMapAllocSize` limits, because narrowing happens *before* the limit comparison — the limit sees the truncated value, not the original wire value, so the cap is bypassed.\n\nThree further sub-issues are not 32-bit-specific:\n\n- `arrayDecoder.Decode`, `mapDecoder.Decode`, and `mapDecoderUnmarshaler.Decode` summed attacker-controlled block lengths via `size += int(l)` and then checked `size \u003e limit`. On amd64 / arm64 the running total wraps at `math.MaxInt64`; the post-wrap negative value passes the `\u003e limit` check, and the decoder proceeds. Regression test: `TestDecoder_ArrayMultiBlockExceedsMaxInt` uses `math.MaxInt − 2` for the second block's count and a `MaxSliceAllocSize` of 13 to demonstrate this on amd64. The Avro block-count field is a signed `long` on the wire, so block counts up to `math.MaxInt64` are admissible — there is no implicit 2³¹ ceiling.\n- `ReadBlockHeader()` returns the absolute value of negative block lengths; the negation is unsafe for `math.MinInt`, which on every platform panics on overflow.\n- `ocf/ocf.go readBlock()` passes the decoded block size directly to `make([]byte, size)`. A negative wire value panics on every platform; on 32-bit, values `\u003e MaxInt32` additionally panic via the narrowing path.\n\n## Affected components\n\n| File | Function(s) | Bug class | Platforms |\n|------|-------------|-----------|-----------|\n| `reader.go` | `ReadBlockHeader` — narrowing | Narrowing | 32-bit |\n| `reader.go` | `ReadBlockHeader` — `-math.MinInt` | Signed overflow (CWE-191) | all |\n| `reader.go` | `readBytes` (via `Reader.ReadBytes`, `Reader.ReadString`) | Narrowing | 32-bit |\n| `reader_skip.go` | `SkipString`, `SkipBytes` (and OCF skip path) | Narrowing | 32-bit |\n| `codec_array.go` | `arrayDecoder.Decode` | Cumulative-size arithmetic overflow (CWE-190) | all |\n| `codec_map.go` | `mapDecoder.Decode`, `mapDecoderUnmarshaler.Decode` | Cumulative-size arithmetic overflow (CWE-190) | all |\n| `ocf/ocf.go` | `skipToEnd`, `readBlock` — narrowing | Narrowing | 32-bit |\n| `ocf/ocf.go` | `readBlock` — negative `make([]byte, …)` | Unchecked-negative (CWE-1284) | all |\n| `reader_generic.go` | union-type index decoding in `Reader.ReadNext` | Narrowing, possible wrong-branch selection | 32-bit |\n\nPR #9 (commit [`bed99b3`](https://github.com/iskorotkov/avro/commit/bed99b315ec097a1a5eb7ae074ef57a91848c583)) covered `ReadBlockHeader`, the cumulative checks in array/map codecs, and the skip helpers. The completeness pass (commit [`e1a570f`](https://github.com/iskorotkov/avro/commit/e1a570f9a8a4fe4b1bc2b4b1fb6d24e4a5f04358)) covered the union index, `readBytes`, and OCF `readBlock`, and added a 32-bit CI job.\n\nNote: the typed-codec union decoder in `codec_union.go` (`getUnionSchema` → `Reader.ReadInt`) is **not** affected by the union-index narrowing — `ReadInt` returns `int32`, no narrowing occurs. The narrowing is specific to `Reader.ReadNext` in the generic decode path (reached via `Unmarshal` into `any` / `map[string]any`).\n\n## Technical details\n\n1. **Block-header narrowing and `MinInt` negation.** `ReadBlockHeader()` returned wire-format `int64` values through narrower operations; on 32-bit, large positives truncated. Negating `math.MinInt` to convert a negative block-count signal into a positive size is undefined-on-overflow, and on every platform `-MinInt` panics on overflow when used in subsequent arithmetic. The fix reads into a `*64`-suffixed local, range-checks against `MinInt32`/`MaxInt32` (or `MinInt`/`MaxInt` as appropriate), and narrows after validation.\n\n2. **Cumulative array and map size overflow (all platforms).** `arrayDecoder.Decode`, `mapDecoder.Decode`, and `mapDecoderUnmarshaler.Decode` summed attacker-controlled block lengths using overflow-prone addition; cumulative size could wrap before reaching the configured limit. On amd64 with `MaxSliceAllocSize = 13`, block 1 of 3 elements, block 2 of `math.MaxInt − 2` elements: the pre-fix `size += int(l)` wraps to `math.MinInt`, then `MinInt \u003e 13` is false, so the check passes and the decoder proceeds. The fix uses subtraction-safe comparisons (`l \u003e limit - size` rather than `size + l \u003e limit`), which is overflow-immune.\n\n3. **Skip-length truncation.** `SkipString`, `SkipBytes`, and the OCF skip helper now route through `SkipNBytesInt64()`, which keeps the length as `int64` and range-checks before any narrowing.\n\n4. **Byte-slice length truncation.** A wire-format length such as `(1\u003c\u003c32) + 5` truncated to `5` in `readBytes()`, slipping past `Config.MaxByteSliceSize` on 32-bit. The fix reads the length as `int64`, compares against `MaxByteSliceSize` before narrowing, and returns \"value is too big\" if exceeded.\n\n5. **Union index narrowing (generic decode path only).** `Reader.ReadNext` decoded the union index as `int64` and immediately cast to `int`. On 32-bit, `1\u003c\u003c32` narrowed to `0` and silently selected `types[0]` despite the explicit upper-bound check immediately above. If `types[0]` is the null branch (idiomatic for `[\"null\", T]` nullable unions), the practical result is a null value where the producer encoded a non-null payload — a DoS-grade logic error. If `types[0]` is a non-trivial schema, downstream bytes are parsed against the wrong schema and produce well-typed but semantically wrong values; treat this as the worst-case interpretation when assessing impact on your own deployment. The typed-codec union decoder (`codec_union.go` `getUnionSchema` → `Reader.ReadInt`) is not affected.\n\n6. **OCF block-size narrowing and negative `make`.** `readBlock()` passes the decoded `int64` size directly to `make([]byte, size)`. A negative wire value panics on every platform; a value `\u003e MaxInt32` additionally panics via the 32-bit narrowing path. The fix validates the size is in `[0, MaxByteSliceSize]` before narrowing.\n\n## Fixed behavior\n\nBoth commits apply the same pattern across every site:\n\n1. Read the wire value into an `int64`-typed local.\n2. Range-check upper and lower bounds before narrowing.\n3. Compare cumulative limits using subtraction-safe arithmetic.\n4. Route skip operations through `SkipNBytesInt64()`.\n5. Return descriptive errors using the consistent `\"value is too big\"` / `\"value is too small\"` wording.\n6. Cast to `int` only after validation succeeds.\n\nCI: a `test-386` job runs the suite under `GOARCH=386` with `CGO_ENABLED=0` (`-race` is amd64/arm64-only). Three tests with untyped `2147483648` constants whose `t.Skipf` gates fire too late (the file fails to compile before any test runs) were split into sibling `*_64bit_test.go` files gated by `//go:build amd64 || arm64 || ...`.\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`.\n\n## Fixed versions\n\n`github.com/iskorotkov/avro/v2` `v2.33.0` and later. There 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 \u003e= v2.33.0`. The packages share the same API surface; replace the import path and run `go mod tidy`:\n\n```diff\n- import \"github.com/hamba/avro/v2\"\n+ import \"github.com/iskorotkov/avro/v2\"\n```\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 =\u003e 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\nNo further configuration is required to benefit from the integer-narrowing fixes — the validation runs on the existing decode path.\n\nIf you cannot upgrade immediately:\n\n- Do not decode untrusted Avro data on any platform — the cumulative-arithmetic overflow paths (`arrayDecoder.Decode`, `mapDecoder.Decode`, `mapDecoderUnmarshaler.Decode`) are reachable on amd64 / arm64. The truncation paths on 32-bit cannot be mitigated by setting `Config.MaxByteSliceSize` lower, because the truncated post-narrowing value is what the limit sees, not the original wire value.\n- For the cross-platform `math.MinInt` and OCF negative-size panic paths, wrapping `Decode` / OCF read calls in a goroutine with `defer recover()` contains the crash, but is not a substitute for upgrading. The other narrowing paths return errors rather than panicking, so `recover()` does nothing for them.\n- Isolate decoding workers so a crash is bounded.\n\n## Proof-of-concept inputs\n\n- A `bytes` or `string` length of `(1\u003c\u003c32) + N` for small `N`, which narrows to `N` on 32-bit and bypasses `Config.MaxByteSliceSize`.\n- A union index of `1\u003c\u003c32`, which narrows to `0` on 32-bit and selects `types[0]` despite the upper-bound check.\n- An array or map encoded across multiple blocks whose cumulative element count wraps the signed `int` running total before the limit check fires. Demonstrated on amd64 by `TestDecoder_ArrayMultiBlockExceedsMaxInt`: `MaxSliceAllocSize = 13`, block 1 of `3`, block 2 of `math.MaxInt − 2`. Wraps to `math.MinInt`, check passes, decoder proceeds.\n- A block header whose absolute value is `math.MinInt`, triggering the unsafe negation (cross-platform).\n- An OCF block size that is negative on the wire, causing `make([]byte, size)` to panic (cross-platform); or a positive value `\u003e MaxInt32` on 32-bit, same outcome via narrowing.\n\n## References\n\n- Initial hardening PR: [iskorotkov/avro#9](https://github.com/iskorotkov/avro/pull/9)\n- Completeness pass PR: [iskorotkov/avro#10](https://github.com/iskorotkov/avro/pull/10)\n- Fix commits: [`bed99b3`](https://github.com/iskorotkov/avro/commit/bed99b315ec097a1a5eb7ae074ef57a91848c583), [`e1a570f`](https://github.com/iskorotkov/avro/commit/e1a570f9a8a4fe4b1bc2b4b1fb6d24e4a5f04358)\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-w8j3-pq8g-8m7w`](https://github.com/iskorotkov/avro/security/advisories/GHSA-w8j3-pq8g-8m7w) (CPU exhaustion — overlaps via the same large-block-count payload shape), [`GHSA-mx64-mj3q-7prj`](https://github.com/iskorotkov/avro/security/advisories/GHSA-mx64-mj3q-7prj) (unbounded map allocation)\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- **Discovery and initial fixes** (PR #9, commit `bed99b3` — `ReadBlockHeader`, cumulative array/map checks, skip helpers): Daniel Błażewicz ([@klajok](https://github.com/klajok))\n- **Completeness fixes** (commit `e1a570f` — union index, `readBytes`, OCF `readBlock`, 32-bit CI coverage): Ivan Korotkov ([@iskorotkov](https://github.com/iskorotkov))\n\n## Timeline\n\n- **2026-05-04** — Initial integer-overflow hardening (PR #9, `bed99b3`) merged.\n- **2026-05-04** — Completeness pass (`e1a570f`) merged; 32-bit CI job added.\n- **2026-05-06** — `v2.33.0` tagged and released.\n- **2026-05-11** — Advisory published.\n- **2026-05-15** — Advisory revised.","status":"published","published":"2026-05-18T16:22:27Z","modified":"2026-06-09T10:32:44Z","cvss":[{"version":"4.0","score":8.2,"vector":"CVSS:4.0/AV:N/AC:L/AT:P/PR:N/UI:N/VC:N/VI:N/VA:H/SC:N/SI:N/SA:N","level":"high"},{"version":"3.1","score":7.5,"vector":"CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H","level":"high"}],"cwes":["CWE-190","CWE-191","CWE-681","CWE-1284"],"updated_at":"2026-11-02T14:40:23.739691Z"}],"nvd":[{"id":"CVE-2026-46384","description":"iskorotkov/avro is a fast Go Avro codec. Prior to 2.33.0, several Avro decoder paths read attacker-controlled 64-bit values from the wire format and either narrowed them to platform-sized int before bounds-checking, or summed them with overflow-prone signed-int arithmetic. On 32-bit targets (GOARCH=386, arm, mips, wasm, etc.), the truncation paths can silently bypass byte-slice limits, select the wrong union branch, or hit the OCF negative-make panic via wrap. Three sub-issues are not 32-bit-specific: cumulative-size arithmetic overflow in arrayDecoder.Decode / mapDecoder.Decode / mapDecoderUnmarshaler.Decode (wraps at math.MaxInt64 on amd64 / arm64 and bypasses MaxSliceAllocSize / MaxMapAllocSize), math.MinInt negation in block-header handling, and make([]byte, size) with a negative size in OCF block reads — all three panic or bypass caps on any platform, giving an attacker a denial-of-service primitive there. This vulnerability is fixed in 2.33.0.","status":"published","published":"2026-05-29T20:16:27.847Z","modified":"2026-09-09T13:20:17.007Z","cvss":[{"version":"4.0","score":8.7,"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/E:X/CR:X/IR:X/AR:X/MAV:X/MAC:X/MAT:X/MPR:X/MUI:X/MVC:X/MVI:X/MVA:X/MSC:X/MSI:X/MSA:X/S:X/AU:X/R:X/V:X/RE:X/U:X","level":"high","assessor":"secondary"},{"version":"3.1","score":7.5,"vector":"CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H","level":"high","assessor":"secondary"}],"cwes":["CWE-190"],"updated_at":"2026-11-02T14:12:21.635958Z"}],"osv":[{"id":"CVE-2026-46384","title":"iskorotkov/avro: Integer Overflow in Avro Decoder","description":"iskorotkov/avro is a fast Go Avro codec. Prior to 2.33.0, several Avro decoder paths read attacker-controlled 64-bit values from the wire format and either narrowed them to platform-sized int before bounds-checking, or summed them with overflow-prone signed-int arithmetic. On 32-bit targets (GOARCH=386, arm, mips, wasm, etc.), the truncation paths can silently bypass byte-slice limits, select the wrong union branch, or hit the OCF negative-make panic via wrap. Three sub-issues are not 32-bit-specific: cumulative-size arithmetic overflow in arrayDecoder.Decode / mapDecoder.Decode / mapDecoderUnmarshaler.Decode (wraps at math.MaxInt64 on amd64 / arm64 and bypasses MaxSliceAllocSize / MaxMapAllocSize), math.MinInt negation in block-header handling, and make([]byte, size) with a negative size in OCF block reads — all three panic or bypass caps on any platform, giving an attacker a denial-of-service primitive there. This vulnerability is fixed in 2.33.0.","status":"published","published":"2026-05-29T19:58:21.535Z","modified":"2026-10-28T02:31:02.509755036Z","cvss":[{"version":"4.0","score":8.7,"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","level":"high"}],"cwes":["CWE-190"],"updated_at":"2026-11-02T15:45:05.870292Z"},{"id":"GHSA-mc57-h6j3-3hmv","title":"iskorotkov/avro: Integer Overflow in Decoder","description":"# Integer Overflow in Avro Decoder\n\n## Summary\n\nSeveral Avro decoder paths read attacker-controlled 64-bit values from the wire format and either narrowed them to platform-sized `int` before bounds-checking, or summed them with overflow-prone signed-`int` arithmetic. On 32-bit targets (`GOARCH=386`, `arm`, `mips`, `wasm`, etc.), the truncation paths can silently bypass byte-slice limits, select the wrong union branch, or hit the OCF negative-`make` panic via wrap. Three sub-issues are not 32-bit-specific: cumulative-size arithmetic overflow in `arrayDecoder.Decode` / `mapDecoder.Decode` / `mapDecoderUnmarshaler.Decode` (wraps at `math.MaxInt64` on amd64 / arm64 and bypasses `MaxSliceAllocSize` / `MaxMapAllocSize`), `math.MinInt` negation in block-header handling, and `make([]byte, size)` with a negative size in OCF block reads — all three panic or bypass caps on any platform, giving an attacker a denial-of-service primitive there.\n\nExploitation requires only an untrusted Avro stream. No primitives reach beyond denial-of-service on current code paths; see the union-index discussion below for a caveat.\n\n\n## Description\n\nSix call sites in the decoder accepted `int64` values from the Avro wire format and converted to `int` before validation. On a 32-bit build any wire value with magnitude `≥ 2³¹` truncates and the post-conversion value bears no useful relationship to the original. A value of `(1\u003c\u003c32) + 5` narrows to `5`; `1\u003c\u003c32` narrows to `0`; values just past `MaxInt32` narrow to large negatives.\n\nThis is distinct from the existing `Config.MaxSliceAllocSize`, `Config.MaxByteSliceSize`, and the new `Config.MaxMapAllocSize` limits, because narrowing happens *before* the limit comparison — the limit sees the truncated value, not the original wire value, so the cap is bypassed.\n\nThree further sub-issues are not 32-bit-specific:\n\n- `arrayDecoder.Decode`, `mapDecoder.Decode`, and `mapDecoderUnmarshaler.Decode` summed attacker-controlled block lengths via `size += int(l)` and then checked `size \u003e limit`. On amd64 / arm64 the running total wraps at `math.MaxInt64`; the post-wrap negative value passes the `\u003e limit` check, and the decoder proceeds. Regression test: `TestDecoder_ArrayMultiBlockExceedsMaxInt` uses `math.MaxInt − 2` for the second block's count and a `MaxSliceAllocSize` of 13 to demonstrate this on amd64. The Avro block-count field is a signed `long` on the wire, so block counts up to `math.MaxInt64` are admissible — there is no implicit 2³¹ ceiling.\n- `ReadBlockHeader()` returns the absolute value of negative block lengths; the negation is unsafe for `math.MinInt`, which on every platform panics on overflow.\n- `ocf/ocf.go readBlock()` passes the decoded block size directly to `make([]byte, size)`. A negative wire value panics on every platform; on 32-bit, values `\u003e MaxInt32` additionally panic via the narrowing path.\n\n## Affected components\n\n| File | Function(s) | Bug class | Platforms |\n|------|-------------|-----------|-----------|\n| `reader.go` | `ReadBlockHeader` — narrowing | Narrowing | 32-bit |\n| `reader.go` | `ReadBlockHeader` — `-math.MinInt` | Signed overflow (CWE-191) | all |\n| `reader.go` | `readBytes` (via `Reader.ReadBytes`, `Reader.ReadString`) | Narrowing | 32-bit |\n| `reader_skip.go` | `SkipString`, `SkipBytes` (and OCF skip path) | Narrowing | 32-bit |\n| `codec_array.go` | `arrayDecoder.Decode` | Cumulative-size arithmetic overflow (CWE-190) | all |\n| `codec_map.go` | `mapDecoder.Decode`, `mapDecoderUnmarshaler.Decode` | Cumulative-size arithmetic overflow (CWE-190) | all |\n| `ocf/ocf.go` | `skipToEnd`, `readBlock` — narrowing | Narrowing | 32-bit |\n| `ocf/ocf.go` | `readBlock` — negative `make([]byte, …)` | Unchecked-negative (CWE-1284) | all |\n| `reader_generic.go` | union-type index decoding in `Reader.ReadNext` | Narrowing, possible wrong-branch selection | 32-bit |\n\nPR #9 (commit [`bed99b3`](https://github.com/iskorotkov/avro/commit/bed99b315ec097a1a5eb7ae074ef57a91848c583)) covered `ReadBlockHeader`, the cumulative checks in array/map codecs, and the skip helpers. The completeness pass (commit [`e1a570f`](https://github.com/iskorotkov/avro/commit/e1a570f9a8a4fe4b1bc2b4b1fb6d24e4a5f04358)) covered the union index, `readBytes`, and OCF `readBlock`, and added a 32-bit CI job.\n\nNote: the typed-codec union decoder in `codec_union.go` (`getUnionSchema` → `Reader.ReadInt`) is **not** affected by the union-index narrowing — `ReadInt` returns `int32`, no narrowing occurs. The narrowing is specific to `Reader.ReadNext` in the generic decode path (reached via `Unmarshal` into `any` / `map[string]any`).\n\n## Technical details\n\n1. **Block-header narrowing and `MinInt` negation.** `ReadBlockHeader()` returned wire-format `int64` values through narrower operations; on 32-bit, large positives truncated. Negating `math.MinInt` to convert a negative block-count signal into a positive size is undefined-on-overflow, and on every platform `-MinInt` panics on overflow when used in subsequent arithmetic. The fix reads into a `*64`-suffixed local, range-checks against `MinInt32`/`MaxInt32` (or `MinInt`/`MaxInt` as appropriate), and narrows after validation.\n\n2. **Cumulative array and map size overflow (all platforms).** `arrayDecoder.Decode`, `mapDecoder.Decode`, and `mapDecoderUnmarshaler.Decode` summed attacker-controlled block lengths using overflow-prone addition; cumulative size could wrap before reaching the configured limit. On amd64 with `MaxSliceAllocSize = 13`, block 1 of 3 elements, block 2 of `math.MaxInt − 2` elements: the pre-fix `size += int(l)` wraps to `math.MinInt`, then `MinInt \u003e 13` is false, so the check passes and the decoder proceeds. The fix uses subtraction-safe comparisons (`l \u003e limit - size` rather than `size + l \u003e limit`), which is overflow-immune.\n\n3. **Skip-length truncation.** `SkipString`, `SkipBytes`, and the OCF skip helper now route through `SkipNBytesInt64()`, which keeps the length as `int64` and range-checks before any narrowing.\n\n4. **Byte-slice length truncation.** A wire-format length such as `(1\u003c\u003c32) + 5` truncated to `5` in `readBytes()`, slipping past `Config.MaxByteSliceSize` on 32-bit. The fix reads the length as `int64`, compares against `MaxByteSliceSize` before narrowing, and returns \"value is too big\" if exceeded.\n\n5. **Union index narrowing (generic decode path only).** `Reader.ReadNext` decoded the union index as `int64` and immediately cast to `int`. On 32-bit, `1\u003c\u003c32` narrowed to `0` and silently selected `types[0]` despite the explicit upper-bound check immediately above. If `types[0]` is the null branch (idiomatic for `[\"null\", T]` nullable unions), the practical result is a null value where the producer encoded a non-null payload — a DoS-grade logic error. If `types[0]` is a non-trivial schema, downstream bytes are parsed against the wrong schema and produce well-typed but semantically wrong values; treat this as the worst-case interpretation when assessing impact on your own deployment. The typed-codec union decoder (`codec_union.go` `getUnionSchema` → `Reader.ReadInt`) is not affected.\n\n6. **OCF block-size narrowing and negative `make`.** `readBlock()` passes the decoded `int64` size directly to `make([]byte, size)`. A negative wire value panics on every platform; a value `\u003e MaxInt32` additionally panics via the 32-bit narrowing path. The fix validates the size is in `[0, MaxByteSliceSize]` before narrowing.\n\n## Fixed behavior\n\nBoth commits apply the same pattern across every site:\n\n1. Read the wire value into an `int64`-typed local.\n2. Range-check upper and lower bounds before narrowing.\n3. Compare cumulative limits using subtraction-safe arithmetic.\n4. Route skip operations through `SkipNBytesInt64()`.\n5. Return descriptive errors using the consistent `\"value is too big\"` / `\"value is too small\"` wording.\n6. Cast to `int` only after validation succeeds.\n\nCI: a `test-386` job runs the suite under `GOARCH=386` with `CGO_ENABLED=0` (`-race` is amd64/arm64-only). Three tests with untyped `2147483648` constants whose `t.Skipf` gates fire too late (the file fails to compile before any test runs) were split into sibling `*_64bit_test.go` files gated by `//go:build amd64 || arm64 || ...`.\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`.\n\n## Fixed versions\n\n`github.com/iskorotkov/avro/v2` `v2.33.0` and later. There 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 \u003e= v2.33.0`. The packages share the same API surface; replace the import path and run `go mod tidy`:\n\n```diff\n- import \"github.com/hamba/avro/v2\"\n+ import \"github.com/iskorotkov/avro/v2\"\n```\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 =\u003e 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\nNo further configuration is required to benefit from the integer-narrowing fixes — the validation runs on the existing decode path.\n\nIf you cannot upgrade immediately:\n\n- Do not decode untrusted Avro data on any platform — the cumulative-arithmetic overflow paths (`arrayDecoder.Decode`, `mapDecoder.Decode`, `mapDecoderUnmarshaler.Decode`) are reachable on amd64 / arm64. The truncation paths on 32-bit cannot be mitigated by setting `Config.MaxByteSliceSize` lower, because the truncated post-narrowing value is what the limit sees, not the original wire value.\n- For the cross-platform `math.MinInt` and OCF negative-size panic paths, wrapping `Decode` / OCF read calls in a goroutine with `defer recover()` contains the crash, but is not a substitute for upgrading. The other narrowing paths return errors rather than panicking, so `recover()` does nothing for them.\n- Isolate decoding workers so a crash is bounded.\n\n## Proof-of-concept inputs\n\n- A `bytes` or `string` length of `(1\u003c\u003c32) + N` for small `N`, which narrows to `N` on 32-bit and bypasses `Config.MaxByteSliceSize`.\n- A union index of `1\u003c\u003c32`, which narrows to `0` on 32-bit and selects `types[0]` despite the upper-bound check.\n- An array or map encoded across multiple blocks whose cumulative element count wraps the signed `int` running total before the limit check fires. Demonstrated on amd64 by `TestDecoder_ArrayMultiBlockExceedsMaxInt`: `MaxSliceAllocSize = 13`, block 1 of `3`, block 2 of `math.MaxInt − 2`. Wraps to `math.MinInt`, check passes, decoder proceeds.\n- A block header whose absolute value is `math.MinInt`, triggering the unsafe negation (cross-platform).\n- An OCF block size that is negative on the wire, causing `make([]byte, size)` to panic (cross-platform); or a positive value `\u003e MaxInt32` on 32-bit, same outcome via narrowing.\n\n## References\n\n- Initial hardening PR: [iskorotkov/avro#9](https://github.com/iskorotkov/avro/pull/9)\n- Completeness pass PR: [iskorotkov/avro#10](https://github.com/iskorotkov/avro/pull/10)\n- Fix commits: [`bed99b3`](https://github.com/iskorotkov/avro/commit/bed99b315ec097a1a5eb7ae074ef57a91848c583), [`e1a570f`](https://github.com/iskorotkov/avro/commit/e1a570f9a8a4fe4b1bc2b4b1fb6d24e4a5f04358)\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-w8j3-pq8g-8m7w`](https://github.com/iskorotkov/avro/security/advisories/GHSA-w8j3-pq8g-8m7w) (CPU exhaustion — overlaps via the same large-block-count payload shape), [`GHSA-mx64-mj3q-7prj`](https://github.com/iskorotkov/avro/security/advisories/GHSA-mx64-mj3q-7prj) (unbounded map allocation)\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- **Discovery and initial fixes** (PR #9, commit `bed99b3` — `ReadBlockHeader`, cumulative array/map checks, skip helpers): Daniel Błażewicz ([@klajok](https://github.com/klajok))\n- **Completeness fixes** (commit `e1a570f` — union index, `readBytes`, OCF `readBlock`, 32-bit CI coverage): Ivan Korotkov ([@iskorotkov](https://github.com/iskorotkov))\n\n## Timeline\n\n- **2026-05-04** — Initial integer-overflow hardening (PR #9, `bed99b3`) merged.\n- **2026-05-04** — Completeness pass (`e1a570f`) merged; 32-bit CI job added.\n- **2026-05-06** — `v2.33.0` tagged and released.\n- **2026-05-11** — Advisory published.\n- **2026-05-15** — Advisory revised.","status":"published","published":"2026-05-18T16:22:27Z","modified":"2026-09-10T03:51:06.405674412Z","cvss":[{"version":"3.1","score":7.5,"vector":"CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H","level":"high"},{"version":"4.0","score":8.2,"vector":"CVSS:4.0/AV:N/AC:L/AT:P/PR:N/UI:N/VC:N/VI:N/VA:H/SC:N/SI:N/SA:N","level":"high"}],"cwes":["CWE-1284","CWE-190","CWE-191","CWE-681"],"updated_at":"2026-11-02T15:46:51.811331Z"},{"id":"GO-2026-5047","title":"Integer overflow in Avro decoder in github.com/iskorotkov/avro/v2 and github.com/hamba/avro/v2","description":"Several Avro decoder paths read attacker-controlled 64-bit values from the wire format and either narrowed them to platform-sized int before bounds-checking, or summed them with overflow-prone signed-int arithmetic. On 32-bit targets, the truncation paths can silently bypass byte-slice limits, select the wrong union branch, or hit a negative-make panic via wrap.\n\nThree sub-issues are not 32-bit-specific: cumulative-size arithmetic overflow in array and map decoders, negation of MinInt in block-header handling, and negative size in block reads. All three panic or bypass caps on any platform, giving an attacker a denial-of-service primitive. Exploitation requires only an untrusted Avro stream.","status":"published","published":"2026-07-27T16:16:22Z","modified":"2026-08-05T03:41:56.388939483Z","updated_at":"2026-11-02T15:47:02.280725Z"},{"id":"openSUSE-SU-2026:21551-1","title":"Security update for govulncheck-vulndb","description":"This update for govulncheck-vulndb fixes the following issues:\n\n- Update to version 0.0.20260727T201416 2026-07-27T20:14:16Z (jsc#PED-11136):\n\n Go CVE Numbering Authority IDs added or updated with aliases:\n * GO-2026-5046 CVE-2026-46385 GHSA-w8j3-pq8g-8m7w\n * GO-2026-5047 CVE-2026-46384 GHSA-mc57-h6j3-3hmv\n * GO-2026-5048 GHSA-mx64-mj3q-7prj\n * GO-2026-5051\n * GO-2026-5069 CVE-2026-30246 GHSA-35hp-hqmv-8qg8\n * GO-2026-5074 CVE-2026-45022 GHSA-389r-gv7p-r3rp\n * GO-2026-5105 CVE-2026-41506 GHSA-3xc5-wrhm-f963\n * GO-2026-5116 CVE-2026-44517 GHSA-49p4-px3h-rq49\n * GO-2026-5158 CVE-2026-41178 GHSA-5wrp-cwcj-q835\n * GO-2026-5198 CVE-2026-41642 GHSA-7235-89m6-f4px\n * GO-2026-5208 CVE-2026-40890 GHSA-77fj-vx54-gvh7\n * GO-2026-5266 CVE-2026-41643 GHSA-8rxh-r2p6-7f2q\n * GO-2026-5309 GHSA-c3wq-j5vh-68rc\n * GO-2026-5327 CVE-2026-2303 GHSA-cp6g-7hqx-qxhp\n * GO-2026-5336 CVE-2026-45571 GHSA-crhj-59gh-8x96\n * GO-2026-5346 CVE-2026-52845 GHSA-f59h-q822-g45g\n * GO-2026-5408 GHSA-gx7w-56w6-g48x\n * GO-2026-5426 CVE-2026-39883 GHSA-hfvc-g4fc-pqhx\n * GO-2026-5435 CVE-2026-35206 GHSA-hr2v-4r36-88hr\n * GO-2026-5452 CVE-2026-34783 GHSA-j6v5-g24h-vg4j\n * GO-2026-5463 CVE-2026-8276 GHSA-jcqv-2g3v-gm88\n * GO-2026-5471 CVE-2026-6993 GHSA-jj45-xvq5-rhh9\n * GO-2026-5490 CVE-2026-44740 GHSA-m3xc-h892-ggx6\n * GO-2026-5492 CVE-2026-45135 GHSA-m675-2p33-xv9g\n * GO-2026-5506 CVE-2026-29181 GHSA-mh2q-q3fh-2475\n * GO-2026-5525 CVE-2026-42285 GHSA-p3w2-64xm-833j\n * GO-2026-5543 CVE-2026-32952 GHSA-pjcq-xvwq-hhpj\n * GO-2026-5548 CVE-2026-44166 GHSA-pq7p-mc74-g65w\n * GO-2026-5566 CVE-2026-35205 GHSA-q5jf-9vfq-h4h7\n * GO-2026-5569 GHSA-q76j-gcg9-vxc6\n * GO-2026-5585 CVE-2026-42554 GHSA-qjv7-627w-8qjv\n * GO-2026-5593 CVE-2026-40611 GHSA-qqx8-2xmm-jrv8\n * GO-2026-5595 CVE-2026-52844 GHSA-qrp7-cvwr-j2c6\n * GO-2026-5597 CVE-2026-44973 GHSA-qw64-3x98-g7q2\n * GO-2026-5606 GHSA-r46f-3rpw-hxrv\n * GO-2026-5617 CVE-2026-42306 GHSA-rg2x-37c3-w2rh\n * GO-2026-5660 CVE-2026-52846 GHSA-vcc4-2c75-vc9v\n * GO-2026-5666 CVE-2026-35204 GHSA-vmx8-mqv2-9gmg\n * GO-2026-5684 CVE-2026-42328 GHSA-w239-58x2-q8p5\n * GO-2026-5693 GHSA-w5pp-99ch-qj29\n * GO-2026-5730 GHSA-wwhq-w58m-w29c\n * GO-2026-5736 CVE-2026-44283 GHSA-x35m-3gp4-4fh5\n * GO-2026-5740 CVE-2026-44301 GHSA-x597-9fr4-5857\n * GO-2026-5748 CVE-2026-7482 GHSA-x8qc-fggm-mpqg\n * GO-2026-5750 CVE-2026-7020 GHSA-x99g-8v8j-25j2\n * GO-2026-5774 GHSA-3fxj-6jh8-hvhx\n * GO-2026-5775 GHSA-9g5q-2w5x-hmxf\n * GO-2026-5777 GHSA-rjr7-jggh-pgcp\n * GO-2026-5781\n * GO-2026-5841 GHSA-259r-337f-4rfw\n * GO-2026-5879 CVE-2026-50162 GHSA-8xwf-rjm4-xvhv\n * GO-2026-5880 CVE-2026-50163 GHSA-fxhp-mv3v-67qp\n * GO-2026-5882 CVE-2026-50151 GHSA-jxpm-75mh-9fp7\n * GO-2026-5884 GHSA-vh4v-2xq2-g5cg\n * GO-2026-5885 CVE-2026-48978 GHSA-xf85-363p-868w\n * GO-2026-5886 CVE-2026-44332 GHSA-g5vh-55hw-rxm8\n * GO-2026-5887 CVE-2026-45045 GHSA-gcfq-8gqf-4876\n * GO-2026-5912 CVE-2026-53624 GHSA-gv83-gqw6-9j2c\n * GO-2026-5954 CVE-2026-49838 GHSA-frrj-87jh-2772\n * GO-2026-5955 CVE-2026-49837 GHSA-gjrg-jjr3-56cm\n * GO-2026-5960 CVE-2026-54063 GHSA-h69g-9hx6-f3v4\n * GO-2026-5971 CVE-2026-37462 GHSA-pw7p-7fqv-hpj8\n * GO-2026-5983 CVE-2026-54448 GHSA-q3fv-x8vg-qqm4\n * GO-2026-6000 CVE-2026-50274 GHSA-74j5-xf3v-crq8\n * GO-2026-6058 CVE-2026-58442 GHSA-h2x6-g7q6-344v\n * GO-2026-6059 CVE-2026-58431 GHSA-h56g-4qw7-2mxg\n * GO-2026-6060 CVE-2026-58426 GHSA-hg5r-vq93-9fv6\n * GO-2026-6061 GHSA-hrxh-6v49-42gf\n * GO-2026-6062 CVE-2026-58434 GHSA-j2w3-9c3r-g83q\n * GO-2026-6063 CVE-2026-58417 GHSA-jr5x-6h83-wrxf\n * GO-2026-6064 CVE-2026-55984 GHSA-m932-crvm-gcp5\n * GO-2026-6065 CVE-2026-55982 GHSA-mg4f-x9v4-6h2p\n * GO-2026-6066 CVE-2026-58507 GHSA-p4mj-98mv-xq26\n * GO-2026-6067 CVE-2026-58445 GHSA-pgqf-926r-548m\n * GO-2026-6068 CVE-2026-58427 GHSA-prr9-9mp4-5gp2\n * GO-2026-6069 CVE-2026-58510 GHSA-q423-49rw-g9mh\n * GO-2026-6070 CVE-2026-58432 GHSA-q9pg-jj6x-j9p6\n * GO-2026-6071 CVE-2026-59766 GHSA-qf2f-qh6p-7v89\n * GO-2026-6072 CVE-2026-56750 GHSA-rgv6-xp99-6mgj\n * GO-2026-6073 CVE-2026-58435 GHSA-rh79-75qm-gwjr\n * GO-2026-6074 GHSA-rjvx-x5h2-6px5\n * GO-2026-6075 CVE-2026-58418 GHSA-rqhx-647v-wx32\n * GO-2026-6076 CVE-2026-25038 GHSA-v73x-hx65-6pf4\n * GO-2026-6077 CVE-2026-58421 GHSA-v96j-25gv-g2w9\n * GO-2026-6078 CVE-2026-55987 GHSA-vrhc-jjfc-m3m3\n * GO-2026-6079 CVE-2026-58425 GHSA-vxv2-8j6r-pcpg\n * GO-2026-6080 CVE-2026-58439 GHSA-w5pg-649r-p6gg\n * GO-2026-6081 CVE-2026-24451 GHSA-wrf9-r3h7-7x5v\n * GO-2026-6082 CVE-2026-42931 GHSA-wwqq-x6w4-frm2\n * GO-2026-6083 CVE-2026-23603 GHSA-x77v-q46j-393g\n * GO-2026-6084 CVE-2026-58441 GHSA-xmj7-xj85-hfc3\n * GO-2026-6085 CVE-2026-58438 GHSA-xv9x-fj9g-vj6h\n * GO-2026-6086 CVE-2026-58443 GHSA-xxjv-752h-3vp2\n","status":"published","published":"2026-08-10T17:38:07Z","modified":"2026-08-12T18:23:41.809969353Z","updated_at":"2026-11-02T16:58:41.885092Z"},{"id":"ROOT-APP-GOBINARY-CVE-2026-46384","title":"CVE-2026-46384 in github.com/hamba/avro/v2 - Patched by Root","description":"Root has patched CVE-2026-46384 in the github.com/hamba/avro/v2 package for Root:Go. Multiple fixed versions available.","status":"published","published":"2026-10-29T07:30:17Z","modified":"2026-10-29T08:15:03.151083826Z","updated_at":"2026-11-02T15:53:26.76659Z"},{"id":"SUSE-SU-2026:23216-1","title":"Security update for govulncheck-vulndb","description":"This update for govulncheck-vulndb fixes the following issues:\n\n- Update to version 0.0.20260727T201416 2026-07-27T20:14:16Z (jsc#PED-11136):\n\n Go CVE Numbering Authority IDs added or updated with aliases:\n * GO-2026-5046 CVE-2026-46385 GHSA-w8j3-pq8g-8m7w\n * GO-2026-5047 CVE-2026-46384 GHSA-mc57-h6j3-3hmv\n * GO-2026-5048 GHSA-mx64-mj3q-7prj\n * GO-2026-5051\n * GO-2026-5069 CVE-2026-30246 GHSA-35hp-hqmv-8qg8\n * GO-2026-5074 CVE-2026-45022 GHSA-389r-gv7p-r3rp\n * GO-2026-5105 CVE-2026-41506 GHSA-3xc5-wrhm-f963\n * GO-2026-5116 CVE-2026-44517 GHSA-49p4-px3h-rq49\n * GO-2026-5158 CVE-2026-41178 GHSA-5wrp-cwcj-q835\n * GO-2026-5198 CVE-2026-41642 GHSA-7235-89m6-f4px\n * GO-2026-5208 CVE-2026-40890 GHSA-77fj-vx54-gvh7\n * GO-2026-5266 CVE-2026-41643 GHSA-8rxh-r2p6-7f2q\n * GO-2026-5309 GHSA-c3wq-j5vh-68rc\n * GO-2026-5327 CVE-2026-2303 GHSA-cp6g-7hqx-qxhp\n * GO-2026-5336 CVE-2026-45571 GHSA-crhj-59gh-8x96\n * GO-2026-5346 CVE-2026-52845 GHSA-f59h-q822-g45g\n * GO-2026-5408 GHSA-gx7w-56w6-g48x\n * GO-2026-5426 CVE-2026-39883 GHSA-hfvc-g4fc-pqhx\n * GO-2026-5435 CVE-2026-35206 GHSA-hr2v-4r36-88hr\n * GO-2026-5452 CVE-2026-34783 GHSA-j6v5-g24h-vg4j\n * GO-2026-5463 CVE-2026-8276 GHSA-jcqv-2g3v-gm88\n * GO-2026-5471 CVE-2026-6993 GHSA-jj45-xvq5-rhh9\n * GO-2026-5490 CVE-2026-44740 GHSA-m3xc-h892-ggx6\n * GO-2026-5492 CVE-2026-45135 GHSA-m675-2p33-xv9g\n * GO-2026-5506 CVE-2026-29181 GHSA-mh2q-q3fh-2475\n * GO-2026-5525 CVE-2026-42285 GHSA-p3w2-64xm-833j\n * GO-2026-5543 CVE-2026-32952 GHSA-pjcq-xvwq-hhpj\n * GO-2026-5548 CVE-2026-44166 GHSA-pq7p-mc74-g65w\n * GO-2026-5566 CVE-2026-35205 GHSA-q5jf-9vfq-h4h7\n * GO-2026-5569 GHSA-q76j-gcg9-vxc6\n * GO-2026-5585 CVE-2026-42554 GHSA-qjv7-627w-8qjv\n * GO-2026-5593 CVE-2026-40611 GHSA-qqx8-2xmm-jrv8\n * GO-2026-5595 CVE-2026-52844 GHSA-qrp7-cvwr-j2c6\n * GO-2026-5597 CVE-2026-44973 GHSA-qw64-3x98-g7q2\n * GO-2026-5606 GHSA-r46f-3rpw-hxrv\n * GO-2026-5617 CVE-2026-42306 GHSA-rg2x-37c3-w2rh\n * GO-2026-5660 CVE-2026-52846 GHSA-vcc4-2c75-vc9v\n * GO-2026-5666 CVE-2026-35204 GHSA-vmx8-mqv2-9gmg\n * GO-2026-5684 CVE-2026-42328 GHSA-w239-58x2-q8p5\n * GO-2026-5693 GHSA-w5pp-99ch-qj29\n * GO-2026-5730 GHSA-wwhq-w58m-w29c\n * GO-2026-5736 CVE-2026-44283 GHSA-x35m-3gp4-4fh5\n * GO-2026-5740 CVE-2026-44301 GHSA-x597-9fr4-5857\n * GO-2026-5748 CVE-2026-7482 GHSA-x8qc-fggm-mpqg\n * GO-2026-5750 CVE-2026-7020 GHSA-x99g-8v8j-25j2\n * GO-2026-5774 GHSA-3fxj-6jh8-hvhx\n * GO-2026-5775 GHSA-9g5q-2w5x-hmxf\n * GO-2026-5777 GHSA-rjr7-jggh-pgcp\n * GO-2026-5781\n * GO-2026-5841 GHSA-259r-337f-4rfw\n * GO-2026-5879 CVE-2026-50162 GHSA-8xwf-rjm4-xvhv\n * GO-2026-5880 CVE-2026-50163 GHSA-fxhp-mv3v-67qp\n * GO-2026-5882 CVE-2026-50151 GHSA-jxpm-75mh-9fp7\n * GO-2026-5884 GHSA-vh4v-2xq2-g5cg\n * GO-2026-5885 CVE-2026-48978 GHSA-xf85-363p-868w\n * GO-2026-5886 CVE-2026-44332 GHSA-g5vh-55hw-rxm8\n * GO-2026-5887 CVE-2026-45045 GHSA-gcfq-8gqf-4876\n * GO-2026-5912 CVE-2026-53624 GHSA-gv83-gqw6-9j2c\n * GO-2026-5954 CVE-2026-49838 GHSA-frrj-87jh-2772\n * GO-2026-5955 CVE-2026-49837 GHSA-gjrg-jjr3-56cm\n * GO-2026-5960 CVE-2026-54063 GHSA-h69g-9hx6-f3v4\n * GO-2026-5971 CVE-2026-37462 GHSA-pw7p-7fqv-hpj8\n * GO-2026-5983 CVE-2026-54448 GHSA-q3fv-x8vg-qqm4\n * GO-2026-6000 CVE-2026-50274 GHSA-74j5-xf3v-crq8\n * GO-2026-6058 CVE-2026-58442 GHSA-h2x6-g7q6-344v\n * GO-2026-6059 CVE-2026-58431 GHSA-h56g-4qw7-2mxg\n * GO-2026-6060 CVE-2026-58426 GHSA-hg5r-vq93-9fv6\n * GO-2026-6061 GHSA-hrxh-6v49-42gf\n * GO-2026-6062 CVE-2026-58434 GHSA-j2w3-9c3r-g83q\n * GO-2026-6063 CVE-2026-58417 GHSA-jr5x-6h83-wrxf\n * GO-2026-6064 CVE-2026-55984 GHSA-m932-crvm-gcp5\n * GO-2026-6065 CVE-2026-55982 GHSA-mg4f-x9v4-6h2p\n * GO-2026-6066 CVE-2026-58507 GHSA-p4mj-98mv-xq26\n * GO-2026-6067 CVE-2026-58445 GHSA-pgqf-926r-548m\n * GO-2026-6068 CVE-2026-58427 GHSA-prr9-9mp4-5gp2\n * GO-2026-6069 CVE-2026-58510 GHSA-q423-49rw-g9mh\n * GO-2026-6070 CVE-2026-58432 GHSA-q9pg-jj6x-j9p6\n * GO-2026-6071 CVE-2026-59766 GHSA-qf2f-qh6p-7v89\n * GO-2026-6072 CVE-2026-56750 GHSA-rgv6-xp99-6mgj\n * GO-2026-6073 CVE-2026-58435 GHSA-rh79-75qm-gwjr\n * GO-2026-6074 GHSA-rjvx-x5h2-6px5\n * GO-2026-6075 CVE-2026-58418 GHSA-rqhx-647v-wx32\n * GO-2026-6076 CVE-2026-25038 GHSA-v73x-hx65-6pf4\n * GO-2026-6077 CVE-2026-58421 GHSA-v96j-25gv-g2w9\n * GO-2026-6078 CVE-2026-55987 GHSA-vrhc-jjfc-m3m3\n * GO-2026-6079 CVE-2026-58425 GHSA-vxv2-8j6r-pcpg\n * GO-2026-6080 CVE-2026-58439 GHSA-w5pg-649r-p6gg\n * GO-2026-6081 CVE-2026-24451 GHSA-wrf9-r3h7-7x5v\n * GO-2026-6082 CVE-2026-42931 GHSA-wwqq-x6w4-frm2\n * GO-2026-6083 CVE-2026-23603 GHSA-x77v-q46j-393g\n * GO-2026-6084 CVE-2026-58441 GHSA-xmj7-xj85-hfc3\n * GO-2026-6085 CVE-2026-58438 GHSA-xv9x-fj9g-vj6h\n * GO-2026-6086 CVE-2026-58443 GHSA-xxjv-752h-3vp2\n","status":"published","published":"2026-08-10T17:34:15Z","modified":"2026-08-27T18:23:09.233788558Z","updated_at":"2026-11-02T15:54:03.503431Z"},{"id":"SUSE-SU-2026:23227-1","title":"Security update for govulncheck-vulndb","description":"This update for govulncheck-vulndb fixes the following issues:\n\n- Update to version 0.0.20260727T201416 2026-07-27T20:14:16Z (jsc#PED-11136):\n\n Go CVE Numbering Authority IDs added or updated with aliases:\n * GO-2026-5046 CVE-2026-46385 GHSA-w8j3-pq8g-8m7w\n * GO-2026-5047 CVE-2026-46384 GHSA-mc57-h6j3-3hmv\n * GO-2026-5048 GHSA-mx64-mj3q-7prj\n * GO-2026-5051\n * GO-2026-5069 CVE-2026-30246 GHSA-35hp-hqmv-8qg8\n * GO-2026-5074 CVE-2026-45022 GHSA-389r-gv7p-r3rp\n * GO-2026-5105 CVE-2026-41506 GHSA-3xc5-wrhm-f963\n * GO-2026-5116 CVE-2026-44517 GHSA-49p4-px3h-rq49\n * GO-2026-5158 CVE-2026-41178 GHSA-5wrp-cwcj-q835\n * GO-2026-5198 CVE-2026-41642 GHSA-7235-89m6-f4px\n * GO-2026-5208 CVE-2026-40890 GHSA-77fj-vx54-gvh7\n * GO-2026-5266 CVE-2026-41643 GHSA-8rxh-r2p6-7f2q\n * GO-2026-5309 GHSA-c3wq-j5vh-68rc\n * GO-2026-5327 CVE-2026-2303 GHSA-cp6g-7hqx-qxhp\n * GO-2026-5336 CVE-2026-45571 GHSA-crhj-59gh-8x96\n * GO-2026-5346 CVE-2026-52845 GHSA-f59h-q822-g45g\n * GO-2026-5408 GHSA-gx7w-56w6-g48x\n * GO-2026-5426 CVE-2026-39883 GHSA-hfvc-g4fc-pqhx\n * GO-2026-5435 CVE-2026-35206 GHSA-hr2v-4r36-88hr\n * GO-2026-5452 CVE-2026-34783 GHSA-j6v5-g24h-vg4j\n * GO-2026-5463 CVE-2026-8276 GHSA-jcqv-2g3v-gm88\n * GO-2026-5471 CVE-2026-6993 GHSA-jj45-xvq5-rhh9\n * GO-2026-5490 CVE-2026-44740 GHSA-m3xc-h892-ggx6\n * GO-2026-5492 CVE-2026-45135 GHSA-m675-2p33-xv9g\n * GO-2026-5506 CVE-2026-29181 GHSA-mh2q-q3fh-2475\n * GO-2026-5525 CVE-2026-42285 GHSA-p3w2-64xm-833j\n * GO-2026-5543 CVE-2026-32952 GHSA-pjcq-xvwq-hhpj\n * GO-2026-5548 CVE-2026-44166 GHSA-pq7p-mc74-g65w\n * GO-2026-5566 CVE-2026-35205 GHSA-q5jf-9vfq-h4h7\n * GO-2026-5569 GHSA-q76j-gcg9-vxc6\n * GO-2026-5585 CVE-2026-42554 GHSA-qjv7-627w-8qjv\n * GO-2026-5593 CVE-2026-40611 GHSA-qqx8-2xmm-jrv8\n * GO-2026-5595 CVE-2026-52844 GHSA-qrp7-cvwr-j2c6\n * GO-2026-5597 CVE-2026-44973 GHSA-qw64-3x98-g7q2\n * GO-2026-5606 GHSA-r46f-3rpw-hxrv\n * GO-2026-5617 CVE-2026-42306 GHSA-rg2x-37c3-w2rh\n * GO-2026-5660 CVE-2026-52846 GHSA-vcc4-2c75-vc9v\n * GO-2026-5666 CVE-2026-35204 GHSA-vmx8-mqv2-9gmg\n * GO-2026-5684 CVE-2026-42328 GHSA-w239-58x2-q8p5\n * GO-2026-5693 GHSA-w5pp-99ch-qj29\n * GO-2026-5730 GHSA-wwhq-w58m-w29c\n * GO-2026-5736 CVE-2026-44283 GHSA-x35m-3gp4-4fh5\n * GO-2026-5740 CVE-2026-44301 GHSA-x597-9fr4-5857\n * GO-2026-5748 CVE-2026-7482 GHSA-x8qc-fggm-mpqg\n * GO-2026-5750 CVE-2026-7020 GHSA-x99g-8v8j-25j2\n * GO-2026-5774 GHSA-3fxj-6jh8-hvhx\n * GO-2026-5775 GHSA-9g5q-2w5x-hmxf\n * GO-2026-5777 GHSA-rjr7-jggh-pgcp\n * GO-2026-5781\n * GO-2026-5841 GHSA-259r-337f-4rfw\n * GO-2026-5879 CVE-2026-50162 GHSA-8xwf-rjm4-xvhv\n * GO-2026-5880 CVE-2026-50163 GHSA-fxhp-mv3v-67qp\n * GO-2026-5882 CVE-2026-50151 GHSA-jxpm-75mh-9fp7\n * GO-2026-5884 GHSA-vh4v-2xq2-g5cg\n * GO-2026-5885 CVE-2026-48978 GHSA-xf85-363p-868w\n * GO-2026-5886 CVE-2026-44332 GHSA-g5vh-55hw-rxm8\n * GO-2026-5887 CVE-2026-45045 GHSA-gcfq-8gqf-4876\n * GO-2026-5912 CVE-2026-53624 GHSA-gv83-gqw6-9j2c\n * GO-2026-5954 CVE-2026-49838 GHSA-frrj-87jh-2772\n * GO-2026-5955 CVE-2026-49837 GHSA-gjrg-jjr3-56cm\n * GO-2026-5960 CVE-2026-54063 GHSA-h69g-9hx6-f3v4\n * GO-2026-5971 CVE-2026-37462 GHSA-pw7p-7fqv-hpj8\n * GO-2026-5983 CVE-2026-54448 GHSA-q3fv-x8vg-qqm4\n * GO-2026-6000 CVE-2026-50274 GHSA-74j5-xf3v-crq8\n * GO-2026-6058 CVE-2026-58442 GHSA-h2x6-g7q6-344v\n * GO-2026-6059 CVE-2026-58431 GHSA-h56g-4qw7-2mxg\n * GO-2026-6060 CVE-2026-58426 GHSA-hg5r-vq93-9fv6\n * GO-2026-6061 GHSA-hrxh-6v49-42gf\n * GO-2026-6062 CVE-2026-58434 GHSA-j2w3-9c3r-g83q\n * GO-2026-6063 CVE-2026-58417 GHSA-jr5x-6h83-wrxf\n * GO-2026-6064 CVE-2026-55984 GHSA-m932-crvm-gcp5\n * GO-2026-6065 CVE-2026-55982 GHSA-mg4f-x9v4-6h2p\n * GO-2026-6066 CVE-2026-58507 GHSA-p4mj-98mv-xq26\n * GO-2026-6067 CVE-2026-58445 GHSA-pgqf-926r-548m\n * GO-2026-6068 CVE-2026-58427 GHSA-prr9-9mp4-5gp2\n * GO-2026-6069 CVE-2026-58510 GHSA-q423-49rw-g9mh\n * GO-2026-6070 CVE-2026-58432 GHSA-q9pg-jj6x-j9p6\n * GO-2026-6071 CVE-2026-59766 GHSA-qf2f-qh6p-7v89\n * GO-2026-6072 CVE-2026-56750 GHSA-rgv6-xp99-6mgj\n * GO-2026-6073 CVE-2026-58435 GHSA-rh79-75qm-gwjr\n * GO-2026-6074 GHSA-rjvx-x5h2-6px5\n * GO-2026-6075 CVE-2026-58418 GHSA-rqhx-647v-wx32\n * GO-2026-6076 CVE-2026-25038 GHSA-v73x-hx65-6pf4\n * GO-2026-6077 CVE-2026-58421 GHSA-v96j-25gv-g2w9\n * GO-2026-6078 CVE-2026-55987 GHSA-vrhc-jjfc-m3m3\n * GO-2026-6079 CVE-2026-58425 GHSA-vxv2-8j6r-pcpg\n * GO-2026-6080 CVE-2026-58439 GHSA-w5pg-649r-p6gg\n * GO-2026-6081 CVE-2026-24451 GHSA-wrf9-r3h7-7x5v\n * GO-2026-6082 CVE-2026-42931 GHSA-wwqq-x6w4-frm2\n * GO-2026-6083 CVE-2026-23603 GHSA-x77v-q46j-393g\n * GO-2026-6084 CVE-2026-58441 GHSA-xmj7-xj85-hfc3\n * GO-2026-6085 CVE-2026-58438 GHSA-xv9x-fj9g-vj6h\n * GO-2026-6086 CVE-2026-58443 GHSA-xxjv-752h-3vp2\n","status":"published","published":"2026-08-10T17:34:15Z","modified":"2026-08-27T18:23:10.174179412Z","updated_at":"2026-11-02T15:54:03.503431Z"}]}}