cryptography is a package designed to expose cryptographic primitives and recipes to Python developers. From 45.0.0 to before 46.0.7, if a non-contiguous buffer was passed to APIs which accepted Python buffers (e.g. Hash.update()), this could lead to buffer overflows. This vulnerability is fixed in 46.0.7.

Impact

When an application passes user-controlled input to the upgrade option of client.request(), an attacker can inject CRLF sequences (\r\n) to:

1. Inject arbitrary HTTP headers 2. Terminate the HTTP request prematurely and smuggle raw data to non-HTTP services (Redis, Memcached, Elasticsearch)

The vulnerability exists because undici writes the upgrade value directly to the socket without validating for invalid header characters:

javascript // lib/dispatcher/client-h1.js:1121 if (upgrade) { header += connection: upgrade\r\nupgrade: ${upgrade}\r\n }

Patches

Patched in the undici version v7.24.0 and v6.24.0. Users should upgrade to this version or later.

Workarounds

Sanitize the upgrade option string before passing to undici:

javascript function sanitizeUpgrade(value) { if (/[\r\n]/.test(value)) { throw new Error('Invalid upgrade value') } return value }

client.request({ upgrade: sanitizeUpgrade(userInput) })

Impact

Undici fetch() uses Math.random() to choose the boundary for a multipart/form-data request. It is known that the output of Math.random() can be predicted if several of its generated values are known.

If there is a mechanism in an app that sends multipart requests to an attacker-controlled website, they can use this to leak the necessary values. Therefore, An attacker can tamper with the requests going to the backend APIs if certain conditions are met.

Patches

This is fixed in 5.28.5; 6.21.1; 7.2.3.

Workarounds

Do not issue multipart requests to attacker controlled servers.

References

https://hackerone.com/reports/2913312 https://blog.securityevaluators.com/hacking-the-javascript-lottery-80cc437e3b7f

A vulnerability was found in Undertow. This issue requires enabling the learning-push handler in the server's config, which is disabled by default, leaving the maxAge config in the handler unconfigured. The default is -1, which makes the handler vulnerable. If someone overwrites that config, the server is not subject to the attack. The attacker needs to be able to reach the server with a normal HTTP request.

Summary The arrayLimit option in qs does not enforce limits for comma-separated values when comma: true is enabled, allowing attackers to cause denial-of-service via memory exhaustion. This is a bypass of the array limit enforcement, similar to the bracket notation bypass addressed in GHSA-6rw7-vpxm-498p (CVE-2025-15284).

Details When the comma option is set to true (not the default, but configurable in applications), qs allows parsing comma-separated strings as arrays (e.g., ?param=a,b,c becomes ['a', 'b', 'c']). However, the limit check for arrayLimit (default: 20) and the optional throwOnLimitExceeded occur after the comma-handling logic in parseArrayValue, enabling a bypass. This permits creation of arbitrarily large arrays from a single parameter, leading to excessive memory allocation.

Vulnerable code (lib/parse.js: lines ~40-50): js if (val && typeof val === 'string' && options.comma && val.indexOf(',') -1) {     return val.split(','); }

if (options.throwOnLimitExceeded && currentArrayLength = options.arrayLimit) {     throw new RangeError('Array limit exceeded. Only ' + options.arrayLimit + ' element' + (options.arrayLimit === 1 ? '' : 's') + ' allowed in an array.'); }

return val; The split(',') returns the array immediately, skipping the subsequent limit check. Downstream merging via utils.combine does not prevent allocation, even if it marks overflows for sparse arrays.This discrepancy allows attackers to send a single parameter with millions of commas (e.g., ?param=,,,,,,,,...), allocating massive arrays in memory without triggering limits. It bypasses the intent of arrayLimit, which is enforced correctly for indexed (a[0]=) and bracket (a[]=) notations (the latter fixed in v6.14.1 per GHSA-6rw7-vpxm-498p).

PoC Test 1 - Basic bypass: npm install qs

js const qs = require('qs');

const payload = 'a=' + ','.repeat(25); // 26 elements after split (bypasses arrayLimit: 5) const options = { comma: true, arrayLimit: 5, throwOnLimitExceeded: true };

try {   const result = qs.parse(payload, options);   console.log(result.a.length); // Outputs: 26 (bypass successful) } catch (e) {   console.log('Limit enforced:', e.message); // Not thrown } Configuration: - comma: true - arrayLimit: 5 - throwOnLimitExceeded: true

Expected: Throws "Array limit exceeded" error. Actual: Parses successfully, creating an array of length 26.

Impact Denial of Service (DoS) via memory exhaustion.

Summary The HttpPostRequestDecoder can be tricked to accumulate data. I have spotted currently two attack vectors

Details 1. While the decoder can store items on the disk if configured so, there are no limits to the number of fields the form can have, an attacher can send a chunked post consisting of many small fields that will be accumulated in the bodyListHttpData list. 2. The decoder cumulates bytes in the undecodedChunk buffer until it can decode a field, this field can cumulate data without limits

PoC

Here is a Netty branch that provides a fix + tests : https://github.com/vietj/netty/tree/post-request-decoder

Here is a reproducer with Vert.x (which uses this decoder) https://gist.github.com/vietj/f558b8ea81ec6505f1e9a6ca283c9ae3

Impact Any Netty based HTTP server that uses the HttpPostRequestDecoder to decode a form.

A flaw was found in the snakeyaml package due to a stack-overflow in parsing YAML files. By persuading a victim to open a specially-crafted file, a remote attacker could cause the application to crash.

A flaw was found in the snakeyaml package due to a stack-overflow in parsing YAML files. By persuading a victim to open a specially-crafted file, a remote attacker could cause the application to crash, resulting in a denial of service.

A flaw was found in the snakeyaml package due to a stack-overflow in parsing YAML files. By persuading a victim to open a specially-crafted file, a remote attacker could cause the application to crash.

A flaw was found in the snakeyaml package due to a stack-overflow in parsing YAML files. By persuading a victim to open a specially-crafted file, a remote attacker could cause the application to crash.

IBM watsonx.data intelligence 5.2.2, 5.3.0, 5.3.1, 5.3.1 through Patch 1 transmits data in clear text that could allow an attacker to obtain sensitive information using man in the middle techniques.

IBM watsonx.data intelligence 5.2.0, 5.2.1, 5.2.2, 5.3.0 transmits data in clear text that could allow an attacker to obtain sensitive information using man in the middle techniques.

IBM watsonx.data intelligence 5.2.0, 5.2.1, 5.2.2, 5.3.0 could allow an authenticated user to cause a temporary denial using a specially crafted HTTP request due to improper allocation of resource throttling.

IBM watsonx.data intelligence 5.2.0, 5.2.1, 5.2.2, 5.3.0 is vulnerable to stored cross-site scripting. This vulnerability allows an authenticated user to embed arbitrary JavaScript code in the Web UI thus altering the intended functionality potentially leading to credentials disclosure within a trusted session.

IBM watsonx.data intelligence 5.2.0, 5.2.1, 5.2.2, 5.3.0 is vulnerable to HTML injection. A remote attacker could inject malicious HTML code, which when viewed, would be executed in the victim's Web browser within the security context of the hosting site.

IBM watsonx.data intelligence 5.2.0, 5.2.1, 5.2.2, 5.3.0 is vulnerable to cross-site scripting. This vulnerability allows an authenticated user to embed arbitrary JavaScript code in the Web UI thus altering the intended functionality potentially leading to credentials disclosure within a trusted session.

IBM watsonx.data intelligence 5.2.0, 5.2.1, 5.2.2, 5.3.0 s vulnerable to server-side request forgery (SSRF). This may allow an authenticated attacker to send unauthorized requests from the system, potentially leading to network enumeration or facilitating other attacks.

IBM watsonx.data intelligence 5.2.0, 5.2.1, 5.2.2, 5.3.0 could allow an authenticated user to bypass security controls and perform unauthorized actions due to client-side enforcement of sever-side security.

IBM watsonx.data intelligence 5.2.0, 5.2.1, 5.2.2, 5.3.0 could allow a remote attacker to obtain sensitive information when a detailed technical error message is returned in the browser.  This information could be used in further attacks against the system.

IBM watsonx.data intelligence 5.2.0, 5.2.1, 5.2.2, 5.3.0 could allow an authenticated user to perform unauthorized actions due to the improper enforcement of behavioral workflow.

A URL validation bypass vulnerability exists in validator.js through version 13.15.15. The isURL() function uses '://' as a delimiter to parse protocols, while browsers use ':' as the delimiter. This parsing difference allows attackers to bypass protocol and domain validation by crafting URLs leading to XSS and Open Redirect attacks.

Improper Input Validation vulnerability in Apache Tomcat due to an incomplete fix of CVE-2025-66614.

This issue affects Apache Tomcat: from 11.0.15 through 11.0.19, from 10.1.50 through 10.1.52, from 9.0.113 through 9.0.115.

Users are recommended to upgrade to version 11.0.20, 10.1.53 or 9.0.116, which fix the issue.

A vulnerability was found in PyTorch 2.6.0+cu124. It has been rated as problematic. Affected by this issue is the function torch.cuda.nccl.reduce of the file torch/cuda/nccl.py. The manipulation leads to denial of service. It is possible to launch the attack on the local host. The exploit has been disclosed to the public and may be used. The patch is identified as 5827d2061dcb4acd05ac5f8e65d8693a481ba0f5. It is recommended to apply a patch to fix this issue.

Uncontrolled Resource Consumption vulnerability in Apache Commons Configuration 1.x.

There are a number of issues in Apache Commons Configuration 1.x that allow excessive resource consumption when loading untrusted configurations or using unexpected usage patterns. The Apache Commons Configuration team does not intend to fix these issues in 1.x. Apache Commons Configuration 1.x is still safe to use in scenario's where you only load trusted configurations.

Users that load untrusted configurations or give attackers control over usage patterns are recommended to upgrade to the 2.x version line, which fixes these issues. Apache Commons Configuration 2.x is not a drop-in replacement, but as it uses a separate Maven groupId and Java package namespace they can be loaded side-by-side, making it possible to do a gradual migration.

Overview

A flaw in Jackson-core's JsonLocation.appendSourceDesc method allows up to 500 bytes of unintended memory content to be included in exception messages. When parsing JSON from a byte array with an offset and length, the exception message incorrectly reads from the beginning of the array instead of the logical payload start. This results in possible information disclosure in systems using pooled or reused buffers, like Netty or Vert.x.

Details

The vulnerability affects the creation of exception messages like:

JsonParseException: Unexpected character ... at [Source: (byte[])...]

When JsonFactory.createParser(byte[] data, int offset, int len) is used, and an error occurs while parsing, the exception message should include a snippet from the specified logical payload. However, the method appendSourceDesc ignores the offset, and always starts reading from index 0.

If the buffer contains residual sensitive data from a previous request, such as credentials or document contents, that data may be exposed if the exception is propagated to the client.

The issue particularly impacts server applications using:

Pooled byte buffers (e.g., Netty) Frameworks that surface parse errors in HTTP responses Default Jackson settings (i.e., INCLUDESOURCEINLOCATION is enabled)

A documented real-world example is CVE-2021-22145 in Elasticsearch, which stemmed from the same root cause.

Attack Scenario

An attacker sends malformed JSON to a service using Jackson and pooled byte buffers (e.g., Netty-based HTTP servers). If the server reuses a buffer and includes the parser’s exception in its HTTP 400 response, the attacker may receive residual data from previous requests.

Proof of Concept

java byte[] buffer = new byte[1000]; System.arraycopy("SECRET".getBytes(), 0, buffer, 0, 6); System.arraycopy("{ \"bad\": }".getBytes(), 0, buffer, 700, 10);

JsonFactory factory = new JsonFactory(); JsonParser parser = factory.createParser(buffer, 700, 20); parser.nextToken(); // throws exception

// Exception message will include "SECRET"

Patches This issue was silently fixed in jackson-core version 2.13.0, released on September 30, 2021, via PR #652.

All users should upgrade to version 2.13.0 or later.

Workarounds If upgrading is not immediately possible, applications can mitigate the issue by:

1. Disabling exception message exposure to clients — avoid returning parsing exception messages in HTTP responses. 2. Disabling source inclusion in exceptions by setting:

java jsonFactory.disable(JsonFactory.Feature.INCLUDESOURCEINLOCATION);

This prevents Jackson from embedding any source content in exception messages, avoiding leakage.

References Pull Request #652 (Fix implementation) CVE-2021-22145 (Elasticsearch exposure of this flaw)

urllib3 supports being used in a Pyodide runtime utilizing the JavaScript Fetch API or falling back on XMLHttpRequest. This means you can use Python libraries to make HTTP requests from your browser or Node.js. Additionally, urllib3 provides a mechanism to control redirects.

However, the retries and redirect parameters are ignored with Pyodide; the runtime itself determines redirect behavior.

Affected usages

Any code which relies on urllib3 to control the number of redirects for an HTTP request in a Pyodide runtime.

Impact

Redirects are often used to exploit SSRF vulnerabilities. An application attempting to mitigate SSRF or open redirect vulnerabilities by disabling redirects may remain vulnerable if a Pyodide runtime redirect mechanism is unsuitable.

Remediation

If you use urllib3 in Node.js, upgrade to a patched version of urllib3.

Unfortunately, browsers provide no suitable way which urllib3 can use: XMLHttpRequest provides no control over redirects, the Fetch API returns opaqueredirect responses lacking data when redirects are controlled manually. Expect default browser behavior for redirects.

A Regular Expression Denial of Service (ReDoS) vulnerability was discovered in the Hugging Face Transformers library, specifically in the getconfigurationfile() function within the transformers.configurationutils module. The affected version is 4.49.0, and the issue is resolved in version 4.51.0. The vulnerability arises from the use of a regular expression pattern config\.(.)\.json that can be exploited to cause excessive CPU consumption through crafted input strings, leading to catastrophic backtracking. This can result in model serving disruption, resource exhaustion, and increased latency in applications using the library.

A Regular Expression Denial of Service (ReDoS) vulnerability was discovered in the Hugging Face Transformers library, specifically in the getimports() function within dynamicmoduleutils.py. This vulnerability affects versions 4.49.0 and is fixed in version 4.51.0. The issue arises from a regular expression pattern \stry\s:.?except.?: used to filter out try/except blocks from Python code, which can be exploited to cause excessive CPU consumption through crafted input strings due to catastrophic backtracking. This vulnerability can lead to remote code loading disruption, resource exhaustion in model serving, supply chain attack vectors, and development pipeline disruption.

A Regular Expression Denial of Service (ReDoS) vulnerability was discovered in the Hugging Face Transformers library, specifically within the DonutProcessor class's token2json() method. This vulnerability affects versions 4.50.3 and earlier, and is fixed in version 4.52.1. The issue arises from the regex pattern <s(.?)> which can be exploited to cause excessive CPU consumption through crafted input strings due to catastrophic backtracking. This vulnerability can lead to service disruption, resource exhaustion, and potential API service vulnerabilities, impacting document processing tasks using the Donut model.

A Regular Expression Denial of Service (ReDoS) vulnerability exists in the Hugging Face Transformers library, specifically in the converttfweightnametoptweightname() function. This function, responsible for converting TensorFlow weight names to PyTorch format, uses a regex pattern /[^/]([^/])/ that can be exploited to cause excessive CPU consumption through crafted input strings due to catastrophic backtracking. The vulnerability affects versions up to 4.51.3 and is fixed in version 4.53.0. This issue can lead to service disruption, resource exhaustion, and potential API service vulnerabilities, impacting model conversion processes between TensorFlow and PyTorch formats.