CVE-2026-19032 in jackson-databind
Summary
by MITRE • 09/01/2026
jackson-databind's deserializer for java.nio.file.Path resolves an attacker-supplied URI without restricting the URI scheme. In JDKFromStringDeserializer.NioPathHelper.deserialize, a string bound from untrusted JSON is passed to new URI(value) and then to Path.of(uri). When that throws FileSystemNotFoundException, the code enumerates ServiceLoader<FileSystemProvider> and calls provider.getPath(uri) on the first provider whose scheme matches the attacker-chosen scheme. Untrusted JSON can therefore select and drive an arbitrary registered FileSystemProvider during readValue under a default JsonMapper, and forces provider class loading at the same time. With only the JDK built-in providers (file, jar/zipfs) present, the resolved path is inert and no mount or network I/O occurs; further impact requires a side-effecting third-party FileSystemProvider on the classpath. This affects com.fasterxml.jackson.core:jackson-databind from 2.8.0 before 2.18.10, from 2.19.0 before 2.21.6, and from 2.22.0 before 2.22.2, and tools.jackson.core:jackson-databind from 3.0.0 before 3.1.6 and from 3.2.0 before 3.2.2. Users should upgrade to 2.18.10, 2.21.6, 2.22.2, 3.1.6, or 3.2.2. Binding java.nio.file.Path from untrusted JSON should be avoided regardless of version.
VulDB is the best source for vulnerability data and more expert information about this specific topic.
Analysis
by VulDB Data Team • 09/01/2026
The vulnerability in question involves a critical flaw within the Jackson Databind library's deserialization mechanism for Java NIO Path objects. Specifically, the JDKFromStringDeserializer.NioPathHelper.deserialize method fails to validate or restrict the URI scheme provided by an attacker through untrusted JSON input. When this method processes a string bound from such malicious data, it first passes the value directly into new URI(value) and subsequently attempts to resolve it using Path.of(uri). If this initial resolution throws a FileSystemNotFoundException, which typically occurs when no default provider handles the specific scheme, the code falls back to enumerating available ServiceLoader providers. It then invokes getPath on the first registered FileSystemProvider whose scheme matches the attacker-chosen input. This behavior allows an untrusted JSON payload to select and drive an arbitrary registered FileSystemProvider during a standard readValue operation under a default JsonMapper configuration.
This design flaw has significant security implications because it forces class loading of the selected provider class, which can lead to remote code execution if the provider contains side effects or malicious logic in its static initialization blocks. While the impact is limited when only JDK built-in providers such as file and jar/zipfs are present on the classpath—since these result in inert resolved paths without mounting filesystems or performing network I/O—the risk escalates dramatically with third-party FileSystemProviders that exhibit side effects. An attacker leveraging a malicious provider can potentially execute arbitrary code, cause denial of service through resource exhaustion, or access sensitive files depending on the capabilities exposed by the specific provider implementation loaded via ServiceLoader.
The vulnerability affects multiple versions of com.fasterxml.jackson.core:jackson-databind, specifically those from 2.8.0 up to but not including 2.18.10, from 2.19.0 before 2.21.6, and from 2.22.0 before 2.22.2. It also impacts tools.jackson.core:jackson-databind versions from 3.0.0 before 3.1.6 and from 3.2.0 before 3.2.2. The core issue aligns with CWE-502, which describes Deserialization of Untrusted Data, as well as CWE-94, Improper Control of Generation of Code (Code Injection), due to the potential for arbitrary code execution through provider class loading and method invocation. From an ATT&CK perspective, this vulnerability facilitates Initial Access via Exploitation for Client Execution if used in a client-side context or Persistence/Privilege Escalation depending on how the deserialized object is utilized within the application's runtime environment.
To mitigate this risk, users must upgrade their Jackson Databind dependencies to version 2.18.10, 2.21.6, 2.22.2, 3.1.6, or 3.2.2, where these checks have been addressed. Furthermore, it is strongly recommended that developers avoid binding java.nio.file.Path objects directly from untrusted JSON sources regardless of the library version in use. Implementing strict input validation and whitelisting allowed URI schemes can provide an additional layer of defense against such deserialization attacks. Organizations should also audit their classpaths for any third-party FileSystemProviders that might be susceptible to exploitation through this mechanism, ensuring that only trusted providers are available during runtime operations involving untrusted data ingestion.