Vulnerabilities

Vulnerability · CVE-2026-83557

Comparable missing from DefaultBaseTypeLimitingValidator's unsafe base types (incomplete PolymorphicTypeValidator denylist)

Published Sep 1, 2026 · catalog updated Sep 1, 2026 · Comparable missing from DefaultBaseTypeLimitingValidator's

Last checked Nov 2, 2026. A connected source was read within the last 7 days.

Check if you run it

No confirmed exploitation is on record for CVE-2026-83557. EPSS is 0.72%. Act only if a listed version of Comparable missing from DefaultBaseTypeLimitingValidator's is installed.

Severity

Medium5.6

Known exploitation

Not in CISA/VulnCheck KEV

EPSS

0.72%

Remediation

Version ranges on file

Affected products

maven com.fasterxml.jackson.core:jackson-databind · maven tools.jackson.core:jackson-databind

### Summary — the used automatically whenever is applied without an explicitly configured custom validator — denies polymorphic resolution only for nine specific "unsafe base types" ( , , , , , , , , ). Its returns unconditionally for every other base type. is not in that list, despite being implemented by a very large fraction of JDK and application classes — comparable in breadth to , which is denylisted for exactly that reason. An application with an -annotated -typed property, and no custom validator configured, will accept a type identifier for essentially any class implementing . ### Details **Affected file:** The class's own JavaDoc acknowledges the design (*"Note that when using potentially unsafe base type like a custom implementation... is needed"*), so the trade-off of leaving broad base types unrestricted is intentional. The gap is that 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 ( was added recently for issue #5014). I verified this is specific to the **default, unconfigured validator** reached via bare usage. Global "Default Typing" via is **not** affected, because that method structurally requires an explicit argument — I confirmed a correctly-configured rejects the same payload under . ### PoC Built entirely from source (jackson-databind + jackson-core + jackson-annotations, , OpenJDK 21, no third-party gadget libraries, no network access): **1. Sanity check (benign class, confirms the mechanism fires):** **2. Real JDK class substitution:** **3. Negative control — Default Typing with an explicit custom PTV:** **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/p