CVE-2026-83557: jackson-databind omits java.lang.Comparable from DefaultBaseTypeLimitingValidator's unsafe base types
DefaultBaseTypeLimitingValidator is the PolymorphicTypeValidator applied automatically whenever @JsonTypeInfo is used without an explicitly configured custom validator. It denies polymorphic resolution only for a fixed set of "unsafe base types", and its isSafeSubType method returns true unconditionally for every base type outside that set. java.lang.Comparable was absent from the list despite being implemented by a very large fraction of JDK and application classes, comparable in breadth to java.io.Serializable, which is on the list for that reason. An application declaring an @JsonTypeInfo-annotated property or class with Comparable as its base type, and no custom PolymorphicTypeValidator, will accept a type identifier for essentially any class implementing Comparable. This yields an attacker-controlled object instantiation primitive; a demonstrated case constructs a java.io.File for an arbitrary attacker-chosen path, which becomes path-traversal-adjacent if the application subsequently calls path-sensitive methods on the value. No class implementing Comparable has been identified that yields code execution through deserialization alone. Global Default Typing via activateDefaultTyping is not affected, because that method structurally requires an explicit PolymorphicTypeValidator argument. This affects com.fasterxml.jackson.core:jackson-databind from 2.11.0 before 2.18.10, from 2.19.0 before 2.21.6, and from 2.22.0 before 2.22.2, and tools.jackson.core:jackson-databind from 3.0.0 before 3.1.6 and from 3.2.0 before 3.2.2. Users should upgrade to 2.18.10, 2.21.6, 2.22.2, 3.1.6, or 3.2.2.
Affected Software
Remediation
Recommended actions to resolve this vulnerability, in priority order.
- Upgrade
Upgrade
com.fasterxml.jackson.core:jackson-databindto a version that resolves this vulnerability.Fixed in 2.18.10 - Upgrade
Upgrade
com.fasterxml.jackson.core:jackson-databindto a version that resolves this vulnerability.Fixed in 2.21.6 - Upgrade
Upgrade
com.fasterxml.jackson.core:jackson-databindto a version that resolves this vulnerability.Fixed in 2.22.2 - Upgrade
Upgrade
tools.jackson.core:jackson-databindto a version that resolves this vulnerability.Fixed in 3.1.6 - Upgrade
Upgrade
tools.jackson.core:jackson-databindto a version that resolves this vulnerability.Fixed in 3.2.2 - Configuration
If your application needs polymorphic handling for a property/class annotated with @JsonTypeInfo and using Comparable as the base type, configure a custom PolymorphicTypeValidator (for example BasicPolymorphicTypeValidator with an allow-list of permitted subtypes) instead of relying on DefaultBaseTypeLimitingValidator.
Jackson polymorphic deserialization (DefaultBaseTypeLimitingValidator) PolymorphicTypeValidator = explicit PolymorphicTypeValidator (e.g., BasicPolymorphicTypeValidator with an allow-list of permitted subtypes)
Event History
Frequently Asked Questions
Which applications are exposed to this issue?
Applications are exposed when they declare an @JsonTypeInfo-annotated property or class whose base type is java.lang.Comparable and do not explicitly configure a custom PolymorphicTypeValidator. The automatically applied DefaultBaseTypeLimitingValidator otherwise permits subtype resolution for this base type.
What does an attacker need to exploit it?
An attacker needs to be able to supply a polymorphic type identifier to the affected deserialization path. No authentication or user interaction is indicated by the supplied vector, but exploitation has high attack complexity.
What can an attacker achieve through the demonstrated behavior?
The issue provides an attacker-controlled object-instantiation primitive for classes implementing Comparable. A demonstrated case creates a java.io.File with an attacker-chosen path; risk becomes path-traversal-adjacent if the application later invokes path-sensitive methods on that object.
Does this issue provide code execution through deserialization alone?
No Comparable-implementing class has been identified that produces code execution through deserialization alone. The stated impact is limited to attacker-controlled instantiation and any unsafe application behavior performed later on the resulting object.
How can teams identify potentially affected code?
Review deserialization models for @JsonTypeInfo on properties or classes using Comparable as the base type, and determine whether a custom PolymorphicTypeValidator is explicitly configured. Such uses relying on the automatic validator are the affected condition described here.