CVE-2026-54512

What it actually does

This flaw bypasses Jackson Databind's PolymorphicTypeValidator allow-list when polymorphic deserialization is enabled and the attacker-controlled type identifier uses a generic canonical type such as an allowed container with a disallowed nested type argument. Jackson validates only the raw outer container class name before the '<' character, then constructs and resolves the full parameterized type without separately validating the nested generic class. As a result, a class that should have been denied by the configured validator can be loaded, instantiated, and populated from attacker-controlled JSON. Depending on the classes available on the application's classpath and how the application processes deserialized objects, impact can range from unauthorized object creation and data manipulation to code execution, sensitive data exposure, or denial of service.

Why it matters to the business

Applications that accept untrusted JSON and use Jackson polymorphic typing may lose the protection they expected from a strict type allow-list. A successful attack could let an unauthenticated remote attacker influence server-side object creation, potentially leading to application compromise, data theft, service disruption, or lateral movement if exploitable gadget classes are present. The issue has a high CVSS score, but exploitation is currently assessed as higher-complexity, has low EPSS, is not listed in CISA KEV, and has no reported mature public exploitation in the provided data; nevertheless, Jackson is widely embedded in Java services and dependency chains, so exposure may be indirect and should be remediated through dependency management.

How an attack unfolds

An attacker first identifies an application endpoint that accepts JSON or another Jackson-supported payload format and deserializes it using polymorphic typing. The attacker must also determine or infer that the application has configured a PolymorphicTypeValidator that allow-lists a generic container type, such as a collection, while denying one or more sensitive nested classes. The attacker then crafts a type identifier using a parameterized type string, placing the allowed container as the raw outer type and a prohibited class as the generic type argument. Because the vulnerable Jackson logic validates only the raw container name before parsing the full canonical type, the outer class passes validation. Jackson then resolves the full generic type, loads the nested class, instantiates it, and sets bean properties from attacker-supplied JSON. If the nested class has dangerous constructors, setters, lifecycle behavior, or gadget-chain behavior reachable in the application context, the attacker may achieve arbitrary effects such as code execution, data access, or denial of service. If no useful gadget or dangerous class exists on the classpath, exploitation may be limited or fail.

How to fix it

Upgrade jackson-databind to a fixed version on the appropriate release line: 2.18.8 or later, 2.21.4 or later, or 3.1.4 or later. If using dependency management through Maven, Gradle, Spring Boot, application servers, shaded JARs, or vendor-packaged libraries, verify the effective resolved version rather than only the declared direct dependency. Where immediate upgrade is not possible, reduce exposure by disabling polymorphic typing for untrusted input, avoiding default typing, restricting deserialization to explicit concrete DTO classes, rejecting type identifiers containing generic canonical type syntax from untrusted payloads, and placing strict input validation and authentication in front of affected endpoints. Mitigations should be treated as temporary because the vulnerability is in the validator bypass logic itself.

How to confirm the fix worked

Confirm the deployed application resolves jackson-databind to a fixed version: 2.18.8+, 2.21.4+, or 3.1.4+. Use build tooling such as 'mvn dependency:tree', 'gradle dependencies', SBOM scans, container image scans, and runtime classpath inspection to detect both direct and transitive copies, including shaded or bundled JARs. Review application code and framework configuration for use of polymorphic typing, default typing, '@JsonTypeInfo', 'activateDefaultTyping', or custom PolymorphicTypeValidator implementations. For security testing in non-production environments, attempt to deserialize a benign parameterized type ID where the raw container is allow-listed but the nested type should be denied, and verify that the fixed version rejects the nested type rather than resolving it. Also confirm that ingress controls or application validation reject unexpected type metadata from untrusted clients.

Typical attack path

1. Find a remotely reachable application function that deserializes attacker-controlled JSON using Jackson polymorphic typing.
2. Confirm or infer that generic container types are permitted by the configured PolymorphicTypeValidator.
3. Identify a disallowed but classpath-accessible nested class whose construction or property population creates a security impact.
4. Craft a payload with a polymorphic type identifier containing a generic parameter, such as an allowed container wrapping the targeted nested class.
5. Send the malicious JSON payload to the vulnerable endpoint.
6. Jackson validates only the raw outer container type, then resolves and instantiates the nested generic type without validating it against the PTV.
7. Trigger the side effect of the instantiated nested class or gadget chain to obtain data, alter application state, execute code, or disrupt service.

How to detect it

Historical exploitation is difficult to prove solely from Jackson logs because successful deserialization may look like normal request processing unless application-level auditing captures type metadata. Focus on web access logs, API gateway logs, WAF events, application request logs, Java exception logs, EDR telemetry, and class-loading or process execution telemetry. Search for inbound JSON containing polymorphic type metadata with generic canonical type syntax, especially strings containing '@class', '@type', or similar type-discriminator fields where the value includes '<' and references Java collection/container classes. Investigate deserialization exceptions such as InvalidTypeIdException, JsonMappingException, ClassNotFoundException, LinkageError, or stack traces involving PolymorphicTypeValidator, DatabindContext, TypeFactory.constructFromCanonical, or _resolveAndValidateGeneric. On hosts, look for post-exploitation evidence consistent with Java deserialization attacks: unexpected child processes spawned by the Java service, outbound connections from application servers, dropped files in temporary directories, unusual class loading, suspicious script execution, or changes to application data immediately after malformed JSON requests. Because exploitation depends on application-specific reachable classes, correlate suspicious payloads with endpoint behavior, authentication context, response anomalies, and follow-on host activity.

• @class
• @type
• <
• >
• java.util.ArrayList<
• java.util.LinkedList<
• java.util.HashSet<
• java.util.HashMap<
• java.util.Collection<
• java.util.List<
• java.util.Map<
• com.fasterxml.jackson.databind.exc.InvalidTypeIdException
• com.fasterxml.jackson.databind.JsonMappingException
• PolymorphicTypeValidator
• DatabindContext._resolveAndValidateGeneric
• _resolveAndValidateGeneric
• TypeFactory.constructFromCanonical
• constructFromCanonical
• ClassNotFoundException
• Class.forName
• activateDefaultTyping
• @JsonTypeInfo

What your security team should do

• Inventory all Java applications, services, containers, and packaged products that include jackson-databind versions from 2.10.0 up to the fixed release lines.
• Prioritize internet-facing services, APIs accepting JSON from untrusted users, and applications known to use Jackson polymorphic typing or default typing.
• Upgrade to jackson-databind 2.18.8+, 2.21.4+, or 3.1.4+ according to the supported branch in use.
• Regenerate and review SBOMs to find transitive, shaded, or vendor-bundled copies of jackson-databind that normal dependency scans may miss.
• Temporarily disable polymorphic deserialization for untrusted inputs or block type identifiers containing generic parameters until upgrades are complete.
• Search logs for suspicious type metadata containing generic canonical type strings, especially values that combine allowed Java container classes with unexpected application or third-party classes.
• Review deserialization error logs for rejected or unusual polymorphic type IDs, class-loading failures, and InvalidTypeIdException events.
• Add regression tests that verify nested generic type arguments are validated by the PolymorphicTypeValidator.
• Monitor vendor advisories for frameworks or commercial products that bundle Jackson and may require separate patches.