Search the public rule index by CVE, GHSA, CWE, language, framework, author, or rule slug. Filter by language, framework, severity, confidence, license, and validation status.
Data volume expansion using derived multiplier without prior maximum limits. An attacker can provide large arbitrary dimension variables that result in massive memory allocations, causing Out-Of-Memory (OOM) application denial of service. Ensure the dimensions or the resultant buffer sizes are constrained against a maximum limit before memory expansion / str
Bypassing Pillow's decompression bomb check when parsing dimensions can allow attackers to cause Denial of Service (DoS) via excessive memory allocation. Always call `Image._decompression_bomb_check((width, height))` before allocating image bitmaps internally or accumulating font metrics.
Dimensions parsed from input are multiplied to allocate a vector without verifying that the input buffer length (end - start) is sufficient for the requested number of elements.
An integer converted directly from a string is used to allocate a slice with make() without bounds validation. An attacker providing a large integer could cause excessive memory allocation and denial of service.
An integer subtraction is used for a slice allocation size without a prior bounds check. If the right-hand side of the subtraction is larger than the left-hand side, an unsigned integer underflow may occur, resulting in an exceptionally large allocation and potentially causing a Denial of Service (DoS) via an out-of-memory crash. Verify that the left-hand si
A 64-bit integer value is narrowed or truncated to a 32-bit int before bounds validation, which can allow values exceeding 32-bit limits to wrap around and bypass size checks.
String or list multiplication with dynamically calculated values may lead to uncontrolled memory consumption and Denial of Service (DoS). Ensure the sequence multiplier is explicitly bounded before execution.
An integer count decoded from untrusted external data is passed to Vec::with_capacity without bounding it against the remaining readable packet/buffer bytes. A crafted large count (e.g. u32::MAX ~4 billion) can trigger a multi-gigabyte heap allocation, crashing the process via OOM before any credential is verified (pre-auth DoS). Clamp the decoded count to t
An array is allocated using a length directly read from a stream or payload without bounded validation. An attacker can supply an artificially large variable length, triggering an excessive memory allocation that exhausts JVM memory (OutOfMemoryError) and leads to Denial of Service (DoS). Always check that the requested size does not exceed the remaining ava
Eagerly allocating a buffer based on an unverified length before asynchronously reading chunks can lead to Denial of Service (DoS) via memory exhaustion. Defend against this by deferring allocation until all chunks are successfully read or validating the requested length against known HTTP Content-Length bounds.
An array is allocated using a size directly from a method parameter without an explicit upper bound check wrapping the allocation. If the size is controlled by an attacker during parsing or deserialization, this can lead to unbounded memory allocation, OutOfMemoryError, and Denial of Service (DoS). Validate the size against a reasonable threshold before allo
