Thursday morning. You open your task tracker and find a ticket from the dependency scanner: “jackson-databind, CVE-2026-83557, critical, patch immediately.” The GitHub advisory link, CVSS score, and the phrase “polymorphic deserialization” lead to an approved hotfix deployment scheduled for Friday at 6 p.m. Stop. The author reversed the process, built a working exploit, and tested it against both vulnerable and patched versions of the library. The result shows why most projects can safely treat this issue as a normal release item rather than an emergency.
Jackson supports polymorphic deserialization by embedding a type identifier in JSON. A typical declaration looks like this:
public class Holder { @JsonTypeInfo(use = JsonTypeInfo.Id.CLASS, include = JsonTypeInfo.As.WRAPPER_ARRAY) public Comparable<?> value; }
The corresponding JSON payload is {"value": ["java.io.File", "/etc/passwd"]}. The first array element supplies the class name and the second supplies constructor arguments.
Because arbitrary class names must not be accepted from untrusted JSON, Jackson provides the PolymorphicTypeValidator interface. The default implementation, DefaultBaseTypeLimitingValidator, maintains a denylist of nine unsafe base types including Object and Serializable. Any base type absent from this list is accepted without further checks. The CVE exists because java.lang.Comparable was omitted from the denylist.
The first real barrier is the configuration flag MapperFeature.BLOCK_UNSAFE_POLYMORPHIC_BASE_TYPES. This flag is disabled by default. When it remains off, Jackson falls back to LaissezFaireSubTypeValidator, which permits everything. Consequently, only projects that deliberately enabled the protective flag can be affected by this specific CVE.
The second barrier is the declared type of the property itself. The validator inspects the declared base type of the field. Only properties explicitly typed as Comparable<?> or raw Comparable combined with @JsonTypeInfo are vulnerable. Typical DTOs containing concrete types, collections, or business objects do not expose such fields.
When both conditions are met, an attacker can supply {"value": ["java.io.File", "/etc/passwd"]} and obtain a live java.io.File instance. The exploit demonstrates controlled instantiation rather than arbitrary code execution. The author notes that no reliable remote-code-execution chain was identified, consistent with the moderate CVSS 5.6 rating.
The patch, released in 2.18.10, 2.21.6, and 2.22.2, adds Comparable to the denylist. However, this change also blocks legitimate subclasses such as a custom SafeThing implements Comparable<SafeThing>, causing InvalidDefinitionException at runtime. Developers who rely on polymorphic Comparable fields must migrate to an explicit BasicPolymorphicTypeValidator allowlist after upgrading.
Two quick checks determine exposure: confirm whether BLOCK_UNSAFE_POLYMORPHIC_BASE_TYPES is enabled and search for any @JsonTypeInfo annotation placed on a Comparable field. Either negative result closes the ticket without emergency action.
