CVE-2026-19032: Insecure Deserialization and Class Loading via java.nio.file.Path Resolution in FasterXML jackson-databind

The FasterXML jackson-databind library is widely utilized across the Java ecosystem to serialize and deserialize Java objects to and from JSON format. Within the library, the deserialization routine for java.nio.file.Path objects converts string inputs directly into java.net.URI instances. Prior to the patch, the parser accepted arbitrary URI scheme values without sanitization, exposing a significant attack surface in applications parsing untrusted payload structures.

This vulnerability is categorized under CWE-470 (Use of Externally-Controlled Input to Select Classes or Code) and CWE-610 (Externally Controlled Reference to a Resource in Another Sphere). The core issue resides in the mechanism used to resolve non-standard URI schemes, which triggers automatic discovery of filesystem providers configured on the target's classpath.

While standard local file schemes (file://) resolve safely on default JVM installations, the presence of specialized library dependencies on the runtime classpath—such as S3, Google Cloud Storage, FTP, or custom virtual filesystem providers—allows attackers to manipulate remote requests, initialize unauthorized network connections, or run static initializers of target classes.

To understand the root cause, we must trace how jackson-databind handles the transition of a JSON string literal into a java.nio.file.Path object. When a class containing a Path property is deserialized, the framework invokes its path deserialization logic. The input string is parsed as a java.net.URI object, which is then fed into Paths.get(uri) or Path.of(uri) to get a reference to the resource.

If the URI specifies a scheme that is not natively registered within the default filesystem context (for example, s3:// or custom://), the standard lookup fails and throws a java.nio.file.FileSystemNotFoundException. Rather than propagating this exception to abort deserialization immediately, the vulnerable implementation catches it and attempts an open-ended fallback search via the Java Service Provider Interface (SPI).

The vulnerable code runs ServiceLoader.load(FileSystemProvider.class) using the thread context class loader. It then loops through all discovered implementations, checking if provider.getScheme().equalsIgnoreCase(scheme) evaluates to true. This lookup triggers the JVM to load the class definition and execute any static initialization blocks associated with providers residing on the application's classpath. If a match is found, the application immediately invokes the custom provider's getPath(uri) method using the attacker's completely controlled URI value.

The vulnerability was addressed in commit cc6756b61ed90b6b9227f670e0408d5d9bd48551 by introducing strict validation inside NioPathDeserializer before any filesystem resolution or class-loading logic can take place.

Prior to the patch, the deserializer blindly processed the input string and initiated the SPI search on failure. The updated version implements a strict URI scheme allowlist that defaults only to the 'file' scheme. Local paths (which do not specify a scheme, causing uri.getScheme() to return null) bypass the validation check, maintaining backward compatibility.

// Patched logic in NioPathDeserializer
public final static Collection<String> DEFAULT_ALLOWED_SCHEMES = Collections.singletonList("file");
protected final Collection<String> _allowedSchemes;
 
public NioPathDeserializer() {
    this(DEFAULT_ALLOWED_SCHEMES);
}
 
// During deserialization of the Path value:
final String scheme = uri.getScheme();
if (scheme != null && !_isSchemeAllowed(scheme)) {
    return (Path) ctxt.handleWeirdStringValue(Path.class, value,
            "scheme '%s' not allowed for Path deserialization (allowed: %s)",
            scheme, _allowedSchemesDesc());
}

The check is performed case-insensitively, preventing bypasses using alternative casing (such as FiLe://). By enforcing this verification up front, jackson-databind avoids calling Paths.get(uri) or triggering ServiceLoader.load(FileSystemProvider.class) for untrusted, arbitrary protocols. This fix is highly robust because it adopts an allowlist model rather than attempting to blocklist dangerous schemes.

An attacker can exploit this vulnerability under specific environmental conditions. The primary prerequisite is that the target application must expose a deserialization endpoint that accepts a JSON object with a field mapped to java.nio.file.Path. Additionally, the application classpath must contain a third-party FileSystemProvider library supporting remote or virtual resources.

For example, if the application classpath includes a library containing a Google Cloud Storage (gs://) or Amazon S3 (s3://) file system provider, the attacker can submit a structured payload targeting those schemes. An example payload looks like this:

{
  "jobName": "Backup Task",
  "sourcePath": "s3://attacker-controlled-bucket.s3.amazonaws.com/payload"
}

When the application processes this payload, the vulnerable deserializer fails the local lookup, queries the SPI registry, loads the matching S3 provider class, and invokes s3Provider.getPath(uri). Depending on the exact provider implementation, this can trigger a Server-Side Request Forgery (SSRF) attempt as the provider contacts the remote endpoint, or execute specialized initialization code that impacts application availability.

The security impact of CVE-2026-19032 is evaluated at CVSS 5.3 (Medium Severity). While the vulnerability allows unauthenticated remote input to drive backend code execution, it does not directly lead to arbitrary code execution (RCE) in a standard, vanilla JVM environment without side-effecting classes on the classpath.

The real-world consequence depends heavily on the libraries deployed alongside jackson-databind. In complex enterprise environments, the forced loading of classes via the ServiceLoader and the invocation of getPath can be chained with other classpath-based vulnerabilities to achieve broader impact, probe network configurations, or perform unauthorized resource requests inside secure network boundaries.

To date, there are no known public exploits or evidence of active exploitation in the wild. The EPSS score remains low at approximately 0.529%, reflecting a limited immediate threat landscape, though legacy and complex container deployments are at elevated risk due to dense classpaths.

The most effective remediation is upgrading to the patched versions of jackson-databind. For the 2.x branch, users should transition to 2.18.10, 2.21.6, or 2.22.2. For the 3.x branch, users must upgrade to 3.1.6 or 3.2.2.

If upgrading is not immediately possible, applications should avoid deserializing untrusted inputs directly into java.nio.file.Path properties. Developers can bind the property as a standard String and manually perform strict schema validation before programmatically constructing the Path instance.

If non-file schemes (like s3 or gs) are legitimately required by the application, developers should securely register a custom instance of NioPathDeserializer on their ObjectMapper. This allows explicit, controlled authorization of chosen protocols while keeping the core protection intact:

SimpleModule module = new SimpleModule();
module.addDeserializer(Path.class, new NioPathDeserializer(Arrays.asList("file", "s3", "gs")));
objectMapper.registerModule(module);