This site offers a simple way to search for advisories in the legacy GitLab Advisory Database, a subset of the GitLab Advisory Database (GLAD) that does not include proprietary advisories.
Dependency Scanning with Gemnasium uses this legacy database. Dependency Scanning using SBOM and continuous vulnerability scanning use the full GLAD, including proprietary advisories.
When using one of the ZipUtil.unpack overloads, the file permissions of the output directory can be changed. For example, when the output directory was only accessible to the 'owner' it could be instead made accessible to every OS user.
ZipUtil.unpack(…) rejects ZIP entries that escape the target output directory, but the Zips fluent API appears to use a separate unpack implementation that does not apply the same destination-boundary check. A ZIP entry such as: ../escape/poc.txt is written outside the configured destination directory when processed with: Zips.get(zip).unpack().destination(outputDir).process(); The transformer branch is affected as well.
zizmor 1.27.0 exposes GitHub access tokens in cleartext when debug-level logging is enabled. Tokens supplied via environment variables (GH_TOKEN, GITHUB_TOKEN, ZIZMOR_GITHUB_TOKEN), or the corresponding command-line options (–gh-token, –github-token, –zizmor-github-token) are included in the debug representation of the parsed application configuration and written to stderr. The affected logging is enabled by a single -v/–verbose or an applicable RUST_LOG directive.
The sql() VQL plugin runs a caller-supplied database driver and connection string with no permission check (vql/parsers/sql/sql.go:93, SQLPlugin.Call). For driver='mysql' or driver='postgres' the handle comes from GetHandleOther (sql.go:39), which passes the connection string straight to Go database/sql sql.Open (sql.go:51) and executes the query (sql.go:159). The plugin declares FILESYSTEM_READ only as Info().Permissions metadata (sql.go:219). That metadata is never consulted at runtime: metadata.go:19 stores it as a string that only the documentation …
The handle_short_request() function in urwid/display/web.py raises an unhandled UnicodeEncodeError when processing a POST request body containing non-ASCII bytes. The function reads POST input and encodes it to ASCII before writing to a named pipe. Any byte value above 0x7F causes the CGI process to exit with an unhandled exception, returning an HTTP 500 error to the client. Additionally, a file descriptor opened earlier in the same function is not closed …
The HTTP server mode of @tsparticles/mcp-server accumulates all incoming request body chunks into an in-memory Buffer[] array with no size limit before calling JSON.parse. An unauthenticated remote attacker can stream an arbitrarily large body to POST /mcp, exhausting the Node.js process memory and causing a Denial of Service. The official Docker image ships with HTTP mode enabled by default (–port 3000 on 0.0.0.0), making this exploitable without any special configuration …
The HTTP mode of @tsparticles/mcp-server parses incoming /mcp request bodies with JSON.parse() outside a request-local error boundary. A single malformed JSON request causes the async request handler to throw and terminates the Node.js process. This was verified on v4.3.0 at commit 0266d469aa2d719cb66a9c6bf09aded4186ec17c. Version 4.3.1 appears to fix this by returning HTTP 400 for invalid JSON.
The HTTP mode of @tsparticles/mcp-server creates a single stateful StreamableHTTPServerTransport instance and reuses it for all clients. The first anonymous client that initializes the MCP endpoint claims the shared transport state, and later clients cannot create their own sessions. This was verified on v4.3.0 at commit 0266d469aa2d719cb66a9c6bf09aded4186ec17c. The same singleton transport pattern is still present in v4.3.1 and current main.
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.