Jackson-databind’s java.nio.file.Path deserializer resolves a URI supplied by untrusted JSON without restricting its scheme. When the built-in file provider cannot be found, the library enumerates all ServiceLoader<FileSystemProvider> implementations and invokes the first provider whose scheme matches the attacker‑chosen scheme. This behavior allows an attacker to supply a JSON payload that selects any FileSystemProvider present on the classpath, causing that provider to be loaded and its getPath method executed during deserialization. While the default JDK providers ("file" and "jar", zipfs) merely produce inert paths, the inclusion of a third‑party provider with side‑effects can lead to remote code execution, network access, or privilege escalation. The vulnerability is triggered only when the application deserializes Path objects from data that the attacker controls, and when a malicious provider is available on the runtime classpath.

The affected library is FasterXML’s jackson-databind. Vulnerable releases include com.fasterxml.jackson.core:jackson-databind from 2.8.0 up to but not including 2.18.10, from 2.19.0 up to but not including 2.21.6, and from 2.22.0 up to but not including 2.22.2; and tools.jackson.core:jackson-databind from 3.0.0 up to but not including 3.1.6 and from 3.2.0 up to but not including 3.2.2. All newer releases applying the fixed scheme allow‑list are unaffected.

The CVSS v3 score is 5.3, indicating a moderate risk. The EPSS score is 0.00463, indicating a very low probability of exploitation. The vulnerability is not listed in the CISA KEV catalog. Exploitation requires the attacker to supply crafted JSON containing a URI scheme that matches a FileSystemProvider implementation present on the application’s classpath. Once the provider is loaded during deserialization, any side‑effects performed by that provider execute in the context of the application, potentially leading to arbitrary code execution or unauthorized access. Because only untrusted deserialization of Path objects enables the attack, mitigating the issue is achievable by refusing to deserialize such fields or by applying the vendor’s patch to introduce a strict scheme allow‑list.