https://cve.radiocsirt.org Contains only the most 10 recent entries. http://www.rssboard.org/rss-specification python-feedgen en Mon, 05 Oct 2026 16:39:25 +0000 https://cve.radiocsirt.org/vuln/cve-2026-13006 <p><strong>Affected:</strong> QOS.CH Sarl Logback-core</p> <p>ACE vulnerability in conditional configuration file processing by QOS.CH logback-core up to and including version 1.5.36 in Java applications, allows an attacker to execute arbitrary code circumventing existing protections against CVE-2025-11226 by compromising an existing logback configuration file or by injecting an environment variable before program execution.</p> <p>A successful attack requires the presence of Janino library to be present on the user&#39;s class path. In addition, the attacker must  have write access to a configuration file. Alternatively, the attacker could inject a malicious environment variable pointing to a malicious configuration file. In both cases, the attack requires existing privilege.</p> <p>Please note that in logack version 1.5.37 conditional processing using Janino was removed.</p> <p><strong>Affected:</strong> QOS.CH Sarl Logback-core</p> <p>ACE vulnerability in conditional configuration file processing by QOS.CH logback-core up to and including version 1.5.36 in Java applications, allows an attacker to execute arbitrary code circumventing existing protections against CVE-2025-11226 by compromising an existing logback configuration file or by injecting an environment variable before program execution.</p> <p>A successful attack requires the presence of Janino library to be present on the user&#39;s class path. In addition, the attacker must  have write access to a configuration file. Alternatively, the attacker could inject a malicious environment variable pointing to a malicious configuration file. In both cases, the attack requires existing privilege.</p> <p>Please note that in logack version 1.5.37 conditional processing using Janino was removed.</p> https://cve.radiocsirt.org/vuln/cve-2026-13006 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