CWE-125
AllowedOut-of-bounds Read
Abstraction: Base · Status: Draft
The product reads data past the end, or before the beginning, of the intended buffer.
11812 vulnerabilities reference this CWE, most recent first.
GHSA-XX22-P4CH-683R
Vulnerability from github – Published: 2026-07-24 16:13 – Updated: 2026-07-24 16:13Summary
Insufficient validation of byte array arguments in JNI-based XXHash implementations in lz4-java 1.11.0 and earlier allows callers to crash the JVM by passing an invalid array reference or invalid range to native XXHash methods.
This affects applications where an attacker can influence the byte array object or the off / len arguments passed to affected XXHash APIs. It does not affect the common case where only the contents of a valid byte array are attacker-controlled.
Java-based XXHash implementations are not affected.
Details
The JNI-backed XXHash implementations pass caller-provided byte array arguments to native code. The affected APIs are:
XXHashFactory.nativeInstance().hash32().hash(byte[] buf, int off, int len, int seed)XXHashFactory.nativeInstance().hash64().hash(byte[] buf, int off, int len, long seed)XXHashFactory.nativeInstance().newStreamingHash32(seed).update(byte[] bytes, int off, int len)XXHashFactory.nativeInstance().newStreamingHash64(seed).update(byte[] bytes, int off, int len)
Before the fix, the streaming JNI implementations did not validate bytes, off, or len before calling XXHashJNI.XXH32_update / XXHashJNI.XXH64_update. The non-streaming JNI implementations called SafeUtils.checkRange, but SafeUtils.checkRange(byte[], int, int) skipped all array access when len == 0, so a null byte array with a zero length could still reach JNI.
As a result:
hash(null, 0, 0, seed)andupdate(null, 0, 0)could pass a null array reference to JNI, causing a fatal JVM crash inGetPrimitiveArrayCritical.update(new byte[16], 0, Integer.MAX_VALUE)could cause native XXHash code to read far beyond the end of the Java array, causing a fatal JVM crash and potentially exposing in-process memory to the native routine before the crash.
The oversized-length non-streaming hash(new byte[16], 0, Integer.MAX_VALUE, seed) case was already rejected in Java before this fix. The missing validation affected the streaming oversized-length case and the zero-length null-array case for both streaming and non-streaming JNI XXHash APIs.
The impact of this vulnerability depends on how user code uses the XXHash API. Code that hashes attacker-controlled byte contents in a valid, correctly bounded array is not affected. Code may be affected if an attacker can cause the application to pass a null array, an attacker-controlled offset, or an attacker-controlled length to the native XXHash API. The primary impact is denial of service due to JVM termination. For oversized lengths, native code may also read outside the Java array before the process crashes.
Mitigation
lz4-java 1.11.1 fixes this issue without requiring changes in user code.
If you cannot upgrade, avoid passing attacker-controlled array references, offsets, or lengths to JNI-backed XXHash APIs. In particular, validate that arrays are non-null and that off and len describe a range fully contained in the array before calling native XXHash methods.
Using XXHashFactory.safeInstance() avoids the JNI boundary and is not affected by this native crash behavior.
{
"affected": [
{
"database_specific": {
"last_known_affected_version_range": "\u003c= 1.11.0"
},
"package": {
"ecosystem": "Maven",
"name": "at.yawk.lz4:lz4-java"
},
"ranges": [
{
"events": [
{
"introduced": "0"
},
{
"fixed": "1.11.1"
}
],
"type": "ECOSYSTEM"
}
]
},
{
"package": {
"ecosystem": "Maven",
"name": "org.lz4:lz4-java"
},
"ranges": [
{
"events": [
{
"introduced": "0"
},
{
"last_affected": "1.8.1"
}
],
"type": "ECOSYSTEM"
}
]
}
],
"aliases": [
"CVE-2026-59949"
],
"database_specific": {
"cwe_ids": [
"CWE-125",
"CWE-476"
],
"github_reviewed": true,
"github_reviewed_at": "2026-07-24T16:13:41Z",
"nvd_published_at": null,
"severity": "MODERATE"
},
"details": "### Summary\n\nInsufficient validation of byte array arguments in JNI-based XXHash implementations in lz4-java 1.11.0 and earlier allows callers to crash the JVM by passing an invalid array reference or invalid range to native XXHash methods.\n\nThis affects applications where an attacker can influence the byte array object or the `off` / `len` arguments passed to affected XXHash APIs. It does **not** affect the common case where only the contents of a valid byte array are attacker-controlled.\n\nJava-based XXHash implementations are *not* affected.\n\n### Details\n\nThe JNI-backed XXHash implementations pass caller-provided byte array arguments to native code. The affected APIs are:\n\n- `XXHashFactory.nativeInstance().hash32().hash(byte[] buf, int off, int len, int seed)`\n- `XXHashFactory.nativeInstance().hash64().hash(byte[] buf, int off, int len, long seed)`\n- `XXHashFactory.nativeInstance().newStreamingHash32(seed).update(byte[] bytes, int off, int len)`\n- `XXHashFactory.nativeInstance().newStreamingHash64(seed).update(byte[] bytes, int off, int len)`\n\nBefore the fix, the streaming JNI implementations did not validate `bytes`, `off`, or `len` before calling `XXHashJNI.XXH32_update` / `XXHashJNI.XXH64_update`. The non-streaming JNI implementations called `SafeUtils.checkRange`, but `SafeUtils.checkRange(byte[], int, int)` skipped all array access when `len == 0`, so a null byte array with a zero length could still reach JNI.\n\nAs a result:\n\n- `hash(null, 0, 0, seed)` and `update(null, 0, 0)` could pass a null array reference to JNI, causing a fatal JVM crash in `GetPrimitiveArrayCritical`.\n- `update(new byte[16], 0, Integer.MAX_VALUE)` could cause native XXHash code to read far beyond the end of the Java array, causing a fatal JVM crash and potentially exposing in-process memory to the native routine before the crash.\n\nThe oversized-length non-streaming `hash(new byte[16], 0, Integer.MAX_VALUE, seed)` case was already rejected in Java before this fix. The missing validation affected the streaming oversized-length case and the zero-length null-array case for both streaming and non-streaming JNI XXHash APIs.\n\nThe impact of this vulnerability depends on how user code uses the XXHash API. Code that hashes attacker-controlled byte contents in a valid, correctly bounded array is not affected. Code may be affected if an attacker can cause the application to pass a null array, an attacker-controlled offset, or an attacker-controlled length to the native XXHash API. The primary impact is denial of service due to JVM termination. For oversized lengths, native code may also read outside the Java array before the process crashes.\n\n### Mitigation\n\nlz4-java 1.11.1 fixes this issue without requiring changes in user code.\n\nIf you cannot upgrade, avoid passing attacker-controlled array references, offsets, or lengths to JNI-backed XXHash APIs. In particular, validate that arrays are non-null and that `off` and `len` describe a range fully contained in the array before calling native XXHash methods.\n\nUsing `XXHashFactory.safeInstance()` avoids the JNI boundary and is not affected by this native crash behavior.",
"id": "GHSA-xx22-p4ch-683r",
"modified": "2026-07-24T16:13:41Z",
"published": "2026-07-24T16:13:41Z",
"references": [
{
"type": "WEB",
"url": "https://github.com/yawkat/lz4-java/security/advisories/GHSA-xx22-p4ch-683r"
},
{
"type": "WEB",
"url": "https://github.com/yawkat/lz4-java/commit/dbd86d04b8dd716e1c2bc626be54189997d910da"
},
{
"type": "PACKAGE",
"url": "https://github.com/yawkat/lz4-java"
},
{
"type": "WEB",
"url": "https://github.com/yawkat/lz4-java/releases/tag/v1.11.1"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:U/C:L/I:N/A:H",
"type": "CVSS_V3"
}
],
"summary": "LZ4 Java: Native XXHash implementations can crash the JVM when passed invalid byte array ranges"
}
GHSA-XX24-R484-7P82
Vulnerability from github – Published: 2024-12-27 12:30 – Updated: 2024-12-27 12:30There is an out-of-bound read and write vulnerability in Huawei smartphone. A module dose not verify the input sufficiently. Attackers can exploit this vulnerability by modifying some configuration to cause out-of-bound read and write, causing denial of service. (Vulnerability ID: HWPSIRT-2020-05103)
This vulnerability has been assigned a Common Vulnerabilities and Exposures (CVE) ID: CVE-2020-9211.
{
"affected": [],
"aliases": [
"CVE-2020-9211"
],
"database_specific": {
"cwe_ids": [
"CWE-125"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2024-12-27T10:15:14Z",
"severity": "MODERATE"
},
"details": "There is an out-of-bound read and write vulnerability in Huawei smartphone. A module dose not verify the input sufficiently. Attackers can exploit this vulnerability by modifying some configuration to cause out-of-bound read and write, causing denial of service. (Vulnerability ID: HWPSIRT-2020-05103)\n\nThis vulnerability has been assigned a Common Vulnerabilities and Exposures (CVE) ID: CVE-2020-9211.",
"id": "GHSA-xx24-r484-7p82",
"modified": "2024-12-27T12:30:35Z",
"published": "2024-12-27T12:30:35Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2020-9211"
},
{
"type": "WEB",
"url": "https://www.huawei.com/en/psirt/security-advisories/2021/huawei-sa-20210106-01-smartphone-en"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:L/AC:H/PR:H/UI:N/S:U/C:H/I:H/A:H",
"type": "CVSS_V3"
}
]
}
GHSA-XX2V-HW92-QXMX
Vulnerability from github – Published: 2026-06-05 00:31 – Updated: 2026-06-05 18:31Integer overflow in Fonts in Google Chrome prior to 149.0.7827.53 allowed a remote attacker to obtain potentially sensitive information from process memory via a crafted HTML page. (Chromium security severity: Low)
{
"affected": [],
"aliases": [
"CVE-2026-11299"
],
"database_specific": {
"cwe_ids": [
"CWE-125",
"CWE-190"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2026-06-05T00:17:07Z",
"severity": "MODERATE"
},
"details": "Integer overflow in Fonts in Google Chrome prior to 149.0.7827.53 allowed a remote attacker to obtain potentially sensitive information from process memory via a crafted HTML page. (Chromium security severity: Low)",
"id": "GHSA-xx2v-hw92-qxmx",
"modified": "2026-06-05T18:31:39Z",
"published": "2026-06-05T00:31:55Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-11299"
},
{
"type": "WEB",
"url": "https://chromereleases.googleblog.com/2026/06/stable-channel-update-for-desktop.html"
},
{
"type": "WEB",
"url": "https://issues.chromium.org/issues/502598424"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:N/AC:L/PR:N/UI:R/S:U/C:H/I:N/A:N",
"type": "CVSS_V3"
}
]
}
GHSA-XX42-XVV9-8P8P
Vulnerability from github – Published: 2022-05-17 00:57 – Updated: 2022-05-17 00:57The compositor in Google Chrome before 22.0.1229.92 allows remote attackers to cause a denial of service (out-of-bounds read) via unspecified vectors.
{
"affected": [],
"aliases": [
"CVE-2012-5110"
],
"database_specific": {
"cwe_ids": [
"CWE-125"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2012-10-09T11:13:00Z",
"severity": "MODERATE"
},
"details": "The compositor in Google Chrome before 22.0.1229.92 allows remote attackers to cause a denial of service (out-of-bounds read) via unspecified vectors.",
"id": "GHSA-xx42-xvv9-8p8p",
"modified": "2022-05-17T00:57:45Z",
"published": "2022-05-17T00:57:45Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2012-5110"
},
{
"type": "WEB",
"url": "https://code.google.com/p/chromium/issues/detail?id=151449"
},
{
"type": "WEB",
"url": "https://oval.cisecurity.org/repository/search/definition/oval%3Aorg.mitre.oval%3Adef%3A14901"
},
{
"type": "WEB",
"url": "http://googlechromereleases.blogspot.com/2012/10/stable-channel-update.html"
}
],
"schema_version": "1.4.0",
"severity": []
}
GHSA-XX4G-62M6-V2W7
Vulnerability from github – Published: 2025-03-03 03:31 – Updated: 2025-03-04 18:33In V5 DA, there is a possible out of bounds read due to a missing bounds check. This could lead to local information disclosure, if an attacker has physical access to the device, with no additional execution privileges needed. User interaction is needed for exploitation. Patch ID: ALPS09291215; Issue ID: MSV-2052.
{
"affected": [],
"aliases": [
"CVE-2025-20652"
],
"database_specific": {
"cwe_ids": [
"CWE-125"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2025-03-03T03:15:10Z",
"severity": "MODERATE"
},
"details": "In V5 DA, there is a possible out of bounds read due to a missing bounds check. This could lead to local information disclosure, if an attacker has physical access to the device, with no additional execution privileges needed. User interaction is needed for exploitation. Patch ID: ALPS09291215; Issue ID: MSV-2052.",
"id": "GHSA-xx4g-62m6-v2w7",
"modified": "2025-03-04T18:33:29Z",
"published": "2025-03-03T03:31:19Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-20652"
},
{
"type": "WEB",
"url": "https://corp.mediatek.com/product-security-bulletin/March-2025"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:P/AC:L/PR:N/UI:N/S:U/C:H/I:N/A:N",
"type": "CVSS_V3"
}
]
}
GHSA-XX4J-RVCC-2VHR
Vulnerability from github – Published: 2022-05-24 16:45 – Updated: 2026-06-10 18:43Capstone 3.0.4 has an out-of-bounds vulnerability (SEGV caused by a read memory access) in X86_insn_reg_intel in arch/X86/X86Mapping.c.
{
"affected": [
{
"package": {
"ecosystem": "PyPI",
"name": "capstone"
},
"ranges": [
{
"events": [
{
"introduced": "0"
},
{
"fixed": "4.0.0"
}
],
"type": "ECOSYSTEM"
}
]
}
],
"aliases": [
"CVE-2016-7151"
],
"database_specific": {
"cwe_ids": [
"CWE-125"
],
"github_reviewed": true,
"github_reviewed_at": "2024-11-21T22:19:31Z",
"nvd_published_at": "2019-05-15T14:29:00Z",
"severity": "MODERATE"
},
"details": "Capstone 3.0.4 has an out-of-bounds vulnerability (SEGV caused by a read memory access) in X86_insn_reg_intel in arch/X86/X86Mapping.c.",
"id": "GHSA-xx4j-rvcc-2vhr",
"modified": "2026-06-10T18:43:14Z",
"published": "2022-05-24T16:45:42Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2016-7151"
},
{
"type": "WEB",
"url": "https://github.com/aquynh/capstone/pull/725"
},
{
"type": "WEB",
"url": "https://github.com/aquynh/capstone/commit/87a25bb543c8e4c09b48d4b4a6c7db31ce58df06"
},
{
"type": "PACKAGE",
"url": "https://github.com/capstone-engine/capstone"
},
{
"type": "WEB",
"url": "https://github.com/pypa/advisory-database/tree/main/vulns/capstone/PYSEC-2019-242.yaml"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.0/AV:L/AC:L/PR:N/UI:R/S:U/C:N/I:N/A:H",
"type": "CVSS_V3"
}
],
"summary": "Capstone SEGV caused by a read memory access"
}
GHSA-XX4P-CQFX-R6V6
Vulnerability from github – Published: 2023-06-28 18:30 – Updated: 2024-04-04 05:15In initiateTdlsTeardownInternal of sta_iface.cpp, there is a possible out of bounds read due to a missing bounds check. This could lead to local information disclosure in the wifi server with System execution privileges needed. User interaction is not needed for exploitation.Product: AndroidVersions: Android-13Android ID: A-262235951
{
"affected": [],
"aliases": [
"CVE-2023-21213"
],
"database_specific": {
"cwe_ids": [
"CWE-125"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2023-06-28T18:15:16Z",
"severity": "MODERATE"
},
"details": "In initiateTdlsTeardownInternal of sta_iface.cpp, there is a possible out of bounds read due to a missing bounds check. This could lead to local information disclosure in the wifi server with System execution privileges needed. User interaction is not needed for exploitation.Product: AndroidVersions: Android-13Android ID: A-262235951",
"id": "GHSA-xx4p-cqfx-r6v6",
"modified": "2024-04-04T05:15:52Z",
"published": "2023-06-28T18:30:26Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2023-21213"
},
{
"type": "WEB",
"url": "https://source.android.com/security/bulletin/pixel/2023-06-01"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:L/AC:L/PR:H/UI:N/S:U/C:H/I:N/A:N",
"type": "CVSS_V3"
}
]
}
GHSA-XX4W-8H42-JM57
Vulnerability from github – Published: 2025-09-16 00:30 – Updated: 2025-11-03 21:34An out-of-bounds access issue was addressed with improved bounds checking. This issue is fixed in tvOS 26, watchOS 26, visionOS 26, macOS Tahoe 26, iOS 26 and iPadOS 26. An app may be able to cause unexpected system termination.
{
"affected": [],
"aliases": [
"CVE-2025-43344"
],
"database_specific": {
"cwe_ids": [
"CWE-125"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2025-09-15T23:15:36Z",
"severity": "LOW"
},
"details": "An out-of-bounds access issue was addressed with improved bounds checking. This issue is fixed in tvOS 26, watchOS 26, visionOS 26, macOS Tahoe 26, iOS 26 and iPadOS 26. An app may be able to cause unexpected system termination.",
"id": "GHSA-xx4w-8h42-jm57",
"modified": "2025-11-03T21:34:34Z",
"published": "2025-09-16T00:30:25Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-43344"
},
{
"type": "WEB",
"url": "https://support.apple.com/en-us/125108"
},
{
"type": "WEB",
"url": "https://support.apple.com/en-us/125110"
},
{
"type": "WEB",
"url": "https://support.apple.com/en-us/125114"
},
{
"type": "WEB",
"url": "https://support.apple.com/en-us/125115"
},
{
"type": "WEB",
"url": "https://support.apple.com/en-us/125116"
},
{
"type": "WEB",
"url": "http://seclists.org/fulldisclosure/2025/Sep/49"
},
{
"type": "WEB",
"url": "http://seclists.org/fulldisclosure/2025/Sep/53"
},
{
"type": "WEB",
"url": "http://seclists.org/fulldisclosure/2025/Sep/57"
},
{
"type": "WEB",
"url": "http://seclists.org/fulldisclosure/2025/Sep/58"
}
],
"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:L",
"type": "CVSS_V3"
}
]
}
GHSA-XX5W-CVP6-JV83
Vulnerability from github – Published: 2026-04-10 15:31 – Updated: 2026-04-10 15:31Impact
Wasmtime with its Winch (baseline) non-default compiler backend may allow properly constructed guest Wasm to access host memory outside of its linear-memory sandbox.
This vulnerability requires use of the Winch compiler (-Ccompiler=winch). By default, Wasmtime uses its Cranelift backend, not Winch. With Winch, the same incorrect assumption is present in theory on both aarch64 and x86-64. The aarch64 case has an observed-working proof of concept, while the x86-64 case is theoretical and may not be reachable in practice.
This Winch compiler bug can allow the Wasm guest to access memory before or after the linear-memory region, independently of whether pre- or post-guard regions are configured. The accessible range in the initial bug proof-of-concept is up to 32KiB before the start of memory, or ~4GiB after the start of memory, independently of the size of pre- or post-guard regions or the use of explicit or guard-region-based bounds checking. However, the underlying bug assumes a 32-bit memory offset stored in a 64-bit register has its upper bits cleared when it may not, and so closely related variants of the initial proof-of-concept may be able to access truly arbitrary memory in-process. This could result in a host process segmentation fault (DoS), an arbitrary data leak from the host process, or with a write, potentially an arbitrary RCE.
Patches
Wasmtime 43.0.1, 42.0.2, and 36.0.7 have been released with fixes for this issue.
Workaround
There are no workarounds within the Winch compiler backend while using the affected versions. Users of Wasmtime are encouraged either to upgrade to patched versions or, if that is not possible, use the Cranelift compiler backend.
{
"affected": [
{
"package": {
"ecosystem": "crates.io",
"name": "wasmtime"
},
"ranges": [
{
"events": [
{
"introduced": "25.0.0"
},
{
"fixed": "36.0.7"
}
],
"type": "ECOSYSTEM"
}
]
},
{
"package": {
"ecosystem": "crates.io",
"name": "wasmtime"
},
"ranges": [
{
"events": [
{
"introduced": "37.0.0"
},
{
"fixed": "42.0.2"
}
],
"type": "ECOSYSTEM"
}
]
},
{
"package": {
"ecosystem": "crates.io",
"name": "wasmtime"
},
"ranges": [
{
"events": [
{
"introduced": "43.0.0"
},
{
"fixed": "43.0.1"
}
],
"type": "ECOSYSTEM"
}
],
"versions": [
"43.0.0"
]
}
],
"aliases": [
"CVE-2026-34987"
],
"database_specific": {
"cwe_ids": [
"CWE-125",
"CWE-787"
],
"github_reviewed": true,
"github_reviewed_at": "2026-04-10T15:31:18Z",
"nvd_published_at": "2026-04-09T19:16:25Z",
"severity": "CRITICAL"
},
"details": "### Impact\n\nWasmtime with its Winch (baseline) non-default compiler backend may allow properly constructed guest Wasm to access host memory outside of its linear-memory sandbox.\n\nThis vulnerability requires use of the Winch compiler (`-Ccompiler=winch`). By default, Wasmtime uses its Cranelift backend, not Winch. With Winch, the same incorrect assumption is present in theory on both aarch64 and x86-64. The aarch64 case has an observed-working proof of concept, while the x86-64 case is theoretical and may not be reachable in practice.\n\nThis Winch compiler bug can allow the Wasm guest to access memory before or after the linear-memory region, independently of whether pre- or post-guard regions are configured. The accessible range in the initial bug proof-of-concept is up to 32KiB before the start of memory, or ~4GiB after the start of memory, independently of the size of pre- or post-guard regions or the use of explicit or guard-region-based bounds checking. However, the underlying bug assumes a 32-bit memory offset stored in a 64-bit register has its upper bits cleared when it may not, and so closely related variants of the initial proof-of-concept may be able to access truly arbitrary memory in-process. This could result in a host process segmentation fault (DoS), an arbitrary data leak from the host process, or with a write, potentially an arbitrary RCE.\n\n### Patches\n\nWasmtime 43.0.1, 42.0.2, and 36.0.7 have been released with fixes for this issue.\n\n### Workaround\n\nThere are no workarounds within the Winch compiler backend while using the affected versions. Users of Wasmtime are encouraged either to upgrade to patched versions or, if that is not possible, use the Cranelift compiler backend.",
"id": "GHSA-xx5w-cvp6-jv83",
"modified": "2026-04-10T15:31:18Z",
"published": "2026-04-10T15:31:18Z",
"references": [
{
"type": "WEB",
"url": "https://github.com/bytecodealliance/wasmtime/security/advisories/GHSA-xx5w-cvp6-jv83"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-34987"
},
{
"type": "PACKAGE",
"url": "https://github.com/bytecodealliance/wasmtime"
},
{
"type": "WEB",
"url": "https://rustsec.org/advisories/RUSTSEC-2026-0095.html"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:4.0/AV:N/AC:L/AT:P/PR:N/UI:N/VC:H/VI:H/VA:H/SC:N/SI:N/SA:N",
"type": "CVSS_V4"
}
],
"summary": "Wasmtime with Winch compiler backend on aarch64 may allow a sandbox-escaping memory access"
}
GHSA-XX79-4755-JQ22
Vulnerability from github – Published: 2023-11-16 12:30 – Updated: 2024-08-29 15:30SSH dissector crash in Wireshark 4.0.0 to 4.0.10 allows denial of service via packet injection or crafted capture file
{
"affected": [],
"aliases": [
"CVE-2023-6174"
],
"database_specific": {
"cwe_ids": [
"CWE-125",
"CWE-74"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2023-11-16T12:15:07Z",
"severity": "MODERATE"
},
"details": "SSH dissector crash in Wireshark 4.0.0 to 4.0.10 allows denial of service via packet injection or crafted capture file",
"id": "GHSA-xx79-4755-jq22",
"modified": "2024-08-29T15:30:30Z",
"published": "2023-11-16T12:30:21Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2023-6174"
},
{
"type": "WEB",
"url": "https://gitlab.com/wireshark/wireshark/-/issues/19369"
},
{
"type": "WEB",
"url": "https://lists.fedoraproject.org/archives/list/package-announce@lists.fedoraproject.org/message/34DBP5P2RHQ7XUABPANYYMOGV5KS6VEP"
},
{
"type": "WEB",
"url": "https://lists.fedoraproject.org/archives/list/package-announce@lists.fedoraproject.org/message/MADSCHKZSCKQ5NLIX3UMOIJD2JZ65L4V"
},
{
"type": "WEB",
"url": "https://security.gentoo.org/glsa/202402-09"
},
{
"type": "WEB",
"url": "https://www.debian.org/security/2023/dsa-5559"
},
{
"type": "WEB",
"url": "https://www.wireshark.org/security/wnpa-sec-2023-28.html"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:N/AC:L/PR:N/UI:R/S:U/C:L/I:L/A:L",
"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.
- To reduce the likelihood of introducing an out-of-bounds read, ensure that you validate and ensure correct calculations for any length argument, buffer size calculation, or offset. Be especially careful of relying on a sentinel (i.e. special character such as NUL) in untrusted inputs.
Mitigation
Strategy: Language Selection
Use a language that provides appropriate memory abstractions.
CAPEC-540: Overread Buffers
An adversary attacks a target by providing input that causes an application to read beyond the boundary of a defined buffer. This typically occurs when a value influencing where to start or stop reading is set to reflect positions outside of the valid memory location of the buffer. This type of attack may result in exposure of sensitive information, a system crash, or arbitrary code execution.