GitLab Advisory Database (GLAD)

download_wheel() runs pip download and hands the result straight to the seeder, with nothing checking the bytes it gets back. The embedded pip and setuptools wheels carry a BUNDLE_SHA256 that virtualenv checks on every load, but a wheel fetched over the network for the periodic-update feature or the –download flag had no equivalent verification. A compromised index, a stale mirror, or a MITM'd download (when TLS is intercepted, e.g. via …

pyvenv.cfg is a line-based format with no escape syntax. PyEnvCfg.write() wrote values verbatim, while PyEnvCfg._read_values() parses the file with str.splitlines(). A value containing a line boundary therefore became additional configuration lines, and because reading is last-wins, the injected keys replaced any key written earlier in the file.

urllib3 supports configuring TLS independently for an HTTPS proxy and the target server. proxy_ssl_context, proxy_assert_hostname, and proxy_assert_fingerprint configure the TLS connection to the proxy. ssl_context and the other target-specific TLS parameters configure the connection to the target server. In urllib3 versions 1.26.0 through 2.7.0, these configurations were not consistently separated. Depending on the proxy mode, urllib3 could: Ignore proxy_ssl_context and use the target server's SSL context for the TLS connection …

urllib3's streaming API is designed for efficiently handling large HTTP responses by reading the content in chunks, rather than loading the entire response body into memory at once. When decoding a chunked-transfer-encoded response, this API reads each chunk's size field by buffering until it sees \n or EOF. A malicious HTTP server can return Transfer-Encoding: chunked and then send a very long run of bytes without any newline, causing the …

urllib3's streaming API is designed for the efficient handling of large HTTP responses by reading content in chunks instead of loading the entire response body into memory at once. urllib3 can decompress response bodies according to the HTTP Content-Encoding header. When streaming a compressed, chunked response, urllib3 first consumes data already buffered by the decoder before reading the next HTTP chunk. However, urllib3 versions from 2.6.2 through 2.7.0 could enter …

HTTPServerRequest.init in tornado/httputil.py parses the URL query string via parse_qs_bytes() with no field-count limit — while the sibling POST-body parsing path (parse_body_arguments) received a max_num_fields=1000 cap added earlier in this exact same release (v6.5.8, commit 8d6363ed), explicitly to bound parsing cost for the identical underlying primitive. This leaves the query-string path with the resource-exhaustion exposure the body-path fix was meant to close. File: tornado/httputil.py, line 553 (HTTPServerRequest.init)

StaticFileHandler allows an unauthenticated attacker to read arbitrary files from the server's filesystem by requesting a path that resolves to a symbolic link placed inside the static root directory. Any application that serves user-uploadable content, or whose static directory is populated by a build/deploy pipeline that creates symlinks (e.g. npm link, webpack, Docker volume mounts, CDN sync tools), is affected. An attacker who can trigger the creation of a symlink …

An unbounded memory accumulation (decompression bomb) in tornado.curl_httpclient.CurlAsyncHTTPClient — the client-side sibling gap of CVE-2026-49855 — verified end-to-end on the 2026-08-15 master snapshot (6.6.dev1) and present unchanged in the latest release tag v6.5.8 and on master (checked 2026-08-17). When a Tornado application configures the curl client (the documented deployment for proxy support / advanced TLS options) and fetch()es an attacker-chosen or attacker-compromised URL with default decompress_response=True, a malicious server replying …

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.