https://db.gcve.eu Contains only the most 10 recent entries. http://www.rssboard.org/rss-specification python-feedgen en Thu, 29 Oct 2026 18:52:14 +0000 https://db.gcve.eu/vuln/alsa-2026:90909 <p><strong>Affected:</strong> AlmaLinux:8: apache-commons-collections, AlmaLinux:8: apache-commons-lang, AlmaLinux:8: apache-commons-net, AlmaLinux:8: bea-stax-api, AlmaLinux:8: glassfish-fastinfoset, AlmaLinux:8: glassfish-jaxb-api, AlmaLinux:8: glassfish-jaxb-core, AlmaLinux:8: glassfish-jaxb-runtime, AlmaLinux:8: glassfish-jaxb-txw2, AlmaLinux:8: jackson-annotations and 20 more</p> <p>The Public Key Infrastructure (PKI) Core contains fundamental packages required by Red Hat Certificate System.</p> <p>Security Fix(es):</p> <p>* com.fasterxml.jackson.core/jackson-core: Jackson-core: Denial of Service via unbounded StringBuilder growth during malformed token processing (CVE-2026-89425) * com.fasterxml.jackson.core/jackson-databind: tools.jackson.core:jackson-databind: Jackson-databind: Denial of Service via quadratic forward-reference completion (CVE-2026-91777) * com.fasterxml.jackson.core/jackson-core: tools.jackson.core/jackson-core: jackson-core: Denial of Service via excessively long JSON property names (CVE-2026-68498)</p> <p>For more details about the security issue(s), including the impact, a CVSS score, acknowledgments, and other related information, refer to the CVE page(s) listed in the References section.</p> <p><strong>Affected:</strong> AlmaLinux:8: apache-commons-collections, AlmaLinux:8: apache-commons-lang, AlmaLinux:8: apache-commons-net, AlmaLinux:8: bea-stax-api, AlmaLinux:8: glassfish-fastinfoset, AlmaLinux:8: glassfish-jaxb-api, AlmaLinux:8: glassfish-jaxb-core, AlmaLinux:8: glassfish-jaxb-runtime, AlmaLinux:8: glassfish-jaxb-txw2, AlmaLinux:8: jackson-annotations and 20 more</p> <p>The Public Key Infrastructure (PKI) Core contains fundamental packages required by Red Hat Certificate System.</p> <p>Security Fix(es):</p> <p>* com.fasterxml.jackson.core/jackson-core: Jackson-core: Denial of Service via unbounded StringBuilder growth during malformed token processing (CVE-2026-89425) * com.fasterxml.jackson.core/jackson-databind: tools.jackson.core:jackson-databind: Jackson-databind: Denial of Service via quadratic forward-reference completion (CVE-2026-91777) * com.fasterxml.jackson.core/jackson-core: tools.jackson.core/jackson-core: jackson-core: Denial of Service via excessively long JSON property names (CVE-2026-68498)</p> <p>For more details about the security issue(s), including the impact, a CVSS score, acknowledgments, and other related information, refer to the CVE page(s) listed in the References section.</p> https://db.gcve.eu/vuln/alsa-2026:90909 https://db.gcve.eu/vuln/certfr-2026-avi-1385 certfr-2026-avi-1385 https://db.gcve.eu/vuln/certfr-2026-avi-1385 https://db.gcve.eu/vuln/fkie_cve-2026-68498 <p>StreamReadConstraints.maxNameLength (default 50,000 characters) is intended to bound how much memory a single JSON Object property name can consume while being parsed, independently of the much larger maxStringLength (default 100,000,000 characters) that bounds ordinary string values. For parsers built over character input — Reader, String or char[] sources, all served by ReaderBasedJsonParser — that bound is not applied while the name is being accumulated. The code path instead re-uses the string-value length check, which is roughly 2000x larger by default.</p> <p>In the character-input slow path, ReaderBasedJsonParser._parseName2() accumulates the name into the TextBuffer and, when a segment fills, calls TextBuffer.finishCurrentSegment(), which validates only maxStringLength. The correct check, StreamReadConstraints.validateNameLength(int), is reached afterwards in CharsToNameCanonicalizer.findSymbol(), once the entire name has been scanned to its closing quote. By that point the full name — up to maxStringLength characters — has already been buffered in memory.</p> <p>A remote attacker who can have a single sufficiently long JSON Object property name parsed through this path can force allocation on the order of 100,000,000 characters (approximately 200 MB, with segment bookkeeping pushing real peak usage higher) before any StreamConstraintsException is thrown, instead of the approximately 50,000-character (about 100 KB) bound the API promises. Repeating this across concurrent req…</p> <p>StreamReadConstraints.maxNameLength (default 50,000 characters) is intended to bound how much memory a single JSON Object property name can consume while being parsed, independently of the much larger maxStringLength (default 100,000,000 characters) that bounds ordinary string values. For parsers built over character input — Reader, String or char[] sources, all served by ReaderBasedJsonParser — that bound is not applied while the name is being accumulated. The code path instead re-uses the string-value length check, which is roughly 2000x larger by default.</p> <p>In the character-input slow path, ReaderBasedJsonParser._parseName2() accumulates the name into the TextBuffer and, when a segment fills, calls TextBuffer.finishCurrentSegment(), which validates only maxStringLength. The correct check, StreamReadConstraints.validateNameLength(int), is reached afterwards in CharsToNameCanonicalizer.findSymbol(), once the entire name has been scanned to its closing quote. By that point the full name — up to maxStringLength characters — has already been buffered in memory.</p> <p>A remote attacker who can have a single sufficiently long JSON Object property name parsed through this path can force allocation on the order of 100,000,000 characters (approximately 200 MB, with segment bookkeeping pushing real peak usage higher) before any StreamConstraintsException is thrown, instead of the approximately 50,000-character (about 100 KB) bound the API promises. Repeating this across concurrent req…</p> https://db.gcve.eu/vuln/fkie_cve-2026-68498 https://db.gcve.eu/vuln/opensuse-su-2026:11876-1 <p>jackson-core-2.18.11-1.1 on GA media</p> <p>jackson-core-2.18.11-1.1 on GA media</p> https://db.gcve.eu/vuln/opensuse-su-2026:11876-1 https://db.gcve.eu/vuln/rhsa-2026:88149 <p>spring-security: authorization bypass for case sensitive comparisons jetty-security: Eclipse Jetty: Authentication bypass via Digest authentication encoding collision jetty: Eclipse Jetty: Information disclosure due to retained HTTP/1.1 trailers across connections bouncycastle: Bouncy Castle: Denial of Service via untrusted keystore length allocation org.eclipse.jetty.http2/http2-common: org.eclipse.jetty.http2/jetty-http2-common: Jetty: Denial of Service via HTTP/2 race condition org.bouncycastle/bc-java: org.bouncycastle/bc-lts-java: Bouncy Castle for Java: Cryptographic signature bypass in RSA PKCS#1 verification org.bouncycastle/bcprov-jdk15on: org.bouncycastle/bcprov-jdk18on: org.bouncycastle/bc-fips: org.bouncycastle/bctls-fips: Bouncy Castle for Java: Denial of Service due to unbounded memory allocation org.eclipse.jetty/jetty-server: org.eclipse.jetty/jetty-proxy: Eclipse Jetty: Access control bypass via case-sensitive host filtering org.eclipse.jetty/jetty-http: Jetty: HTTP request smuggling via crafted chunked requests Spring Framework: org.springframework/spring-expression: Spring Framework: Denial of Service via unbounded exponentiation in SpEL expressions Spring Framework: Spring Framework: Memory leak via malformed RSocket SETUP frame org.bouncycastle/bc-java: Bouncy Castle for Java: Denial of Service via quadratic-time escaping of X.500 distinguished names org.bouncycastle/bcpkix-jdk15on: org.bouncycastle/bcprov-jdk15on: Bouncy Castle for Java: Certificate val…</p> <p>spring-security: authorization bypass for case sensitive comparisons jetty-security: Eclipse Jetty: Authentication bypass via Digest authentication encoding collision jetty: Eclipse Jetty: Information disclosure due to retained HTTP/1.1 trailers across connections bouncycastle: Bouncy Castle: Denial of Service via untrusted keystore length allocation org.eclipse.jetty.http2/http2-common: org.eclipse.jetty.http2/jetty-http2-common: Jetty: Denial of Service via HTTP/2 race condition org.bouncycastle/bc-java: org.bouncycastle/bc-lts-java: Bouncy Castle for Java: Cryptographic signature bypass in RSA PKCS#1 verification org.bouncycastle/bcprov-jdk15on: org.bouncycastle/bcprov-jdk18on: org.bouncycastle/bc-fips: org.bouncycastle/bctls-fips: Bouncy Castle for Java: Denial of Service due to unbounded memory allocation org.eclipse.jetty/jetty-server: org.eclipse.jetty/jetty-proxy: Eclipse Jetty: Access control bypass via case-sensitive host filtering org.eclipse.jetty/jetty-http: Jetty: HTTP request smuggling via crafted chunked requests Spring Framework: org.springframework/spring-expression: Spring Framework: Denial of Service via unbounded exponentiation in SpEL expressions Spring Framework: Spring Framework: Memory leak via malformed RSocket SETUP frame org.bouncycastle/bc-java: Bouncy Castle for Java: Denial of Service via quadratic-time escaping of X.500 distinguished names org.bouncycastle/bcpkix-jdk15on: org.bouncycastle/bcprov-jdk15on: Bouncy Castle for Java: Certificate val…</p> https://db.gcve.eu/vuln/rhsa-2026:88149 https://db.gcve.eu/vuln/suse-su-2026:24149-1 <p>Security update for jackson-annotations, jackson-core, jackson-databind</p> <p>Security update for jackson-annotations, jackson-core, jackson-databind</p> https://db.gcve.eu/vuln/suse-su-2026:24149-1 https://db.gcve.eu/vuln/ubuntu-cve-2026-68498 <p><strong>Affected:</strong> Ubuntu:16.04:LTS: jackson-core, Ubuntu:18.04:LTS: jackson-core, Ubuntu:20.04:LTS: jackson-core, Ubuntu:22.04:LTS: jackson-core, Ubuntu:24.04:LTS: jackson-core, Ubuntu:26.10: jackson-core, Ubuntu:26.04:LTS: jackson-core</p> <p>StreamReadConstraints.maxNameLength (default 50,000 characters) is intended to bound how much memory a single JSON Object property name can consume while being parsed, independently of the much larger maxStringLength (default 100,000,000 characters) that bounds ordinary string values. For parsers built over character input — Reader, String or char[] sources, all served by ReaderBasedJsonParser — that bound is not applied while the name is being accumulated. The code path instead re-uses the string-value length check, which is roughly 2000x larger by default. In the character-input slow path, ReaderBasedJsonParser._parseName2() accumulates the name into the TextBuffer and, when a segment fills, calls TextBuffer.finishCurrentSegment(), which validates only maxStringLength. The correct check, StreamReadConstraints.validateNameLength(int), is reached afterwards in CharsToNameCanonicalizer.findSymbol(), once the entire name has been scanned to its closing quote. By that point the full name — up to maxStringLength characters — has already been buffered in memory. A remote attacker who can have a single sufficiently long JSON Object property name parsed through this path can force allocation on the order of 100,000,000 characters (approximately 200 MB, with segment bookkeeping pushing real peak usage higher) before any StreamConstraintsException is thrown, instead of the approximately 50,000-character (about 100 KB) bound the API promises. Repeating this across concurrent requests…</p> <p><strong>Affected:</strong> Ubuntu:16.04:LTS: jackson-core, Ubuntu:18.04:LTS: jackson-core, Ubuntu:20.04:LTS: jackson-core, Ubuntu:22.04:LTS: jackson-core, Ubuntu:24.04:LTS: jackson-core, Ubuntu:26.10: jackson-core, Ubuntu:26.04:LTS: jackson-core</p> <p>StreamReadConstraints.maxNameLength (default 50,000 characters) is intended to bound how much memory a single JSON Object property name can consume while being parsed, independently of the much larger maxStringLength (default 100,000,000 characters) that bounds ordinary string values. For parsers built over character input — Reader, String or char[] sources, all served by ReaderBasedJsonParser — that bound is not applied while the name is being accumulated. The code path instead re-uses the string-value length check, which is roughly 2000x larger by default. In the character-input slow path, ReaderBasedJsonParser._parseName2() accumulates the name into the TextBuffer and, when a segment fills, calls TextBuffer.finishCurrentSegment(), which validates only maxStringLength. The correct check, StreamReadConstraints.validateNameLength(int), is reached afterwards in CharsToNameCanonicalizer.findSymbol(), once the entire name has been scanned to its closing quote. By that point the full name — up to maxStringLength characters — has already been buffered in memory. A remote attacker who can have a single sufficiently long JSON Object property name parsed through this path can force allocation on the order of 100,000,000 characters (approximately 200 MB, with segment bookkeeping pushing real peak usage higher) before any StreamConstraintsException is thrown, instead of the approximately 50,000-character (about 100 KB) bound the API promises. Repeating this across concurrent requests…</p> https://db.gcve.eu/vuln/ubuntu-cve-2026-68498