CVE-2026-83557

What it actually does

Jackson databind's DefaultBaseTypeLimitingValidator, used automatically with @JsonTypeInfo when no custom PolymorphicTypeValidator is configured, failed to treat java.lang.Comparable as an unsafe base type. Any @JsonTypeInfo-annotated property or class whose declared base type is Comparable therefore accepted type identifiers for essentially any Comparable-implementing class. That yields an attacker-controlled object-instantiation primitive during JSON deserialization (a demonstrated outcome is construction of a java.io.File for an arbitrary path). It does not, by itself, provide a known gadget that executes code solely through deserialization. Global default typing via activateDefaultTyping is unaffected because that API requires an explicit validator.

Why it matters to the business

Applications that deserialize untrusted JSON into Comparable-typed polymorphic properties can be induced to instantiate unexpected JDK or application types. Follow-on use of those objects (especially path-sensitive File APIs) can cause unauthorized file access, data exposure, integrity issues, or localized denial of service. CVSS is moderate (5.6) with high attack complexity, the issue is not in KEV, and no public exploit maturity is reported, but Jackson databind is extremely widely used, so unpatched services remain a meaningful residual risk until upgraded.

How an attack unfolds

An attacker locates an HTTP or messaging endpoint that deserializes JSON into a type annotated with @JsonTypeInfo whose base type is Comparable and that does not supply a custom PolymorphicTypeValidator. The attacker includes a polymorphic type identifier naming a Comparable-implementing class of their choice (for example a java.io.File bound to a path they select). Jackson instantiates that class while mapping the rest of the payload. If application logic later treats the resulting object as a path, name, or comparable value, the attacker gains path-traversal-adjacent behavior or other unintended object use. Code execution through this flaw alone has not been demonstrated. Success depends on the presence of a Comparable-typed polymorphic binding and on subsequent application use of the instantiated object.

How to fix it

Upgrade com.fasterxml.jackson.core:jackson-databind to 2.18.10, 2.21.6, or 2.22.2 (as appropriate for the 2.x line in use), or upgrade tools.jackson.core:jackson-databind to 3.1.6 or 3.2.2. Do not remain on 2.11.0–2.18.9, 2.19.0–2.21.5, 2.22.0–2.22.1, 3.0.0–3.1.5, or 3.2.0–3.2.1. As defense in depth, avoid declaring @JsonTypeInfo on overly broad bases such as Comparable; prefer closed allowlists via an explicit PolymorphicTypeValidator (BasicPolymorphicTypeValidator or equivalent) that permits only known application types. Do not enable default typing. Where Comparable-typed polymorphic fields are unnecessary, remove @JsonTypeInfo or replace them with concrete types. Rebuild and redeploy all artifacts that shade or vendor Jackson databind, including transitive copies.

How to confirm the fix worked

Confirm the resolved jackson-databind version in every runtime classpath, lockfile, and shaded JAR is at least 2.18.10, 2.21.6, 2.22.2, 3.1.6, or 3.2.2. Search source for @JsonTypeInfo on Comparable (and similar broad interfaces) and for missing custom PolymorphicTypeValidator configuration. After upgrade, exercise existing JSON fixtures for those endpoints and verify that type identifiers for types outside an explicit allowlist are rejected. Dependency scanners and SBOM diffs should show no remaining vulnerable jackson-databind coordinates. Staging tests should confirm functional JSON payloads still bind to intended application types.

Typical attack path

1. Find an application surface that accepts JSON and binds it with Jackson using @JsonTypeInfo on a Comparable base type without a custom PolymorphicTypeValidator.
2. Craft a JSON document whose type identifier names a Comparable-implementing class the attacker wants instantiated (such as a file-path type) rather than the type the application expected.
3. Submit that document to the deserialization endpoint so Jackson constructs the attacker-chosen object.
4. Rely on subsequent application logic that invokes path-sensitive or otherwise privileged methods on the deserialized value to achieve unauthorized file access or related impact.
5. Optionally repeat against other Comparable-typed polymorphic fields to expand impact; this path does not currently include a known in-band remote code execution gadget.

How to detect it

This CVE has no public exploit maturity and is not listed as actively exploited, so historical compromise is unlikely but not impossible. Review access logs and application logs for JSON request bodies that include polymorphic type metadata (Jackson type-id properties such as @class, @type, or a custom typeProperty) naming unexpected JDK types, especially java.io.File, on endpoints that bind Comparable or other generic types. Correlate with subsequent file-system errors, unexpected File or Path object construction, or access to unusual paths shortly after JSON parse. Inspect WAF/API-gateway payloads and deserialized-object debug traces if enabled. Look at application exception logs for InvalidTypeIdException versus successful binds of non-application types. There are no named threat actors associated with this issue; treat hits as opportunistic probing unless tied to a broader intrusion.

• "@class":"java.io.File"
• "@type":"java.io.File"
• java.io.File in JSON type-id / typeProperty fields
• @JsonTypeInfo on java.lang.Comparable
• jackson-databind versions 2.11.0-2.18.9, 2.19.0-2.21.5, 2.22.0-2.22.1, 3.0.0-3.1.5, 3.2.0-3.2.1 in classpath or SBOM
• com.fasterxml.jackson.databind.exc.InvalidTypeIdException
• unexpected java.io.File construction immediately after JSON parse

What your security team should do

• Inventory all services that depend on jackson-databind in the affected 2.11–2.22 and 3.0–3.2 ranges and schedule upgrades to 2.18.10, 2.21.6, 2.22.2, 3.1.6, or 3.2.2 immediately.
• Prioritize internet-facing and partner-facing JSON APIs, then internal message consumers that deserialize untrusted or semi-trusted payloads.
• Hunt source and configs for @JsonTypeInfo on Comparable or other broad JDK types without an explicit PolymorphicTypeValidator and tighten those bindings.
• Block or flag new use of polymorphic typing on JDK base types in code review and SAST rules.
• Re-scan containers, fat JARs, and third-party plugins for shaded jackson-databind so upgrades are not bypassed by bundled copies.
• Because exploit maturity is none and KEV is false, treat this as a patch-sprint item rather than an active incident unless detection finds matching traffic.