CWE-1284
AllowedImproper Validation of Specified Quantity in Input
Abstraction: Base · Status: Incomplete
The product receives input that is expected to specify a quantity (such as size or length), but it does not validate or incorrectly validates that the quantity has the required properties.
494 vulnerabilities reference this CWE, most recent first.
GHSA-M2V8-V989-39Q2
Vulnerability from github – Published: 2026-07-02 12:31 – Updated: 2026-07-02 12:31Unauthenticated Arbitrary Code Execution in W3 Total Cache <= 2.9.4 versions.
{
"affected": [],
"aliases": [
"CVE-2026-57623"
],
"database_specific": {
"cwe_ids": [
"CWE-1284"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2026-07-02T12:17:37Z",
"severity": "CRITICAL"
},
"details": "Unauthenticated Arbitrary Code Execution in W3 Total Cache \u003c= 2.9.4 versions.",
"id": "GHSA-m2v8-v989-39q2",
"modified": "2026-07-02T12:31:01Z",
"published": "2026-07-02T12:31:01Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-57623"
},
{
"type": "WEB",
"url": "https://patchstack.com/database/wordpress/plugin/w3-total-cache/vulnerability/wordpress-w3-total-cache-plugin-2-9-4-arbitrary-code-execution-vulnerability?_s_id=cve"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:C/C:H/I:H/A:H",
"type": "CVSS_V3"
}
]
}
GHSA-M4RJ-RPHF-266H
Vulnerability from github – Published: 2024-05-15 18:30 – Updated: 2024-05-15 18:30An improper access control was identified in the Identity Security Cloud (ISC) message server API that allowed an authenticated user to exfiltrate job processing metadata (opaque messageIDs, work queue depth and counts) for other tenants.
{
"affected": [],
"aliases": [
"CVE-2024-3317"
],
"database_specific": {
"cwe_ids": [
"CWE-1284"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2024-05-15T16:15:10Z",
"severity": "MODERATE"
},
"details": "An improper access control was identified in the Identity Security Cloud (ISC) message server API that allowed an authenticated user to exfiltrate job processing metadata (opaque messageIDs, work queue depth and counts) for other tenants.",
"id": "GHSA-m4rj-rphf-266h",
"modified": "2024-05-15T18:30:34Z",
"published": "2024-05-15T18:30:34Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-3317"
},
{
"type": "WEB",
"url": "https://www.sailpoint.com/security-advisories"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:H/I:N/A:N",
"type": "CVSS_V3"
}
]
}
GHSA-M6X2-4HHH-669J
Vulnerability from github – Published: 2026-06-23 18:31 – Updated: 2026-06-23 18:31CMS (Cryptographic Message Syntax) parsing in gpgsm in GnuPG through 2.5.20 mishandles the CMS format for AES-GCM because aes-ICVlen is supposed to be 12 bytes but 4 bytes is accepted. NOTE: this is related to CVE-2026-34182.
{
"affected": [],
"aliases": [
"CVE-2026-57062"
],
"database_specific": {
"cwe_ids": [
"CWE-1284"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2026-06-23T18:18:10Z",
"severity": "LOW"
},
"details": "CMS (Cryptographic Message Syntax) parsing in gpgsm in GnuPG through 2.5.20 mishandles the CMS format for AES-GCM because aes-ICVlen is supposed to be 12 bytes but 4 bytes is accepted. NOTE: this is related to CVE-2026-34182.",
"id": "GHSA-m6x2-4hhh-669j",
"modified": "2026-06-23T18:31:45Z",
"published": "2026-06-23T18:31:45Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-57062"
},
{
"type": "WEB",
"url": "https://blog.calif.io/p/how-to-format-a-ciphertext"
},
{
"type": "WEB",
"url": "https://www.gnupg.org/download"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:L/AC:H/PR:N/UI:N/S:U/C:N/I:L/A:N",
"type": "CVSS_V3"
}
]
}
GHSA-M8Q6-F6PJ-J3MH
Vulnerability from github – Published: 2025-09-12 06:30 – Updated: 2025-09-12 06:30An issue has been discovered in GitLab CE/EE affecting all versions from 7.12 before 18.1.6, 18.2 before 18.2.6, and 18.3 before 18.3.2 that could have allowed unauthorized users to render the GitLab instance unresponsive to legitimate users by sending multiple concurrent large SAML responses.
{
"affected": [],
"aliases": [
"CVE-2025-2256"
],
"database_specific": {
"cwe_ids": [
"CWE-1284"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2025-09-12T06:15:42Z",
"severity": "HIGH"
},
"details": "An issue has been discovered in GitLab CE/EE affecting all versions from 7.12 before 18.1.6, 18.2 before 18.2.6, and 18.3 before 18.3.2 that could have allowed unauthorized users to render the GitLab instance unresponsive to legitimate users by sending multiple concurrent large SAML responses.",
"id": "GHSA-m8q6-f6pj-j3mh",
"modified": "2025-09-12T06:30:26Z",
"published": "2025-09-12T06:30:26Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-2256"
},
{
"type": "WEB",
"url": "https://hackerone.com/reports/3019485"
},
{
"type": "WEB",
"url": "https://about.gitlab.com/releases/2025/09/10/patch-release-gitlab-18-3-2-released"
},
{
"type": "WEB",
"url": "https://gitlab.com/gitlab-org/gitlab/-/issues/524633"
}
],
"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"
}
]
}
GHSA-M8R5-J3FQ-HX58
Vulnerability from github – Published: 2022-01-04 00:00 – Updated: 2023-06-26 21:30ASUS RT-AX56U Wi-Fi Router is vulnerable to stack-based buffer overflow due to improper validation for httpd parameter length. An authenticated local area network attacker can launch arbitrary code execution to control the system or disrupt service.
{
"affected": [],
"aliases": [
"CVE-2021-44158"
],
"database_specific": {
"cwe_ids": [
"CWE-121",
"CWE-1284",
"CWE-787"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2022-01-03T10:15:00Z",
"severity": "HIGH"
},
"details": "ASUS RT-AX56U Wi-Fi Router is vulnerable to stack-based buffer overflow due to improper validation for httpd parameter length. An authenticated local area network attacker can launch arbitrary code execution to control the system or disrupt service.",
"id": "GHSA-m8r5-j3fq-hx58",
"modified": "2023-06-26T21:30:54Z",
"published": "2022-01-04T00:00:54Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2021-44158"
},
{
"type": "WEB",
"url": "https://www.twcert.org.tw/tw/cp-132-5431-d23be-1.html"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:A/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H",
"type": "CVSS_V3"
}
]
}
GHSA-M8WX-W8WV-8Q47
Vulnerability from github – Published: 2022-09-15 00:00 – Updated: 2024-09-25 12:30Improper Input Validation vulnerability exists in the Hitachi Energy MicroSCADA X SYS600's ICCP stack during the ICCP communication establishment causes a denial-of-service when ICCP of SYS600 is request to forward any data item updates with timestamps too distant in the future to any remote ICCP system. By default, ICCP is not configured and not enabled. This issue affects: Hitachi Energy MicroSCADA X SYS600 version 10.2 to version 10.3.1. cpe:2.3:a:hitachienergy:microscada_x_sys600:10.2::::::: cpe:2.3:a:hitachienergy:microscada_x_sys600:10.2.1::::::: cpe:2.3:a:hitachienergy:microscada_x_sys600:10.3::::::: cpe:2.3:a:hitachienergy:microscada_x_sys600:10.3.1:::::::
{
"affected": [],
"aliases": [
"CVE-2022-2277"
],
"database_specific": {
"cwe_ids": [
"CWE-1284",
"CWE-20"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2022-09-14T18:15:00Z",
"severity": "HIGH"
},
"details": "Improper Input Validation vulnerability exists in the Hitachi Energy MicroSCADA X SYS600\u0027s ICCP stack during the ICCP communication establishment causes a denial-of-service when ICCP of SYS600 is request to forward any data item updates with timestamps too distant in the future to any remote ICCP system. By default, ICCP is not configured and not enabled. This issue affects: Hitachi Energy MicroSCADA X SYS600 version 10.2 to version 10.3.1. cpe:2.3:a:hitachienergy:microscada_x_sys600:10.2:*:*:*:*:*:*:* cpe:2.3:a:hitachienergy:microscada_x_sys600:10.2.1:*:*:*:*:*:*:* cpe:2.3:a:hitachienergy:microscada_x_sys600:10.3:*:*:*:*:*:*:* cpe:2.3:a:hitachienergy:microscada_x_sys600:10.3.1:*:*:*:*:*:*:*",
"id": "GHSA-m8wx-w8wv-8q47",
"modified": "2024-09-25T12:30:39Z",
"published": "2022-09-15T00:00:16Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2022-2277"
},
{
"type": "WEB",
"url": "https://publisher.hitachienergy.com/preview?DocumentID=8DBD000106\u0026LanguageCode=en\u0026DocumentPartId=\u0026Action=Launch"
},
{
"type": "WEB",
"url": "https://publisher.hitachienergy.com/preview?DocumentId=8DBD000106\u0026languageCode=en\u0026Preview=true"
},
{
"type": "WEB",
"url": "https://search.abb.com/library/Download.aspx?DocumentID=8DBD000106\u0026LanguageCode=en\u0026DocumentPartId=\u0026Action=Launch"
}
],
"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"
}
]
}
GHSA-M95X-5WWW-9P45
Vulnerability from github – Published: 2025-02-25 21:31 – Updated: 2025-02-25 21:31NVIDIA CUDA toolkit for Linux and Windows contains a vulnerability in the cuobjdump binary, where a user could cause a crash by passing a malformed ELF file to cuobjdump. A successful exploit of this vulnerability might lead to a partial denial of service.
{
"affected": [],
"aliases": [
"CVE-2024-53878"
],
"database_specific": {
"cwe_ids": [
"CWE-1284"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2025-02-25T21:15:17Z",
"severity": "LOW"
},
"details": "NVIDIA CUDA toolkit for Linux and Windows contains a vulnerability in the cuobjdump binary, where a user could cause a crash by passing a malformed ELF file to cuobjdump. A successful exploit of this vulnerability might lead to a partial denial of service.",
"id": "GHSA-m95x-5www-9p45",
"modified": "2025-02-25T21:31:45Z",
"published": "2025-02-25T21:31:45Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-53878"
},
{
"type": "WEB",
"url": "https://nvidia.custhelp.com/app/answers/detail/a_id/5594"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:L/AC:L/PR:L/UI:R/S:U/C:N/I:N/A:L",
"type": "CVSS_V3"
}
]
}
GHSA-MC57-H6J3-3HMV
Vulnerability from github – Published: 2026-05-18 16:22 – Updated: 2026-06-09 10:32Integer Overflow in Avro Decoder
Summary
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.
Exploitation 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.
Description
Six 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<<32) + 5 narrows to 5; 1<<32 narrows to 0; values just past MaxInt32 narrow to large negatives.
This 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.
Three further sub-issues are not 32-bit-specific:
arrayDecoder.Decode,mapDecoder.Decode, andmapDecoderUnmarshaler.Decodesummed attacker-controlled block lengths viasize += int(l)and then checkedsize > limit. On amd64 / arm64 the running total wraps atmath.MaxInt64; the post-wrap negative value passes the> limitcheck, and the decoder proceeds. Regression test:TestDecoder_ArrayMultiBlockExceedsMaxIntusesmath.MaxInt − 2for the second block's count and aMaxSliceAllocSizeof 13 to demonstrate this on amd64. The Avro block-count field is a signedlongon the wire, so block counts up tomath.MaxInt64are admissible — there is no implicit 2³¹ ceiling.ReadBlockHeader()returns the absolute value of negative block lengths; the negation is unsafe formath.MinInt, which on every platform panics on overflow.ocf/ocf.go readBlock()passes the decoded block size directly tomake([]byte, size). A negative wire value panics on every platform; on 32-bit, values> MaxInt32additionally panic via the narrowing path.
Affected components
| File | Function(s) | Bug class | Platforms |
|---|---|---|---|
reader.go |
ReadBlockHeader — narrowing |
Narrowing | 32-bit |
reader.go |
ReadBlockHeader — -math.MinInt |
Signed overflow (CWE-191) | all |
reader.go |
readBytes (via Reader.ReadBytes, Reader.ReadString) |
Narrowing | 32-bit |
reader_skip.go |
SkipString, SkipBytes (and OCF skip path) |
Narrowing | 32-bit |
codec_array.go |
arrayDecoder.Decode |
Cumulative-size arithmetic overflow (CWE-190) | all |
codec_map.go |
mapDecoder.Decode, mapDecoderUnmarshaler.Decode |
Cumulative-size arithmetic overflow (CWE-190) | all |
ocf/ocf.go |
skipToEnd, readBlock — narrowing |
Narrowing | 32-bit |
ocf/ocf.go |
readBlock — negative make([]byte, …) |
Unchecked-negative (CWE-1284) | all |
reader_generic.go |
union-type index decoding in Reader.ReadNext |
Narrowing, possible wrong-branch selection | 32-bit |
PR #9 (commit bed99b3) covered ReadBlockHeader, the cumulative checks in array/map codecs, and the skip helpers. The completeness pass (commit e1a570f) covered the union index, readBytes, and OCF readBlock, and added a 32-bit CI job.
Note: 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).
Technical details
-
Block-header narrowing and
MinIntnegation.ReadBlockHeader()returned wire-formatint64values through narrower operations; on 32-bit, large positives truncated. Negatingmath.MinIntto convert a negative block-count signal into a positive size is undefined-on-overflow, and on every platform-MinIntpanics on overflow when used in subsequent arithmetic. The fix reads into a*64-suffixed local, range-checks againstMinInt32/MaxInt32(orMinInt/MaxIntas appropriate), and narrows after validation. -
Cumulative array and map size overflow (all platforms).
arrayDecoder.Decode,mapDecoder.Decode, andmapDecoderUnmarshaler.Decodesummed attacker-controlled block lengths using overflow-prone addition; cumulative size could wrap before reaching the configured limit. On amd64 withMaxSliceAllocSize = 13, block 1 of 3 elements, block 2 ofmath.MaxInt − 2elements: the pre-fixsize += int(l)wraps tomath.MinInt, thenMinInt > 13is false, so the check passes and the decoder proceeds. The fix uses subtraction-safe comparisons (l > limit - sizerather thansize + l > limit), which is overflow-immune. -
Skip-length truncation.
SkipString,SkipBytes, and the OCF skip helper now route throughSkipNBytesInt64(), which keeps the length asint64and range-checks before any narrowing. -
Byte-slice length truncation. A wire-format length such as
(1<<32) + 5truncated to5inreadBytes(), slipping pastConfig.MaxByteSliceSizeon 32-bit. The fix reads the length asint64, compares againstMaxByteSliceSizebefore narrowing, and returns "value is too big" if exceeded. -
Union index narrowing (generic decode path only).
Reader.ReadNextdecoded the union index asint64and immediately cast toint. On 32-bit,1<<32narrowed to0and silently selectedtypes[0]despite the explicit upper-bound check immediately above. Iftypes[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. Iftypes[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.gogetUnionSchema→Reader.ReadInt) is not affected. -
OCF block-size narrowing and negative
make.readBlock()passes the decodedint64size directly tomake([]byte, size). A negative wire value panics on every platform; a value> MaxInt32additionally panics via the 32-bit narrowing path. The fix validates the size is in[0, MaxByteSliceSize]before narrowing.
Fixed behavior
Both commits apply the same pattern across every site:
- Read the wire value into an
int64-typed local. - Range-check upper and lower bounds before narrowing.
- Compare cumulative limits using subtraction-safe arithmetic.
- Route skip operations through
SkipNBytesInt64(). - Return descriptive errors using the consistent
"value is too big"/"value is too small"wording. - Cast to
intonly after validation succeeds.
CI: 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 || ....
Affected versions
github.com/hamba/avro/v2— all versions up to and includingv2.31.0(repository is read-only upstream).github.com/iskorotkov/avro/v2— all versions prior tov2.33.0.
Fixed versions
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.
Mitigation
Migrate from github.com/hamba/avro/v2 to github.com/iskorotkov/avro/v2 >= v2.33.0. The packages share the same API surface; replace the import path and run go mod tidy:
- import "github.com/hamba/avro/v2"
+ import "github.com/iskorotkov/avro/v2"
For consumers that prefer the original import path, a replace directive in go.mod is supported:
replace github.com/hamba/avro/v2 => github.com/iskorotkov/avro/v2 v2.33.0
replace is honoured only for the main module of a build — transitive consumers must add their own replace, or migrate the import path directly.
No further configuration is required to benefit from the integer-narrowing fixes — the validation runs on the existing decode path.
If you cannot upgrade immediately:
- 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 settingConfig.MaxByteSliceSizelower, because the truncated post-narrowing value is what the limit sees, not the original wire value. - For the cross-platform
math.MinIntand OCF negative-size panic paths, wrappingDecode/ OCF read calls in a goroutine withdefer recover()contains the crash, but is not a substitute for upgrading. The other narrowing paths return errors rather than panicking, sorecover()does nothing for them. - Isolate decoding workers so a crash is bounded.
Proof-of-concept inputs
- A
bytesorstringlength of(1<<32) + Nfor smallN, which narrows toNon 32-bit and bypassesConfig.MaxByteSliceSize. - A union index of
1<<32, which narrows to0on 32-bit and selectstypes[0]despite the upper-bound check. - An array or map encoded across multiple blocks whose cumulative element count wraps the signed
intrunning total before the limit check fires. Demonstrated on amd64 byTestDecoder_ArrayMultiBlockExceedsMaxInt:MaxSliceAllocSize = 13, block 1 of3, block 2 ofmath.MaxInt − 2. Wraps tomath.MinInt, check passes, decoder proceeds. - A block header whose absolute value is
math.MinInt, triggering the unsafe negation (cross-platform). - An OCF block size that is negative on the wire, causing
make([]byte, size)to panic (cross-platform); or a positive value> MaxInt32on 32-bit, same outcome via narrowing.
References
- Initial hardening PR: iskorotkov/avro#9
- Completeness pass PR: iskorotkov/avro#10
- Fix commits:
bed99b3,e1a570f - Release:
v2.33.0 - Security policy:
SECURITY.md - Related advisories on this fork:
GHSA-w8j3-pq8g-8m7w(CPU exhaustion — overlaps via the same large-block-count payload shape),GHSA-mx64-mj3q-7prj(unbounded map allocation) - Cross-module precedent on
hamba/avro:GO-2023-1930/CVE-2023-37475/GHSA-9x44-9pgq-cf45 - Upstream (read-only):
hamba/avro
Credits
- Discovery and initial fixes (PR #9, commit
bed99b3—ReadBlockHeader, cumulative array/map checks, skip helpers): Daniel Błażewicz (@klajok) - Completeness fixes (commit
e1a570f— union index,readBytes, OCFreadBlock, 32-bit CI coverage): Ivan Korotkov (@iskorotkov)
Timeline
- 2026-05-04 — Initial integer-overflow hardening (PR #9,
bed99b3) merged. - 2026-05-04 — Completeness pass (
e1a570f) merged; 32-bit CI job added. - 2026-05-06 —
v2.33.0tagged and released. - 2026-05-11 — Advisory published.
- 2026-05-15 — Advisory revised.
{
"affected": [
{
"package": {
"ecosystem": "Go",
"name": "github.com/iskorotkov/avro/v2"
},
"ranges": [
{
"events": [
{
"introduced": "0"
},
{
"fixed": "2.33.0"
}
],
"type": "ECOSYSTEM"
}
]
}
],
"aliases": [
"CVE-2026-46384"
],
"database_specific": {
"cwe_ids": [
"CWE-1284",
"CWE-190",
"CWE-191",
"CWE-681"
],
"github_reviewed": true,
"github_reviewed_at": "2026-05-18T16:22:27Z",
"nvd_published_at": "2026-05-29T20:16:27Z",
"severity": "HIGH"
},
"details": "# 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 \u2014 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 `\u2265 2\u00b3\u00b9` 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 \u2014 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 \u2212 2` for the second block\u0027s 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 \u2014 there is no implicit 2\u00b3\u00b9 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` \u2014 narrowing | Narrowing | 32-bit |\n| `reader.go` | `ReadBlockHeader` \u2014 `-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` \u2014 narrowing | Narrowing | 32-bit |\n| `ocf/ocf.go` | `readBlock` \u2014 negative `make([]byte, \u2026)` | 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` \u2192 `Reader.ReadInt`) is **not** affected by the union-index narrowing \u2014 `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 \u2212 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 \u2014 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` \u2192 `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` \u2014 all versions up to and including `v2.31.0` (repository is read-only upstream).\n- `github.com/iskorotkov/avro/v2` \u2014 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` \u2014 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 \u2014 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 \u2014 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 \u2014 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 \u2212 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 \u2014 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` \u2014 `ReadBlockHeader`, cumulative array/map checks, skip helpers): Daniel B\u0142a\u017cewicz ([@klajok](https://github.com/klajok))\n- **Completeness fixes** (commit `e1a570f` \u2014 union index, `readBytes`, OCF `readBlock`, 32-bit CI coverage): Ivan Korotkov ([@iskorotkov](https://github.com/iskorotkov))\n\n## Timeline\n\n- **2026-05-04** \u2014 Initial integer-overflow hardening (PR #9, `bed99b3`) merged.\n- **2026-05-04** \u2014 Completeness pass (`e1a570f`) merged; 32-bit CI job added.\n- **2026-05-06** \u2014 `v2.33.0` tagged and released.\n- **2026-05-11** \u2014 Advisory published.\n- **2026-05-15** \u2014 Advisory revised.",
"id": "GHSA-mc57-h6j3-3hmv",
"modified": "2026-06-09T10:32:44Z",
"published": "2026-05-18T16:22:27Z",
"references": [
{
"type": "WEB",
"url": "https://github.com/iskorotkov/avro/security/advisories/GHSA-mc57-h6j3-3hmv"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-46384"
},
{
"type": "PACKAGE",
"url": "https://github.com/iskorotkov/avro"
}
],
"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"
},
{
"score": "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",
"type": "CVSS_V4"
}
],
"summary": "iskorotkov/avro: Integer Overflow in Decoder"
}
GHSA-MC92-59CV-MJWH
Vulnerability from github – Published: 2024-11-14 18:30 – Updated: 2024-11-14 18:30A memory corruption vulnerability exists in the affected products when parsing DFT files. Local threat actors can exploit this issue to disclose information and to execute arbitrary code. To exploit this vulnerability a legitimate user must open a malicious DFT file.
{
"affected": [],
"aliases": [
"CVE-2024-6068"
],
"database_specific": {
"cwe_ids": [
"CWE-1284"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2024-11-14T17:15:07Z",
"severity": "HIGH"
},
"details": "A memory corruption vulnerability exists in the affected products when parsing DFT files. Local threat actors can exploit this issue to disclose information and to execute arbitrary code. To exploit this vulnerability a legitimate user must open a malicious DFT file.",
"id": "GHSA-mc92-59cv-mjwh",
"modified": "2024-11-14T18:30:37Z",
"published": "2024-11-14T18:30:37Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-6068"
},
{
"type": "WEB",
"url": "https://www.rockwellautomation.com/en-us/trust-center/security-advisories/advisory.SD17011.html"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:L/AC:L/PR:L/UI:R/S:U/C:H/I:H/A:H",
"type": "CVSS_V3"
},
{
"score": "CVSS:4.0/AV:L/AC:L/AT:N/PR:L/UI:P/VC:H/VI:H/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",
"type": "CVSS_V4"
}
]
}
GHSA-MCWG-GHGC-H3XJ
Vulnerability from github – Published: 2026-05-01 00:31 – Updated: 2026-05-10 15:31IBM Db2 11.5.0 through 11.5.9, and 12.1.0 through 12.1.4 for Linux, UNIX and Windows (includes Db2 Connect Server) could allow an authenticated user to cause a denial of service due to improper neutralization of special elements in data query logic.
{
"affected": [],
"aliases": [
"CVE-2026-1577"
],
"database_specific": {
"cwe_ids": [
"CWE-1284",
"CWE-20"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2026-04-30T22:16:25Z",
"severity": "MODERATE"
},
"details": "IBM Db2 11.5.0 through 11.5.9, and 12.1.0 through 12.1.4 for Linux, UNIX and Windows (includes Db2 Connect Server) could allow an\u00a0authenticated user to cause a denial of service due to improper neutralization of special\u00a0elements in data query logic.",
"id": "GHSA-mcwg-ghgc-h3xj",
"modified": "2026-05-10T15:31:18Z",
"published": "2026-05-01T00:31:26Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-1577"
},
{
"type": "WEB",
"url": "https://www.ibm.com/support/pages/node/7269434"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H",
"type": "CVSS_V3"
}
]
}
Mitigation MIT-5
Strategy: Input Validation
- Assume all input is malicious. Use an "accept known good" input validation strategy, i.e., use a list of acceptable inputs that strictly conform to specifications. Reject any input that does not strictly conform to specifications, or transform it into something that does.
- When performing input validation, consider all potentially relevant properties, including length, type of input, the full range of acceptable values, missing or extra inputs, syntax, consistency across related fields, and conformance to business rules. As an example of business rule logic, "boat" may be syntactically valid because it only contains alphanumeric characters, but it is not valid if the input is only expected to contain colors such as "red" or "blue."
- Do not rely exclusively on looking for malicious or malformed inputs. This is likely to miss at least one undesirable input, especially if the code's environment changes. This can give attackers enough room to bypass the intended validation. However, denylists can be useful for detecting potential attacks or determining which inputs are so malformed that they should be rejected outright.
No CAPEC attack patterns related to this CWE.