<?xml version='1.0' encoding='UTF-8'?>
<?xml-stylesheet href="/static/style.xsl" type="text/xsl"?>
<feed xmlns="http://www.w3.org/2005/Atom" xml:lang="en">
  <id>https://cve.radiocsirt.org/rss/recent/all/10</id>
  <title>Most recent entries from all</title>
  <updated>2026-10-02T10:06:43.345981+00:00</updated>
  <author>
    <name>Vulnerability-Lookup</name>
    <email>csirt@opendfir.org</email>
  </author>
  <link href="https://cve.radiocsirt.org" rel="alternate"/>
  <generator uri="https://lkiesow.github.io/python-feedgen" version="1.0.0">python-feedgen</generator>
  <subtitle>Contains only the most 10 recent entries.</subtitle>
  <entry>
    <id>https://cve.radiocsirt.org/vuln/cve-2025-61726</id>
    <title>CVE-2025-61726 — Memory exhaustion in query parameter parsing in net/url</title>
    <updated>2026-10-02T10:06:43.804216+00:00</updated>
    <content type="xhtml">
      <div xmlns="http://www.w3.org/1999/xhtml"><p><strong>Affected:</strong> 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</p>
<p>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.</p></div>
    </content>
    <link href="https://cve.radiocsirt.org/vuln/cve-2025-61726"/>
  </entry>
  <entry>
    <id>https://cve.radiocsirt.org/vuln/ghsa-2m67-wjpj-xhg9</id>
    <title>GHSA-2m67-wjpj-xhg9 — Jackson Core: Document length constraint bypass in blocking, async, and DataInput parsers</title>
    <updated>2026-10-02T10:06:43.805991+00:00</updated>
    <content type="xhtml">
      <div xmlns="http://www.w3.org/1999/xhtml"><p><strong>Affected:</strong> Maven: tools.jackson.core:jackson-core</p>
<p>## Summary</p>
<p>Jackson Core 3.x does not consistently enforce `StreamReadConstraints.maxDocumentLength`. Oversized JSON documents can be accepted without a `StreamConstraintsException` in multiple parser entry points, which allows configured size limits to be bypassed and weakens denial-of-service protections.</p>
<p>## Details</p>
<p>Three code paths where `maxDocumentLength` is not fully enforced:</p>
<p>### 1. Blocking parsers skip validation of the final in-memory buffer</p>
<p>Blocking parsers validate only previously processed buffers, not the final in-memory buffer:</p>
<p>- `ReaderBasedJsonParser.java:255`
- `UTF8StreamJsonParser.java:208`</p>
<p>Relevant code:</p>
<p>```java
_currInputProcessed += bufSize;
_streamReadConstraints.validateDocumentLength(_currInputProcessed);
```</p>
<p>This means the check occurs only when a completed buffer is rolled over. If an oversized document is fully contained in the final buffer, parsing can complete without any document-length exception.</p>
<p>### 2. Async parsers skip validation of the final chunk on end-of-input</p>
<p>Async parsers validate previously processed chunks, but do not validate the final chunk on end-of-input:</p>
<p>- `NonBlockingByteArrayJsonParser.java:49`
- `NonBlockingByteBufferJsonParser.java:57`
- `NonBlockingUtf8JsonParserBase.java:75`</p>
<p>Relevant code:</p>
<p>```java
_currInputProcessed += _origBufferLen;
_streamReadConstraints.validateDocumentLength(_currInputProcessed);</p>
<p>public void endOfInput() {
    _endOfInput = true;
}
```</p>
<p>`endOfInput()` marks EOF but does not perform a…</p></div>
    </content>
    <link href="https://cve.radiocsirt.org/vuln/ghsa-2m67-wjpj-xhg9"/>
  </entry>
</feed>
