Pjfanning

An issue exists when binding a JSON string to a `javax.xml.datatype.Duration` or `javax.xml.datatype.XMLGregorianCalendar` field via the `CoreXMLDeserializers.Std. deserialize` function. The software passes the raw string directly to `DatatypeFactory.newDuration(value)` or `newXMLGregorianCalendar(value)`. Because the XML Schema lexical grammar allows numeric components of arbitrary length, the JDK uses `BigInteger(String)` and `BigDecimal(String)` constructors, which have quadratic complexity relative to the digit count. Since the input is treated as a JSON string rather than a JSON number, the `StreamReadConstraints.maxNumberLength` guard is bypassed, and the XML datatype deserializer fails to perform length validation. An unauthenticated attacker can send a request containing a string with several million digits, causing excessive CPU consumption and potentially saturating server worker threads.

The deserializer for java.nio.file.Path resolves an attacker-supplied URI without restricting the URI scheme. In the `JDKFromStringDeserializer.NioPathHelper.deserialize` function, a string from untrusted JSON is passed to `new URI(value)` and then to `Path.of(uri)`. If a `FileSystemNotFoundException` occurs, the code enumerates `ServiceLoader<FileSystemProvider>` and calls `provider.getPath(uri)` on the first provider matching the attacker-chosen scheme. This allows untrusted JSON to select and drive an arbitrary registered `FileSystemProvider` during `readValue` under a default `JsonMapper`, forcing provider class loading. While the resolved path is inert with only JDK built-in providers (file, jar/zipfs), further impact is possible if a side-effecting third-party `FileSystemProvider` is present on the classpath.

The non-blocking (asynchronous) JSON parser in jackson-core fails to enforce the `maxNumberLength` constraint defined in `StreamReadConstraints`. This occurs because the async parsing path in `NonBlockingUtf8JsonParserBase` and related classes does not invoke number length validation methods. Specifically, methods like ` finishNumberIntegralPart()` accumulate digits into the `TextBuffer` without checks, and ` valueComplete()` fails to call `resetInt()` or `resetFloat()`, where `validateIntegerLength()` and `validateFPLength()` are executed. An attacker can submit a JSON document containing a number token of arbitrary length, leading to excessive memory allocation in the `TextBuffer` and potential `OutOfMemoryError`. Additionally, if the application calls `getBigIntegerValue()` or `getDecimalValue()`, the JVM may experience CPU exhaustion due to O(n^2) BigInteger parsing, resulting in a denial of service.

Name of the Vulnerable Software and Affected Versions: jackson-core versions prior to 2.15.0 Description: The issue arises when parsing input files with deeply nested data, potentially causing a StackoverflowError due to excessive depth. A configurable limit for traversal depth has been introduced, defaulting to 1000, to prevent this error. If the limit is reached, a StreamConstraintsException is thrown. Users should avoid parsing input files from untrusted sources as a workaround. Recommendations: For versions prior to 2.15.0, update to version 2.15.0 or later to include the configurable depth limit and prevent StackoverflowError. As a temporary workaround, consider avoiding the parsing of deeply nested input files from untrusted sources until the update is applied.

The web-based admin console in H2 Database Engine can be started via the CLI with the argument `-webAdminPassword`, which allows the user to specify the password in cleartext for the web admin console. Consequently, a local user (or an attacker that has obtained local access through some means) would be able to discover the password by listing processes and their arguments. The issue was fixed in version 2.2.220.

The issue concerns the XML parser used in the Excel-Streaming-Reader, which did not apply all necessary settings to prevent XML Entity Expansion issues. This problem is resolved by upgrading to version 2.1.0. There is no known workaround for this issue.