https://cve.radiocsirt.org Contains only the most 10 recent entries. http://www.rssboard.org/rss-specification python-feedgen en Mon, 05 Oct 2026 21:06:48 +0000 https://cve.radiocsirt.org/vuln/cve-2025-1396 <p><strong>Affected:</strong> WSO2 Identity Server, WSO2 Open Banking IAM, WSO2 Identity Server as Key Manager</p> <p>A username enumeration vulnerability exists in multiple WSO2 products when Multi-Attribute Login is enabled. In this configuration, the system returns a distinct &#34;User does not exist&#34; error message to the login form, regardless of the validate_username setting. This behavior allows malicious actors to determine which usernames exist in the system based on observable discrepancies in the application&#39;s responses.</p> <p>Exploitation of this vulnerability could aid in brute-force attacks, targeted phishing campaigns, or other social engineering techniques by confirming the validity of user identifiers within the system.</p> <p><strong>Affected:</strong> WSO2 Identity Server, WSO2 Open Banking IAM, WSO2 Identity Server as Key Manager</p> <p>A username enumeration vulnerability exists in multiple WSO2 products when Multi-Attribute Login is enabled. In this configuration, the system returns a distinct &#34;User does not exist&#34; error message to the login form, regardless of the validate_username setting. This behavior allows malicious actors to determine which usernames exist in the system based on observable discrepancies in the application&#39;s responses.</p> <p>Exploitation of this vulnerability could aid in brute-force attacks, targeted phishing campaigns, or other social engineering techniques by confirming the validity of user identifiers within the system.</p> https://cve.radiocsirt.org/vuln/cve-2025-1396 https://cve.radiocsirt.org/vuln/ghsa-r7wm-3cxj-wff9 <p><strong>Affected:</strong> Maven: com.fasterxml.jackson.core:jackson-core, Maven: tools.jackson.core:jackson-core</p> <p>## Summary</p> <p>The fix released in jackson-core `2.18.6` and `2.21.1` for [GHSA-72hv-8253-57qq](https://github.com/FasterXML/jackson-core/security/advisories/GHSA-72hv-8253-57qq) (Number Length Constraint Bypass in Async Parser, published 2026-02-28) is incomplete. The fix commit `b0c428e6` (#1555) wired `validateIntegerLength` into a new `_setIntLength` helper and called it at every place where the integer portion of a number is *decided* (terminator byte arrived, `.` / `e/E` seen, end-of-feed inside a fully-buffered value). It did not call it on the much more attacker-relevant path: &#34;ran out of input while still inside `MINOR_NUMBER_INTEGER_DIGITS`, return `NOT_AVAILABLE` to caller&#34;.</p> <p>As a result, an attacker who streams JSON to a non-blocking parser in many small chunks, without ever sending a terminator byte, can keep the parser inside `MINOR_NUMBER_INTEGER_DIGITS` indefinitely. `_textBuffer.expandCurrentSegment()` grows on every chunk, and `validateIntegerLength` is never invoked. The accumulator is only gated by `maxStringLength` (20 MiB default) — a **~20,000x amplification** of the documented `maxNumberLength` (1000 default).</p> <p>This is the same vulnerability class, same advisory wording (&#34;Memory Exhaustion: Unbounded allocation in TextBuffer from excessively long numbers&#34;), same parser class — just the streaming path the original fix didn&#39;t cover. The fix to the *fraction* path is correct (see `_finishFloatFraction` at line 1834-1837 of `NonBlockingUtf8JsonParserBase.jav…</p> <p><strong>Affected:</strong> Maven: com.fasterxml.jackson.core:jackson-core, Maven: tools.jackson.core:jackson-core</p> <p>## Summary</p> <p>The fix released in jackson-core `2.18.6` and `2.21.1` for [GHSA-72hv-8253-57qq](https://github.com/FasterXML/jackson-core/security/advisories/GHSA-72hv-8253-57qq) (Number Length Constraint Bypass in Async Parser, published 2026-02-28) is incomplete. The fix commit `b0c428e6` (#1555) wired `validateIntegerLength` into a new `_setIntLength` helper and called it at every place where the integer portion of a number is *decided* (terminator byte arrived, `.` / `e/E` seen, end-of-feed inside a fully-buffered value). It did not call it on the much more attacker-relevant path: &#34;ran out of input while still inside `MINOR_NUMBER_INTEGER_DIGITS`, return `NOT_AVAILABLE` to caller&#34;.</p> <p>As a result, an attacker who streams JSON to a non-blocking parser in many small chunks, without ever sending a terminator byte, can keep the parser inside `MINOR_NUMBER_INTEGER_DIGITS` indefinitely. `_textBuffer.expandCurrentSegment()` grows on every chunk, and `validateIntegerLength` is never invoked. The accumulator is only gated by `maxStringLength` (20 MiB default) — a **~20,000x amplification** of the documented `maxNumberLength` (1000 default).</p> <p>This is the same vulnerability class, same advisory wording (&#34;Memory Exhaustion: Unbounded allocation in TextBuffer from excessively long numbers&#34;), same parser class — just the streaming path the original fix didn&#39;t cover. The fix to the *fraction* path is correct (see `_finishFloatFraction` at line 1834-1837 of `NonBlockingUtf8JsonParserBase.jav…</p> https://cve.radiocsirt.org/vuln/ghsa-r7wm-3cxj-wff9