https://db.gcve.eu Contains only the most 10 recent entries. http://www.rssboard.org/rss-specification python-feedgen en Wed, 30 Sep 2026 03:52:18 +0000 https://db.gcve.eu/vuln/certfr-2026-avi-1165 certfr-2026-avi-1165 https://db.gcve.eu/vuln/certfr-2026-avi-1165 https://db.gcve.eu/vuln/cleanstart-2026-ah35927 <p><strong>Withdrawn by the publisher.</strong></p> <p><strong>Affected:</strong> CleanStart: wso2is</p> <p>Multiple security vulnerabilities affect the wso2is package. DefaultBaseTypeLimitingValidator is the PolymorphicTypeValidator applied automatically whenever @JsonTypeInfo is used without an explicitly configured custom validator. See references for individual vulnerability details.</p> <p><strong>Withdrawn by the publisher.</strong></p> <p><strong>Affected:</strong> CleanStart: wso2is</p> <p>Multiple security vulnerabilities affect the wso2is package. DefaultBaseTypeLimitingValidator is the PolymorphicTypeValidator applied automatically whenever @JsonTypeInfo is used without an explicitly configured custom validator. See references for individual vulnerability details.</p> https://db.gcve.eu/vuln/cleanstart-2026-ah35927 https://db.gcve.eu/vuln/fkie_cve-2026-18401 <p>The non-blocking (asynchronous) JSON parser in jackson-core does not enforce the maxNumberLength constraint defined in StreamReadConstraints (default: 1000 characters). An attacker able to submit JSON to an application that uses the async parser API can supply a number token of arbitrary length, leading to excessive memory allocation and potential CPU exhaustion, resulting in a denial of service.</p> <p>The synchronous parser enforces this limit correctly, so the constraint is applied inconsistently depending on which parsing API the application uses.</p> <p>Root cause: the async parsing path in NonBlockingUtf8JsonParserBase and related classes never invokes the number length validation methods. Number parsing methods such as _finishNumberIntegralPart() accumulate digits into the TextBuffer without any length check, then call _valueComplete() to finalize the token. _valueComplete() does not call resetInt() or resetFloat(), which are the methods in ParserBase where validateIntegerLength() and validateFPLength() are performed. Because that validation step is skipped, maxNumberLength is never enforced on the async code path.</p> <p>Impact: an attacker sending a JSON document containing an arbitrarily long number to an application using the async parser (for example a Spring WebFlux or other reactive application) can cause unbounded allocation in the TextBuffer and an OutOfMemoryError. If the application subsequently calls getBigIntegerValue() or getDecimalValue(), the JVM may additionally…</p> <p>The non-blocking (asynchronous) JSON parser in jackson-core does not enforce the maxNumberLength constraint defined in StreamReadConstraints (default: 1000 characters). An attacker able to submit JSON to an application that uses the async parser API can supply a number token of arbitrary length, leading to excessive memory allocation and potential CPU exhaustion, resulting in a denial of service.</p> <p>The synchronous parser enforces this limit correctly, so the constraint is applied inconsistently depending on which parsing API the application uses.</p> <p>Root cause: the async parsing path in NonBlockingUtf8JsonParserBase and related classes never invokes the number length validation methods. Number parsing methods such as _finishNumberIntegralPart() accumulate digits into the TextBuffer without any length check, then call _valueComplete() to finalize the token. _valueComplete() does not call resetInt() or resetFloat(), which are the methods in ParserBase where validateIntegerLength() and validateFPLength() are performed. Because that validation step is skipped, maxNumberLength is never enforced on the async code path.</p> <p>Impact: an attacker sending a JSON document containing an arbitrarily long number to an application using the async parser (for example a Spring WebFlux or other reactive application) can cause unbounded allocation in the TextBuffer and an OutOfMemoryError. If the application subsequently calls getBigIntegerValue() or getDecimalValue(), the JVM may additionally…</p> https://db.gcve.eu/vuln/fkie_cve-2026-18401 https://db.gcve.eu/vuln/ghsa-6qm2-mcq7-53qp <p><strong>Withdrawn by the publisher.</strong></p> <p><strong>Affected:</strong> Maven: tools.jackson.core:jackson-core</p> <p>## Duplicate Advisory</p> <p>This advisory has been withdrawn because it is a duplicate of GHSA-72hv-8253-57qq. This link is maintained to preserve external references.</p> <p>## Original Description</p> <p>The non-blocking (asynchronous) JSON parser in jackson-core does not enforce the maxNumberLength constraint defined in StreamReadConstraints (default: 1000 characters). An attacker able to submit JSON to an application that uses the async parser API can supply a number token of arbitrary length, leading to excessive memory allocation and potential CPU exhaustion, resulting in a denial of service.</p> <p>The synchronous parser enforces this limit correctly, so the constraint is applied inconsistently depending on which parsing API the application uses.</p> <p>Root cause: the async parsing path in NonBlockingUtf8JsonParserBase and related classes never invokes the number length validation methods. Number parsing methods such as _finishNumberIntegralPart() accumulate digits into the TextBuffer without any length check, then call _valueComplete() to finalize the token. _valueComplete() does not call resetInt() or resetFloat(), which are the methods in ParserBase where validateIntegerLength() and validateFPLength() are performed. Because that validation step is skipped, maxNumberLength is never enforced on the async code path.</p> <p>Impact: an attacker sending a JSON document containing an arbitrarily long number to an application using the async parser (for example a Spring WebFlux or other reactive appl…</p> <p><strong>Withdrawn by the publisher.</strong></p> <p><strong>Affected:</strong> Maven: tools.jackson.core:jackson-core</p> <p>## Duplicate Advisory</p> <p>This advisory has been withdrawn because it is a duplicate of GHSA-72hv-8253-57qq. This link is maintained to preserve external references.</p> <p>## Original Description</p> <p>The non-blocking (asynchronous) JSON parser in jackson-core does not enforce the maxNumberLength constraint defined in StreamReadConstraints (default: 1000 characters). An attacker able to submit JSON to an application that uses the async parser API can supply a number token of arbitrary length, leading to excessive memory allocation and potential CPU exhaustion, resulting in a denial of service.</p> <p>The synchronous parser enforces this limit correctly, so the constraint is applied inconsistently depending on which parsing API the application uses.</p> <p>Root cause: the async parsing path in NonBlockingUtf8JsonParserBase and related classes never invokes the number length validation methods. Number parsing methods such as _finishNumberIntegralPart() accumulate digits into the TextBuffer without any length check, then call _valueComplete() to finalize the token. _valueComplete() does not call resetInt() or resetFloat(), which are the methods in ParserBase where validateIntegerLength() and validateFPLength() are performed. Because that validation step is skipped, maxNumberLength is never enforced on the async code path.</p> <p>Impact: an attacker sending a JSON document containing an arbitrarily long number to an application using the async parser (for example a Spring WebFlux or other reactive appl…</p> https://db.gcve.eu/vuln/ghsa-6qm2-mcq7-53qp https://db.gcve.eu/vuln/opensuse-su-2026:11638-1 <p>jackson-core-2.18.9-2.1 on GA media</p> <p>jackson-core-2.18.9-2.1 on GA media</p> https://db.gcve.eu/vuln/opensuse-su-2026:11638-1 https://db.gcve.eu/vuln/ubuntu-cve-2026-18401 <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.04:LTS: jackson-core</p> <p>The non-blocking (asynchronous) JSON parser in jackson-core does not enforce the maxNumberLength constraint defined in StreamReadConstraints (default: 1000 characters). An attacker able to submit JSON to an application that uses the async parser API can supply a number token of arbitrary length, leading to excessive memory allocation and potential CPU exhaustion, resulting in a denial of service. The synchronous parser enforces this limit correctly, so the constraint is applied inconsistently depending on which parsing API the application uses. Root cause: the async parsing path in NonBlockingUtf8JsonParserBase and related classes never invokes the number length validation methods. Number parsing methods such as _finishNumberIntegralPart() accumulate digits into the TextBuffer without any length check, then call _valueComplete() to finalize the token. _valueComplete() does not call resetInt() or resetFloat(), which are the methods in ParserBase where validateIntegerLength() and validateFPLength() are performed. Because that validation step is skipped, maxNumberLength is never enforced on the async code path. Impact: an attacker sending a JSON document containing an arbitrarily long number to an application using the async parser (for example a Spring WebFlux or other reactive application) can cause unbounded allocation in the TextBuffer and an OutOfMemoryError. If the application subsequently calls getBigIntegerValue() or getDecimalValue(), the JVM may additionally be tied u…</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.04:LTS: jackson-core</p> <p>The non-blocking (asynchronous) JSON parser in jackson-core does not enforce the maxNumberLength constraint defined in StreamReadConstraints (default: 1000 characters). An attacker able to submit JSON to an application that uses the async parser API can supply a number token of arbitrary length, leading to excessive memory allocation and potential CPU exhaustion, resulting in a denial of service. The synchronous parser enforces this limit correctly, so the constraint is applied inconsistently depending on which parsing API the application uses. Root cause: the async parsing path in NonBlockingUtf8JsonParserBase and related classes never invokes the number length validation methods. Number parsing methods such as _finishNumberIntegralPart() accumulate digits into the TextBuffer without any length check, then call _valueComplete() to finalize the token. _valueComplete() does not call resetInt() or resetFloat(), which are the methods in ParserBase where validateIntegerLength() and validateFPLength() are performed. Because that validation step is skipped, maxNumberLength is never enforced on the async code path. Impact: an attacker sending a JSON document containing an arbitrarily long number to an application using the async parser (for example a Spring WebFlux or other reactive application) can cause unbounded allocation in the TextBuffer and an OutOfMemoryError. If the application subsequently calls getBigIntegerValue() or getDecimalValue(), the JVM may additionally be tied u…</p> https://db.gcve.eu/vuln/ubuntu-cve-2026-18401 https://db.gcve.eu/vuln/wid-sec-w-2026-0555 <p>Ein entfernter, anonymer Angreifer kann eine Schwachstelle in FasterXML Jackson ausnutzen, um einen Denial of Service Angriff durchzuführen.</p> <p>Ein entfernter, anonymer Angreifer kann eine Schwachstelle in FasterXML Jackson ausnutzen, um einen Denial of Service Angriff durchzuführen.</p> https://db.gcve.eu/vuln/wid-sec-w-2026-0555