<?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-04T22:30:09.023741+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-48924</id>
    <title>CVE-2025-48924 — Apache Commons Lang, Apache Commons Lang: ClassUtils.getClass(...) can throw a StackOverflowError on very long inputs</title>
    <updated>2026-10-04T22:30:09.285309+00:00</updated>
    <content type="xhtml">
      <div xmlns="http://www.w3.org/1999/xhtml"><p><strong>Affected:</strong> Apache Software Foundation Apache Commons Lang</p>
<p>Uncontrolled Recursion vulnerability in Apache Commons Lang.</p>
<p>This issue affects Apache Commons Lang: Starting with commons-lang:commons-lang 2.0 to 2.6, and, from org.apache.commons:commons-lang3 3.0 before 3.18.0.</p>
<p>The methods ClassUtils.getClass(...) can throw StackOverflowError on very long inputs. Because an Error is usually not handled by applications and libraries, a 
StackOverflowError could cause an application to stop.</p>
<p>Users are recommended to upgrade to version 3.18.0, which fixes the issue.</p></div>
    </content>
    <link href="https://cve.radiocsirt.org/vuln/cve-2025-48924"/>
  </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-04T22:30:09.285385+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>
