CVE-2025-61726 — Memory exhaustion in query parameter parsing in net/url

Affected: Go standard library net/url, Red Hat Cryostat 4 on RHEL 9, Red Hat HawtIO HawtIO 4.3.1, Red Hat HawtIO HawtIO 4.4.0, Red Hat Ansible Automation Platform 2.4 for RHEL 8, Red Hat Ansible Automation Platform 2.4 for RHEL 9, Red Hat Ansible Automation Platform 2.5 for RHEL 8, Red Hat Ansible Automation Platform 2.5 for RHEL 9, Red Hat Ansible Automation Platform 2.6 for RHEL 10, Red Hat Ansible Automation Platform 2.6 for RHEL 9 and 152 more

The net/url package does not set a limit on the number of query parameters in a query. While the maximum size of query parameters in URLs is generally limited by the maximum request header size, the net/http.Request.ParseForm method can parse large URL-encoded forms. Parsing a large form containing many unique query parameters can cause excessive memory consumption.

GHSA-72hv-8253-57qq — jackson-core: Number Length Constraint Bypass in Async Parser Leads to Potential DoS Condition

Affected: Maven: tools.jackson.core:jackson-core, Maven: com.fasterxml.jackson.core:jackson-core

### Summary The non-blocking (async) JSON parser in `jackson-core` bypasses the `maxNumberLength` constraint (default: 1000 characters) defined in `StreamReadConstraints`. This allows an attacker to send JSON with arbitrarily long numbers through the async parser API, leading to excessive memory allocation and potential CPU exhaustion, resulting in a Denial of Service (DoS).

The standard synchronous parser correctly enforces this limit, but the async parser fails to do so, creating an inconsistent enforcement policy.

### Details The root cause is that the async parsing path in `NonBlockingUtf8JsonParserBase` (and related classes) does not call the methods responsible for number length validation.

- The number parsing methods (e.g., `_finishNumberIntegralPart`) accumulate digits into the `TextBuffer` without any length checks. - After parsing, they call `_valueComplete()`, which finalizes the token but does **not** call `resetInt()` or `resetFloat()`. - The `resetInt()`/`resetFloat()` methods in `ParserBase` are where the `validateIntegerLength()` and `validateFPLength()` checks are performed. - Because this validation step is skipped, the `maxNumberLength` constraint is never enforced in the async code path.

### PoC The following JUnit 5 test demonstrates the vulnerability. It shows that the async parser accepts a 5,000-digit number, whereas the limit should be 1,000.

```java package tools.jackson.core.unittest.dos;

import java.nio.charset.StandardCharsets;

import org…

Most recent entries from all

CVE-2025-61726 — Memory exhaustion in query parameter parsing in net/url

GHSA-72hv-8253-57qq — jackson-core: Number Length Constraint Bypass in Async Parser Leads to Potential DoS Condition