Common Weakness Enumeration

CWE-190

Allowed

Integer Overflow or Wraparound

Abstraction: Base · Status: Stable

API response cwe.mitre.org

The product performs a calculation that can produce an integer overflow or wraparound when the logic assumes that the resulting value will always be larger than the original value. This occurs when an integer value is incremented to a value that is too large to store in the associated representation. When this occurs, the value may become a very small or negative number.

3868 vulnerabilities reference this CWE, most recent first.

GHSA-M8QW-26FR-V67C

Vulnerability from github – Published: 2025-02-07 12:31 – Updated: 2025-02-07 12:31
VLAI
Details

in OpenHarmony v4.1.2 and prior versions allow a local attacker cause DOS through integer overflow.

Severity
5.5 (Medium)
CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H
Show details on source website
To clipboard 

{
  "affected": [],
  "aliases": [
    "CVE-2025-0302"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-190"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2025-02-07T10:15:11Z",
    "severity": "MODERATE"
  },
  "details": "in OpenHarmony v4.1.2 and prior versions allow a local attacker cause DOS through integer overflow.",
  "id": "GHSA-m8qw-26fr-v67c",
  "modified": "2025-02-07T12:31:14Z",
  "published": "2025-02-07T12:31:14Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2025-0302"
    },
    {
      "type": "WEB",
      "url": "https://gitee.com/openharmony/security/blob/master/zh/security-disclosure/2025/2025-02.md"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H",
      "type": "CVSS_V3"
    }
  ]
}

GHSA-M8VF-X457-28CV

Vulnerability from github – Published: 2026-03-17 21:31 – Updated: 2026-03-17 21:31
VLAI
Details

Netskope was notified about a potential gap in its Endpoint DLP Module for Netskope Client on Windows systems. The successful exploitation of the gap can potentially allow a privileged user to trigger an integer overflow within the DLL Injector, leading to a Blue-Screen-of-Death (BSOD). Successful exploitation would require the Endpoint DLP module to be enabled in the client configuration. A successful exploit can potentially result in a denial-of-service for the local machine.

Severity
6.7 (Medium)
CVSS:4.0/AV:L/AC:L/AT:N/PR:H/UI:N/VC:N/VI:N/VA:H/SC:N/SI:N/SA:N
Show details on source website
To clipboard 

{
  "affected": [],
  "aliases": [
    "CVE-2026-2809"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-190"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2026-03-17T21:16:19Z",
    "severity": "MODERATE"
  },
  "details": "Netskope was notified about a potential gap in its Endpoint DLP Module for Netskope Client on Windows systems. The successful exploitation of the gap can potentially allow a privileged user to trigger an integer overflow within the DLL Injector, leading to a Blue-Screen-of-Death (BSOD). Successful exploitation would require the Endpoint DLP module to be enabled in the client configuration. A successful exploit can potentially result in a denial-of-service for the local machine.",
  "id": "GHSA-m8vf-x457-28cv",
  "modified": "2026-03-17T21:31:46Z",
  "published": "2026-03-17T21:31:45Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-2809"
    },
    {
      "type": "WEB",
      "url": "https://support.netskope.com/s/article/NSKPSA-2026-001-Endpoint-DLP-Driver-DLL-Injector-Integer-Overflow"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:4.0/AV:L/AC:L/AT:N/PR:H/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",
      "type": "CVSS_V4"
    }
  ]
}

GHSA-M93G-V4MV-3GGR

Vulnerability from github – Published: 2024-01-08 15:30 – Updated: 2025-11-04 21:30
VLAI
Details

Multiple integer overflow vulnerabilities exist in the VZT facgeometry parsing functionality of GTKWave 3.3.115. A specially crafted .vzt file can lead to arbitrary code execution. A victim would need to open a malicious file to trigger these vulnerabilities.This vulnerability concerns the integer overflow when allocating the msb array.

Severity
7.8 (High)
CVSS:3.1/AV:L/AC:L/PR:N/UI:R/S:U/C:H/I:H/A:H
Show details on source website
To clipboard 

{
  "affected": [],
  "aliases": [
    "CVE-2023-38619"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-190"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2024-01-08T15:15:19Z",
    "severity": "HIGH"
  },
  "details": "Multiple integer overflow vulnerabilities exist in the VZT facgeometry parsing functionality of GTKWave 3.3.115. A specially crafted .vzt file can lead to arbitrary code execution. A victim would need to open a malicious file to trigger these vulnerabilities.This vulnerability concerns the integer overflow when allocating the `msb` array.",
  "id": "GHSA-m93g-v4mv-3ggr",
  "modified": "2025-11-04T21:30:58Z",
  "published": "2024-01-08T15:30:29Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2023-38619"
    },
    {
      "type": "WEB",
      "url": "https://lists.debian.org/debian-lts-announce/2024/04/msg00007.html"
    },
    {
      "type": "WEB",
      "url": "https://talosintelligence.com/vulnerability_reports/TALOS-2023-1812"
    },
    {
      "type": "WEB",
      "url": "https://www.talosintelligence.com/vulnerability_reports/TALOS-2023-1812"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:L/AC:L/PR:N/UI:R/S:U/C:H/I:H/A:H",
      "type": "CVSS_V3"
    }
  ]
}

GHSA-M9F3-5W45-2J8H

Vulnerability from github – Published: 2022-05-01 18:28 – Updated: 2022-05-01 18:28
VLAI
Details

Multiple integer overflows in the imageop module in Python 2.5.1 and earlier allow context-dependent attackers to cause a denial of service (application crash) and possibly obtain sensitive information (memory contents) via crafted arguments to (1) the tovideo method, and unspecified other vectors related to (2) imageop.c, (3) rbgimgmodule.c, and other files, which trigger heap-based buffer overflows.

Show details on source website
To clipboard 

{
  "affected": [],
  "aliases": [
    "CVE-2007-4965"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-190"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2007-09-18T22:17:00Z",
    "severity": "MODERATE"
  },
  "details": "Multiple integer overflows in the imageop module in Python 2.5.1 and earlier allow context-dependent attackers to cause a denial of service (application crash) and possibly obtain sensitive information (memory contents) via crafted arguments to (1) the tovideo method, and unspecified other vectors related to (2) imageop.c, (3) rbgimgmodule.c, and other files, which trigger heap-based buffer overflows.",
  "id": "GHSA-m9f3-5w45-2j8h",
  "modified": "2022-05-01T18:28:39Z",
  "published": "2022-05-01T18:28:39Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2007-4965"
    },
    {
      "type": "WEB",
      "url": "https://exchange.xforce.ibmcloud.com/vulnerabilities/36653"
    },
    {
      "type": "WEB",
      "url": "https://issues.rpath.com/browse/RPL-1885"
    },
    {
      "type": "WEB",
      "url": "https://oval.cisecurity.org/repository/search/definition/oval%3Aorg.mitre.oval%3Adef%3A10804"
    },
    {
      "type": "WEB",
      "url": "https://oval.cisecurity.org/repository/search/definition/oval%3Aorg.mitre.oval%3Adef%3A8486"
    },
    {
      "type": "WEB",
      "url": "https://oval.cisecurity.org/repository/search/definition/oval%3Aorg.mitre.oval%3Adef%3A8496"
    },
    {
      "type": "WEB",
      "url": "https://www.redhat.com/archives/fedora-package-announce/2007-October/msg00378.html"
    },
    {
      "type": "WEB",
      "url": "http://bugs.gentoo.org/show_bug.cgi?id=192876"
    },
    {
      "type": "WEB",
      "url": "http://docs.info.apple.com/article.html?artnum=307179"
    },
    {
      "type": "WEB",
      "url": "http://lists.apple.com/archives/security-announce/2007/Dec/msg00002.html"
    },
    {
      "type": "WEB",
      "url": "http://lists.apple.com/archives/security-announce/2009/Feb/msg00000.html"
    },
    {
      "type": "WEB",
      "url": "http://lists.grok.org.uk/pipermail/full-disclosure/2007-September/065826.html"
    },
    {
      "type": "WEB",
      "url": "http://lists.opensuse.org/opensuse-security-announce/2008-02/msg00003.html"
    },
    {
      "type": "WEB",
      "url": "http://lists.vmware.com/pipermail/security-announce/2008/000005.html"
    },
    {
      "type": "WEB",
      "url": "http://secunia.com/advisories/26837"
    },
    {
      "type": "WEB",
      "url": "http://secunia.com/advisories/27460"
    },
    {
      "type": "WEB",
      "url": "http://secunia.com/advisories/27562"
    },
    {
      "type": "WEB",
      "url": "http://secunia.com/advisories/27872"
    },
    {
      "type": "WEB",
      "url": "http://secunia.com/advisories/28136"
    },
    {
      "type": "WEB",
      "url": "http://secunia.com/advisories/28480"
    },
    {
      "type": "WEB",
      "url": "http://secunia.com/advisories/28838"
    },
    {
      "type": "WEB",
      "url": "http://secunia.com/advisories/29032"
    },
    {
      "type": "WEB",
      "url": "http://secunia.com/advisories/29303"
    },
    {
      "type": "WEB",
      "url": "http://secunia.com/advisories/29889"
    },
    {
      "type": "WEB",
      "url": "http://secunia.com/advisories/31255"
    },
    {
      "type": "WEB",
      "url": "http://secunia.com/advisories/31492"
    },
    {
      "type": "WEB",
      "url": "http://secunia.com/advisories/33937"
    },
    {
      "type": "WEB",
      "url": "http://secunia.com/advisories/37471"
    },
    {
      "type": "WEB",
      "url": "http://secunia.com/advisories/38675"
    },
    {
      "type": "WEB",
      "url": "http://support.apple.com/kb/HT3438"
    },
    {
      "type": "WEB",
      "url": "http://support.avaya.com/css/P8/documents/100074697"
    },
    {
      "type": "WEB",
      "url": "http://wiki.rpath.com/wiki/Advisories:rPSA-2007-0254"
    },
    {
      "type": "WEB",
      "url": "http://www.debian.org/security/2008/dsa-1551"
    },
    {
      "type": "WEB",
      "url": "http://www.debian.org/security/2008/dsa-1620"
    },
    {
      "type": "WEB",
      "url": "http://www.gentoo.org/security/en/glsa/glsa-200711-07.xml"
    },
    {
      "type": "WEB",
      "url": "http://www.mandriva.com/security/advisories?name=MDVSA-2008:012"
    },
    {
      "type": "WEB",
      "url": "http://www.mandriva.com/security/advisories?name=MDVSA-2008:013"
    },
    {
      "type": "WEB",
      "url": "http://www.redhat.com/support/errata/RHSA-2007-1076.html"
    },
    {
      "type": "WEB",
      "url": "http://www.redhat.com/support/errata/RHSA-2008-0629.html"
    },
    {
      "type": "WEB",
      "url": "http://www.securityfocus.com/archive/1/487990/100/0/threaded"
    },
    {
      "type": "WEB",
      "url": "http://www.securityfocus.com/archive/1/488457/100/0/threaded"
    },
    {
      "type": "WEB",
      "url": "http://www.securityfocus.com/archive/1/507985/100/0/threaded"
    },
    {
      "type": "WEB",
      "url": "http://www.securityfocus.com/bid/25696"
    },
    {
      "type": "WEB",
      "url": "http://www.ubuntu.com/usn/usn-585-1"
    },
    {
      "type": "WEB",
      "url": "http://www.us-cert.gov/cas/techalerts/TA07-352A.html"
    },
    {
      "type": "WEB",
      "url": "http://www.vmware.com/security/advisories/VMSA-2009-0016.html"
    },
    {
      "type": "WEB",
      "url": "http://www.vupen.com/english/advisories/2007/3201"
    },
    {
      "type": "WEB",
      "url": "http://www.vupen.com/english/advisories/2007/4238"
    },
    {
      "type": "WEB",
      "url": "http://www.vupen.com/english/advisories/2008/0637"
    },
    {
      "type": "WEB",
      "url": "http://www.vupen.com/english/advisories/2009/3316"
    }
  ],
  "schema_version": "1.4.0",
  "severity": []
}

GHSA-M9GF-VF48-RG58

Vulnerability from github – Published: 2025-02-21 15:32 – Updated: 2025-07-30 18:31
VLAI
Details

There exists a heap buffer overflow vulnerable in Abseil-cpp. The sized constructors, reserve(), and rehash() methods of absl::{flat,node}hash{set,map} did not impose an upper bound on their size argument. As a result, it was possible for a caller to pass a very large size that would cause an integer overflow when computing the size of the container's backing store, and a subsequent out-of-bounds memory write. Subsequent accesses to the container might also access out-of-bounds memory. We recommend upgrading past commit 5a0e2cb5e3958dd90bb8569a2766622cb74d90c1

Severity
9.8 (Critical)
CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H
5.9 (Medium)
CVSS:4.0/AV:A/AC:H/AT:P/PR:L/UI:A/VC:L/VI:H/VA:L/SC:L/SI:H/SA:L
Show details on source website
To clipboard 

{
  "affected": [],
  "aliases": [
    "CVE-2025-0838"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-190"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2025-02-21T15:15:11Z",
    "severity": "MODERATE"
  },
  "details": "There exists a heap buffer overflow vulnerable in Abseil-cpp. The sized constructors, reserve(), and rehash() methods of absl::{flat,node}hash{set,map} did not impose an upper bound on their size argument. As a result, it was possible for a caller to pass a very large size that would cause an integer overflow when computing the size of the container\u0027s backing store, and a subsequent out-of-bounds memory write. Subsequent accesses to the container might also access out-of-bounds memory. We recommend upgrading past commit 5a0e2cb5e3958dd90bb8569a2766622cb74d90c1",
  "id": "GHSA-m9gf-vf48-rg58",
  "modified": "2025-07-30T18:31:29Z",
  "published": "2025-02-21T15:32:03Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2025-0838"
    },
    {
      "type": "WEB",
      "url": "https://github.com/abseil/abseil-cpp/commit/5a0e2cb5e3958dd90bb8569a2766622cb74d90c1"
    },
    {
      "type": "WEB",
      "url": "https://lists.debian.org/debian-lts-announce/2025/04/msg00012.html"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H",
      "type": "CVSS_V3"
    },
    {
      "score": "CVSS:4.0/AV:A/AC:H/AT:P/PR:L/UI:A/VC:L/VI:H/VA:L/SC:L/SI:H/SA:L/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-MC36-3FHX-66VV

Vulnerability from github – Published: 2022-10-11 12:00 – Updated: 2022-10-12 12:00
VLAI
Details

A write-what-where condition in hermes caused by an integer overflow, prior to commit 5b6255ae049fa4641791e47fad994e8e8c4da374 allows attackers to potentially execute arbitrary code via crafted JavaScript. Note that this is only exploitable if the application using Hermes permits evaluation of untrusted JavaScript. Hence, most React Native applications are not affected.

Severity
9.8 (Critical)
CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H
Show details on source website
To clipboard 

{
  "affected": [],
  "aliases": [
    "CVE-2022-35289"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-190"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2022-10-11T02:15:00Z",
    "severity": "CRITICAL"
  },
  "details": "A write-what-where condition in hermes caused by an integer overflow, prior to commit 5b6255ae049fa4641791e47fad994e8e8c4da374 allows attackers to potentially execute arbitrary code via crafted JavaScript. Note that this is only exploitable if the application using Hermes permits evaluation of untrusted JavaScript. Hence, most React Native applications are not affected.",
  "id": "GHSA-mc36-3fhx-66vv",
  "modified": "2022-10-12T12:00:30Z",
  "published": "2022-10-11T12:00:47Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2022-35289"
    },
    {
      "type": "WEB",
      "url": "https://github.com/facebook/hermes/commit/5b6255ae049fa4641791e47fad994e8e8c4da374"
    },
    {
      "type": "WEB",
      "url": "https://www.facebook.com/security/advisories/CVE-2022-35289"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H",
      "type": "CVSS_V3"
    }
  ]
}

GHSA-MC39-H54G-PVW6

Vulnerability from github – Published: 2024-04-05 15:42 – Updated: 2024-04-05 15:42
VLAI
Summary
libdav1d-sys affected by dav1d AV1 decoder integer overflow
Details

An integer overflow in dav1d AV1 decoder that can occur when decoding videos with large frame size. This can lead to memory corruption within the AV1 decoder. We recommend upgrading to version 0.7.0 of libdav1d-sys, which includes dav1d 1.4.0.

Severity
5.9 (Medium)
CVSS:3.1/AV:A/AC:H/PR:L/UI:N/S:U/C:L/I:H/A:L
Show details on source website
To clipboard 

{
  "affected": [
    {
      "package": {
        "ecosystem": "crates.io",
        "name": "libdav1d-sys"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            },
            {
              "fixed": "0.7.0"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [],
  "database_specific": {
    "cwe_ids": [
      "CWE-190"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2024-04-05T15:42:39Z",
    "nvd_published_at": null,
    "severity": "MODERATE"
  },
  "details": "An integer overflow in dav1d AV1 decoder that can occur when decoding videos with large frame size. This can lead to memory corruption within the AV1 decoder. We recommend upgrading to version 0.7.0 of libdav1d-sys, which includes dav1d 1.4.0.\n",
  "id": "GHSA-mc39-h54g-pvw6",
  "modified": "2024-04-05T15:42:39Z",
  "published": "2024-04-05T15:42:39Z",
  "references": [
    {
      "type": "PACKAGE",
      "url": "https://github.com/njaard/libavif-rs"
    },
    {
      "type": "WEB",
      "url": "https://rustsec.org/advisories/RUSTSEC-2024-0016.html"
    },
    {
      "type": "WEB",
      "url": "https://www.cvedetails.com/cve/CVE-2024-1580"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:A/AC:H/PR:L/UI:N/S:U/C:L/I:H/A:L",
      "type": "CVSS_V3"
    }
  ],
  "summary": "libdav1d-sys affected by dav1d AV1 decoder integer overflow"
}

GHSA-MC57-H6J3-3HMV

Vulnerability from github – Published: 2026-05-18 16:22 – Updated: 2026-06-09 10:32
VLAI
Summary
iskorotkov/avro: Integer Overflow in Decoder
Details

Integer 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, and mapDecoderUnmarshaler.Decode summed attacker-controlled block lengths via size += int(l) and then checked size > limit. On amd64 / arm64 the running total wraps at math.MaxInt64; the post-wrap negative value passes the > 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.
  • ReadBlockHeader() returns the absolute value of negative block lengths; the negation is unsafe for math.MinInt, which on every platform panics on overflow.
  • 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 > MaxInt32 additionally 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

  1. 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.

  2. 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 > 13 is false, so the check passes and the decoder proceeds. The fix uses subtraction-safe comparisons (l > limit - size rather than size + l > limit), which is overflow-immune.

  3. 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.

  4. Byte-slice length truncation. A wire-format length such as (1<<32) + 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.

  5. Union index narrowing (generic decode path only). Reader.ReadNext decoded the union index as int64 and immediately cast to int. On 32-bit, 1<<32 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.

  6. 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 > MaxInt32 additionally 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:

  1. Read the wire value into an int64-typed local.
  2. Range-check upper and lower bounds before narrowing.
  3. Compare cumulative limits using subtraction-safe arithmetic.
  4. Route skip operations through SkipNBytesInt64().
  5. Return descriptive errors using the consistent "value is too big" / "value is too small" wording.
  6. Cast to int only 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 including v2.31.0 (repository is read-only upstream).
  • github.com/iskorotkov/avro/v2 — all versions prior to v2.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 setting Config.MaxByteSliceSize lower, because the truncated post-narrowing value is what the limit sees, not the original wire value.
  • 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.
  • Isolate decoding workers so a crash is bounded.

Proof-of-concept inputs

  • A bytes or string length of (1<<32) + N for small N, which narrows to N on 32-bit and bypasses Config.MaxByteSliceSize.
  • A union index of 1<<32, which narrows to 0 on 32-bit and selects types[0] despite the upper-bound check.
  • 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.
  • 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 > MaxInt32 on 32-bit, same outcome via narrowing.

References

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, OCF readBlock, 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.0 tagged and released.
  • 2026-05-11 — Advisory published.
  • 2026-05-15 — Advisory revised.
Severity
7.5 (High)
CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H
8.2 (High)
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
Show details on source website
To clipboard 

{
  "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-MC5F-XRMC-QMXR

Vulnerability from github – Published: 2022-05-14 03:02 – Updated: 2022-05-14 03:02
VLAI
Details

The mintToken function of a smart contract implementation for BGC, an Ethereum token, has an integer overflow that allows the owner of the contract to set the balance of an arbitrary user to any value.

Severity
7.5 (High)
CVSS:3.0/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:H/A:N
Show details on source website
To clipboard 

{
  "affected": [],
  "aliases": [
    "CVE-2018-13648"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-190"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2018-07-09T06:29:00Z",
    "severity": "HIGH"
  },
  "details": "The mintToken function of a smart contract implementation for BGC, an Ethereum token, has an integer overflow that allows the owner of the contract to set the balance of an arbitrary user to any value.",
  "id": "GHSA-mc5f-xrmc-qmxr",
  "modified": "2022-05-14T03:02:42Z",
  "published": "2022-05-14T03:02:42Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2018-13648"
    },
    {
      "type": "WEB",
      "url": "https://github.com/BlockChainsSecurity/EtherTokens/blob/master/GEMCHAIN/mint%20integer%20overflow.md"
    },
    {
      "type": "WEB",
      "url": "https://github.com/BlockChainsSecurity/EtherTokens/tree/master/BGC"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.0/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:H/A:N",
      "type": "CVSS_V3"
    }
  ]
}

GHSA-MC63-87JP-8648

Vulnerability from github – Published: 2026-06-15 18:31 – Updated: 2026-06-15 18:31
VLAI
Details

LibreOffice can import EMF+ graphics, which may be embedded in documents. A heap buffer overflow existed when importing an EMF+ gradient brush. The number of gradient blend points was read from the file and used to compute an allocation size, but that multiplication could overflow, so a small buffer was allocated and then filled as if it were large, writing past its end. In fixed versions the blend-point count is checked against the data actually available before allocating.

Severity
5.4 (Medium)
CVSS:4.0/AV:L/AC:L/AT:N/PR:N/UI:P/VC:L/VI:L/VA:H/SC:N/SI:N/SA:N/E:P
Show details on source website
To clipboard 

{
  "affected": [],
  "aliases": [
    "CVE-2026-6045"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-190"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2026-06-15T18:16:37Z",
    "severity": "MODERATE"
  },
  "details": "LibreOffice can import EMF+ graphics, which may be embedded in documents. A heap buffer overflow existed when importing an EMF+ gradient brush. The number of gradient blend points was read from the file and used to compute an allocation size, but that multiplication could overflow, so a small buffer was allocated and then filled as if it were large, writing past its end. In fixed versions the blend-point count is checked against the data actually available before allocating.",
  "id": "GHSA-mc63-87jp-8648",
  "modified": "2026-06-15T18:31:19Z",
  "published": "2026-06-15T18:31:19Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-6045"
    },
    {
      "type": "WEB",
      "url": "https://www.libreoffice.org/about-us/security/advisories/cve-2026-6045"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:4.0/AV:L/AC:L/AT:N/PR:N/UI:P/VC:L/VI:L/VA:H/SC:N/SI:N/SA:N/E:P/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"
    }
  ]
}
Mitigation
Requirements

Ensure that all protocols are strictly defined, such that all out-of-bounds behavior can be identified simply, and require strict conformance to the protocol.

Mitigation MIT-3
Requirements

Strategy: Language Selection

  • Use a language that does not allow this weakness to occur or provides constructs that make this weakness easier to avoid.
  • If possible, choose a language or compiler that performs automatic bounds checking.
Mitigation MIT-4
Architecture and Design

Strategy: Libraries or Frameworks

  • Use a vetted library or framework that does not allow this weakness to occur or provides constructs that make this weakness easier to avoid [REF-1482].
  • Use libraries or frameworks that make it easier to handle numbers without unexpected consequences.
  • Examples include safe integer handling packages such as SafeInt (C++) or IntegerLib (C or C++). [REF-106]
Mitigation MIT-8
Implementation

Strategy: Input Validation

  • Perform input validation on any numeric input by ensuring that it is within the expected range. Enforce that the input meets both the minimum and maximum requirements for the expected range.
  • Use unsigned integers where possible. This makes it easier to perform validation for integer overflows. When signed integers are required, ensure that the range check includes minimum values as well as maximum values.
Mitigation MIT-36
Implementation
  • Understand the programming language's underlying representation and how it interacts with numeric calculation (CWE-681). Pay close attention to byte size discrepancies, precision, signed/unsigned distinctions, truncation, conversion and casting between types, "not-a-number" calculations, and how the language handles numbers that are too large or too small for its underlying representation. [REF-7]
  • Also be careful to account for 32-bit, 64-bit, and other potential differences that may affect the numeric representation.
Mitigation MIT-15
Architecture and Design

For any security checks that are performed on the client side, ensure that these checks are duplicated on the server side, in order to avoid CWE-602. Attackers can bypass the client-side checks by modifying values after the checks have been performed, or by changing the client to remove the client-side checks entirely. Then, these modified values would be submitted to the server.

Mitigation MIT-26
Implementation

Strategy: Compilation or Build Hardening

Examine compiler warnings closely and eliminate problems with potential security implications, such as signed / unsigned mismatch in memory operations, or use of uninitialized variables. Even if the weakness is rarely exploitable, a single failure may lead to the compromise of the entire system.

CAPEC-92: Forced Integer Overflow

This attack forces an integer variable to go out of range. The integer variable is often used as an offset such as size of memory allocation or similarly. The attacker would typically control the value of such variable and try to get it out of range. For instance the integer in question is incremented past the maximum possible value, it may wrap to become a very small, or negative number, therefore providing a very incorrect value which can lead to unexpected behavior. At worst the attacker can execute arbitrary code.

← Back to the CWE list