GitLab Advisory Database (GLAD)

vm2 bufferAllocLimit cap bypassed by Buffer.concat and Buffer.from arrayLike The bufferAllocLimit option introduced in 3.11.0 (GHSA-6785-pvv7-mvg7) caps host-side Buffer allocations driven by sandbox code, the way embedders opt into timeout. The cap wraps Buffer.alloc, Buffer.allocUnsafe, Buffer.allocUnsafeSlow, and the deprecated Buffer(N) / new Buffer(N) forms. Two other API paths reach the same host C++ allocator with an attacker-controlled size and are not capped: Buffer.concat(list, totalLength) and Buffer.from(arrayLike) with a fake length. …

VM2 suffers from a sandbox breakout vulnerability. This allows attackers to write code which can escape from the VM2 sandbox and execute arbitrary commands on the host system.

GHSA-9g8x-92q2-p28f closed the "process-wide observability builtins" class by adding diagnostics_channel, async_hooks, perf_hooks, and v8 to DANGEROUS_BUILTINS in lib/builtin.js. The fix's rationale (in the commit message and docs/ATTACKS.md Category 35) is general: Process-wide observability builtins. Unlike most Node builtins, these expose state of the entire host process rather than sandbox-local state — the vm2 boundary cannot usefully contain them because the data they surface […] belongs to the embedder. Even a …

I found that handleException() in lib/setup-sandbox.js recursively sanitizes sub-errors for SuppressedError and AggregateError, but completely ignores the ES2022 Error.cause property. When sandbox code catches a host-thrown error carrying a .cause that references a host object like process, it can traverse that reference to achieve arbitrary command execution on the host. The project's own docs/ATTACKS.md (Defense Invariant #3, line 54) explicitly claims Error.cause is sanitized. The implementation does not match this …

The bufferAllocLimit defense (GHSA-6785-pvv7-mvg7) can be completely bypassed using ArrayBuffer, SharedArrayBuffer, or any TypedArray constructor. These allocate identical host-process RSS through the same V8/libuv C++ allocation path as Buffer.alloc but are not subject to the size cap.

The sigstore check on metadata.json is gated on the wrong side of the condition. LoadMetadata in internal/config/update.go:81 verifies the bundle only when UNIGET_IGNORE_METADATA_SIGNATURE is non-empty, so in a normal run, where nobody sets that variable, the signature is never checked. Setting the variable that is named "ignore the signature" is what turns verification on. That matters because metadata.json populates Tool.Check, and pkg/tool/tool.go:250 runs Tool.Check through /bin/bash -c. That is the …

Path Traversal vulnerability in hook filename handling allows attackers to access and manipulate arbitrary files outside the hooks directory via directory escape sequences like passwd. Details File: hooks.go Lines 135-160 hookFileName := args[0] // User input not validated hookFile = preInstallHooksDir + "/" + hookFileName // Direct concatenation Hook filenames are concatenated directly without sanitizing ../ sequences, allowing directory traversal.

The uniget CLI has a command injection vulnerability in hooks.go line 199 where strings.Split(editor, " ") naively parses the EDITOR environment variable without respecting shell syntax. An attacker can set EDITOR="/path/to/wrapper && id && echo" which gets split into separate arguments, allowing the wrapper script to execute arbitrary commands like id. This was successfully exploited to execute uid=1000(w4nn4d13), confirming code execution is possible. The vulnerability affects hook editing and breaks …

Insufficient clearing of the output buffer in Java-based decompressor implementations in lz4-java 1.10.0 and earlier allows remote attackers to read previous buffer contents via crafted compressed input. In applications where the output buffer is reused without being cleared, this may lead to disclosure of sensitive data. JNI-based implementations are not affected.

Insufficient clearing of the output buffer in Java-based decompressor implementations in lz4-java 1.10.0 and earlier allows remote attackers to read previous buffer contents via crafted compressed input. In applications where the output buffer is reused without being cleared, this may lead to disclosure of sensitive data. JNI-based implementations are not affected.

Insufficient clearing of the output buffer in Java-based decompressor implementations in lz4-java 1.10.0 and earlier allows remote attackers to read previous buffer contents via crafted compressed input. In applications where the output buffer is reused without being cleared, this may lead to disclosure of sensitive data. JNI-based implementations are not affected.

This advisory has been marked as a false positive.

This advisory has been marked as a false positive.

This advisory has been marked as a false positive.

This advisory has been marked as False Positive and has been removed.

After an API Token exposure from an exploited trivy dependency, two new releases of litellm were uploaded to PyPI containing automatically activated malware, harvesting sensitive credentials and files, and exfiltrating to a remote API. Anyone who has installed and run the project should assume any credentials available to litellm environment may have been exposed, and revoke/rotate thema ccordingly.