CVE-2026-54512: jackson-databind PolymorphicTypeValidator Bypass via Generic Type Parameters

Technical summary

The vulnerability exists in DatabindContext._resolveAndValidateGeneric(), which is responsible for validating polymorphic type deserialization against the configured PolymorphicTypeValidator (PTV). When a type ID string contains angle brackets (indicating generic parameters), the method extracts and validates only the raw container class name—the substring before the '<' character. Upon validation success, it calls TypeFactory.constructFromCanonical() to parse the full parameterized type string, returning a fully generic type without re-validating the nested type arguments. During subsequent deserialization, the nested types are resolved via Class.forName() with runtime linking enabled, instantiated via reflection, and populated with attacker-controlled bean properties. An allow-list containing java.util.ArrayList is thus circumvented by a crafted type ID like ArrayList<com.malicious.Gadget>, which passes the container-level check but loads the denied gadget class without any PTV validation. The vulnerability affects jackson-databind 2.10.0–2.18.7, 2.21.0–2.21.3, and 3.1.0–3.1.3.

Business impact

This vulnerability creates a pathway to remote code execution for any application using jackson-databind with polymorphic deserialization enabled and a configured PTV allow-list. Organizations relying on the PolymorphicTypeValidator as a primary defense against gadget-chain attacks—a standard practice after earlier jackson-databind vulnerabilities—face complete security bypass. Even strict allow-lists are ineffective, potentially exposing web services, message processors, and data transformation pipelines to arbitrary code execution without authentication. The scope and severity depend on whether an organization's threat model accounts for untrusted JSON inputs; however, many Jackson users deliberately enable polymorphic typing and allow-lists specifically to safely handle semi-trusted data, making this a high-impact issue for that population.

Affected systems

jackson-databind versions 2.10.0 through 2.18.7, all of 2.21.0–2.21.3, and 3.1.0–3.1.3 are vulnerable. Any Java application embedding jackson-databind and using polymorphic deserialization with a PolymorphicTypeValidator is at risk if it processes untrusted JSON. Common integration points include Spring Data REST, Kafka consumers, messaging brokers, and RESTful web services that accept JSON payloads. Applications using only default (non-polymorphic) Jackson deserialization are unaffected.

Exploitability

Exploitation requires that an attacker control or influence the type identifier in a JSON payload sent to a vulnerable application. No user interaction or privileged access is needed; the attack is purely a malicious JSON craft. However, the application must have polymorphic deserialization enabled with a PTV configured, which is a deliberate opt-in configuration. In that context, exploitation is straightforward: an attacker supplies a type ID string with generic parameters wrapping a gadget class, and the validation bypass allows instantiation and bean-property population from JSON. The attack surface is high for applications accepting JSON from untrusted sources, but applications using Jackson in the default (non-polymorphic) mode are not vulnerable.

Remediation

Upgrade jackson-databind to version 2.18.8, 2.21.4, or 3.1.4 or later. These versions fix the validation bypass by ensuring that nested generic type arguments are also validated against the configured PolymorphicTypeValidator. If immediate patching is not feasible, review and tighten PolymorphicTypeValidator allow-lists to exclude generic container types where possible, or disable polymorphic deserialization if not required. Note that workarounds are limited; the fix requires patching.

Patch guidance

Apply updates to jackson-databind versions 2.18.8, 2.21.4, or 3.1.4 as follows: For Maven projects, update the dependency version in pom.xml and rebuild. For Gradle, update build.gradle. For applications using Spring Boot or other frameworks, verify that dependency management pulls the patched version—some frameworks may override transitive dependencies. Recompile and regression-test applications using polymorphic deserialization to ensure compatibility. Patching is recommended for all affected versions; there is no known breaking change in these maintenance releases.

Detection guidance

Monitor application logs and deserialization events for type ID strings containing angle brackets (e.g., 'ArrayList<...'). Enable debug logging in Jackson's ObjectMapper or use a custom PolymorphicTypeValidator that logs rejected types. Network detection is difficult without decryption, but behavioral monitoring can flag unexpected class instantiation (e.g., via JVM instrumentation or SecurityManager policies). During code review, search for ObjectMapper configurations that enable polymorphic deserialization and ensure PTV is explicitly configured. Scan dependency reports to identify affected jackson-databind versions in your supply chain.

Why prioritize this

This vulnerability warrants immediate action due to its high CVSS score (8.1), lack of user interaction requirement, and complete bypass of a security mechanism (PTV) that many organizations deploy specifically to mitigate gadget-chain risks. Although polymorphic deserialization is an opt-in feature, it is used in production systems (e.g., Spring Data REST defaults), and the fix is available and straightforward. Organizations should prioritize patching, especially those handling semi-trusted or untrusted JSON inputs.

Risk score, explained

The CVSS 3.1 score of 8.1 (HIGH) reflects network-accessible attack vector (AV:N), high complexity due to the need for polymorphic deserialization to be enabled (AC:H), no privilege or user interaction requirements (PR:N, UI:N), and high impact on confidentiality, integrity, and availability (C:H, I:H, A:H). The score is not critical because the vulnerability requires specific configuration (polymorphic typing + PTV enabled), which mitigates the absolute highest severity. However, for organizations meeting those conditions, the actual risk is severe.

Frequently asked questions