Mtholmquist

Hugo is a static site generator. From v0.161.0, Hugo executes Node tools under Node's permission model, but TailwindCSS — included in the default security.exec.allow list — requires a highly permissive configuration (--allow-addons, --allow-child-process, --allow-worker). As a result, the restrictions intended by the fix for GHSA-x597-9fr4-5857 could still be bypassed, allowing a Node tool invoked during a build to read and write files outside the project's working directory. Affected versions are those after v0.43; the issue was fixed in v0.165.0 by removing tailwindcss from the default security.exec.allow list. Users who do not use TailwindCSS, or who only build trusted sites, are not affected. As a workaround, users can define a restrictive security.exec.allow list in hugo.toml.

**Name of the Vulnerable Software and Affected Versions** hank-ai/darknet (affected versions not specified) **Description** The software calculates the size of weight and output heap buffers for a convolutional layer using unchecked 32-bit integer arithmetic based on fields from a `.cfg` file. In the file `src-lib/convolutional layer.cpp`, the variables `l.nweights` and `l.outputs` are computed and passed to `xcalloc`. If the product of the dimensions in the `.cfg` file exceeds `INT MAX`, an integer overflow occurs, resulting in an undersized buffer allocation. Subsequently, the `forward convolutional layer` function re-derives the GEMM (General Matrix Multiply) dimensions using a different operand order, leading to out-of-bounds read and write operations through the undersized buffer. This can be triggered by loading a specially crafted `.cfg` file during inference or training, without requiring a valid `.weights` file. This issue can lead to heap buffer overflow reads in `gemm nn fast()` and glibc allocator metadata corruption. **Recommendations** At the moment, there is no information about a newer version that contains a fix for this vulnerability.

**Name of the Vulnerable Software and Affected Versions** msgpack-c (affected versions not specified) **Description** An integer overflow occurs in the `msgpack unpacker expand buffer` function within `src/unpack.c`, which is accessible via the `msgpack unpacker reserve buffer` API. The function calculates the new buffer size using an unchecked `size t` addition of the requested size and the amount already used. When a request near `SIZE MAX` is made, the addition wraps, causing the loop condition to be satisfied prematurely. Consequently, the allocation is performed at a small pre-wrap size, but the function returns a success status. This leads the caller to believe the requested capacity was reserved, resulting in a heap buffer overflow during subsequent write operations. This issue can be triggered in integrations that pass attacker-influenced lengths to the reservation API, such as length-prefixed streaming transports. **Recommendations** At the moment, there is no information about a newer version that contains a fix for this vulnerability.