<?xml version='1.0' encoding='UTF-8'?>
<?xml-stylesheet href="/static/style.xsl" type="text/xsl"?>
<rss xmlns:atom="http://www.w3.org/2005/Atom" xmlns:content="http://purl.org/rss/1.0/modules/content/" version="2.0">
  <channel>
    <title>Most recent entries from all</title>
    <link>https://cve.radiocsirt.org</link>
    <description>Contains only the most 10 recent entries.</description>
    <docs>http://www.rssboard.org/rss-specification</docs>
    <generator>python-feedgen</generator>
    <language>en</language>
    <lastBuildDate>Fri, 02 Oct 2026 12:28:01 +0000</lastBuildDate>
    <item>
      <title>CVE-2025-59250 — JDBC Driver for SQL Server Spoofing Vulnerability</title>
      <link>https://cve.radiocsirt.org/vuln/cve-2025-59250</link>
      <description>&lt;p&gt;&lt;strong&gt;Affected:&lt;/strong&gt; Microsoft JDBC Driver for SQL Server 10.2, Microsoft JDBC Driver for SQL Server 11.2, Microsoft JDBC Driver for SQL Server 12.10, Microsoft JDBC Driver for SQL Server 12.2, Microsoft JDBC Driver for SQL Server 12.4, Microsoft JDBC Driver for SQL Server 12.6, Microsoft JDBC Driver for SQL Server 12.8, Microsoft JDBC Driver for SQL Server 13.2&lt;/p&gt;
&lt;p&gt;Improper input validation in JDBC Driver for SQL Server allows an unauthorized attacker to perform spoofing over a network.&lt;/p&gt;</description>
      <content:encoded>&lt;p&gt;&lt;strong&gt;Affected:&lt;/strong&gt; Microsoft JDBC Driver for SQL Server 10.2, Microsoft JDBC Driver for SQL Server 11.2, Microsoft JDBC Driver for SQL Server 12.10, Microsoft JDBC Driver for SQL Server 12.2, Microsoft JDBC Driver for SQL Server 12.4, Microsoft JDBC Driver for SQL Server 12.6, Microsoft JDBC Driver for SQL Server 12.8, Microsoft JDBC Driver for SQL Server 13.2&lt;/p&gt;
&lt;p&gt;Improper input validation in JDBC Driver for SQL Server allows an unauthorized attacker to perform spoofing over a network.&lt;/p&gt;</content:encoded>
      <guid isPermaLink="false">https://cve.radiocsirt.org/vuln/cve-2025-59250</guid>
    </item>
    <item>
      <title>GHSA-72hv-8253-57qq — jackson-core: Number Length Constraint Bypass in Async Parser Leads to Potential DoS Condition</title>
      <link>https://cve.radiocsirt.org/vuln/ghsa-72hv-8253-57qq</link>
      <description>&lt;p&gt;&lt;strong&gt;Affected:&lt;/strong&gt; Maven: tools.jackson.core:jackson-core, Maven: com.fasterxml.jackson.core:jackson-core&lt;/p&gt;
&lt;p&gt;### 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).&lt;/p&gt;
&lt;p&gt;The standard synchronous parser correctly enforces this limit, but the async parser fails to do so, creating an inconsistent enforcement policy.&lt;/p&gt;
&lt;p&gt;### 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.&lt;/p&gt;
&lt;p&gt;- 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.&lt;/p&gt;
&lt;p&gt;### 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.&lt;/p&gt;
&lt;p&gt;```java
package tools.jackson.core.unittest.dos;&lt;/p&gt;
&lt;p&gt;import java.nio.charset.StandardCharsets;&lt;/p&gt;
&lt;p&gt;import org…&lt;/p&gt;</description>
      <content:encoded>&lt;p&gt;&lt;strong&gt;Affected:&lt;/strong&gt; Maven: tools.jackson.core:jackson-core, Maven: com.fasterxml.jackson.core:jackson-core&lt;/p&gt;
&lt;p&gt;### 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).&lt;/p&gt;
&lt;p&gt;The standard synchronous parser correctly enforces this limit, but the async parser fails to do so, creating an inconsistent enforcement policy.&lt;/p&gt;
&lt;p&gt;### 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.&lt;/p&gt;
&lt;p&gt;- 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.&lt;/p&gt;
&lt;p&gt;### 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.&lt;/p&gt;
&lt;p&gt;```java
package tools.jackson.core.unittest.dos;&lt;/p&gt;
&lt;p&gt;import java.nio.charset.StandardCharsets;&lt;/p&gt;
&lt;p&gt;import org…&lt;/p&gt;</content:encoded>
      <guid isPermaLink="false">https://cve.radiocsirt.org/vuln/ghsa-72hv-8253-57qq</guid>
    </item>
  </channel>
</rss>
