CVE-2026-54512/54513: Jackson PolymorphicTypeValidator Bypass

In early June 2026, the jackson-databind maintainers disclosed two High-severity vulnerabilities, CVE-2026-54512 and CVE-2026-54513, both scored CVSS 3.1 8.1 (AV:N/AC:H/PR:N/UI:N/S:U/C:H/I:H/A:H). Both defeat BasicPolymorphicTypeValidator (PTV), the allowlist mechanism the Jackson project documents as the security-conscious way to enable polymorphic deserialization. CVE-2026-54512 (CWE-184, CWE-502) lets an attacker smuggle a denied class through a generic type parameter of an allowed container (java.util.ArrayList<com.evil.Gadget>), and CVE-2026-54513 (CWE-184) lets an attacker do the same through the component type of an allowlisted array. Both are unauthenticated and network-reachable. They affect jackson-databind >= 2.10.0, < 2.18.8, >= 2.19.0, < 2.21.4, and >= 3.0.0, < 3.1.4; the fixes first shipped in 2.18.8, 2.21.4, and 3.1.4 on June 4, 2026. For applications pinned to an EOL Jackson 2.x line that cannot move to a patched release, there is no OSS fix available.

Running an unsupported Jackson or Spring Boot version? See NES for Spring.

‍

What are CVE-2026-54512 and CVE-2026-54513?

Both are bypasses of PolymorphicTypeValidator (PTV), classed as CWE-184 (Incomplete List of Disallowed Inputs), with CVE-2026-54512 also carrying CWE-502 (Deserialization of Untrusted Data). PTV is the gatekeeper that decides which concrete types Jackson is allowed to instantiate when polymorphic typing is enabled. The recommended configuration is a BasicPolymorphicTypeValidator built with an explicit name-prefix or concrete-type allowlist, so that only known-safe types can be resolved from attacker-influenced type IDs. Both CVEs let an attacker reach a type that is not on the allowlist anyway.

The affected component in each case is the validation path that runs before Jackson resolves a type ID into a concrete class:

• CVE-2026-54512 lives in DatabindContext._resolveAndValidateGeneric(). When a type ID string contains generic parameters (the string contains a <), only the raw container class name (the substring before the <) is checked against the PTV. The nested type arguments are never validated.
• CVE-2026-54513 lives in BasicPolymorphicTypeValidator.Builder.allowIfSubTypeIsArray(), which allowlists any array type based only on clazz.isArray() and never validates the array's component (element) type against the configured allowlist.

In both, the allowlist check passes on the outer shell while the dangerous type rides inside it.

‍

Severity and exploit conditions

Both CVEs share an identical CVSS 3.1 vector, published by the CNA (GitHub) as CVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:U/C:H/I:H/A:H, score 8.1 (High).

The AC:H rating is the honest qualifier here. Neither CVE is a turnkey exploit on its own: the attacker needs an exploitable class (a JNDI lookup helper, a JDBC or connection-pool gadget, a TemplatesImpl-style loader) already on the classpath, and the application must have polymorphic typing enabled with a PTV in place. The reason these matter despite AC:H is the population they hit. The affected configuration is not a misuse pattern. It is the documented, security-conscious setup: an explicit BasicPolymorphicTypeValidator allowlist. Teams that followed Jackson's hardening guidance after the long line of historical jackson-databind deserialization CVEs are precisely the teams exposed.

‍

What an attacker can do

Given an endpoint that deserializes untrusted JSON with polymorphic typing and a PTV allowlist, an attacker can:

• Bypass the PTV allowlist entirely. A field typed as Object with @JsonTypeInfo(use = Id.CLASS, include = As.WRAPPER_ARRAY) accepts a type ID. For CVE-2026-54512, the payload {"value":["java.util.ArrayList<com.evil.EvilGadget>",[{"cmd":"calc.exe"}]]} passes the check on java.util.ArrayList while com.evil.EvilGadget is the type actually loaded.
• Instantiate a non-allowlisted class via Class.forName(name, true, loader) and set attacker-controlled property values on it through setter and field injection.
• Smuggle the denied type through several positions. The maintainers' advisory documents list elements (ArrayList<Evil>), map keys (HashMap<Evil,String>), map values (HashMap<String,Evil>), nested generics (ArrayList<ArrayList<Evil>>), and array elements (ArrayList<Evil[]>), all bypassing an ArrayList or HashMap allowlist. CVE-2026-54513 covers the array-component variant where allowIfSubTypeIsArray() is the allow rule in play.
• Reach unauthenticated remote code execution when a class with exploitable side effects is on the classpath. This is the same gadget-instantiation risk PTV exists to prevent; these CVEs re-open it against allowlists that were configured correctly.

‍

Root cause

For CVE-2026-54512, the validator inspects the container and trusts its contents. When the type ID contains a <, _resolveAndValidateGeneric() validates only the substring before it. If the container (for example java.util.ArrayList) is approved, the method parses the full canonical string via TypeFactory.constructFromCanonical() and returns the fully parameterized type without ever running the nested type arguments back through the PTV. Those nested arguments are then resolved, instantiated, and populated as beans. The allowlist guards the wrapper and ignores what is inside it.

For CVE-2026-54513, allowIfSubTypeIsArray() approves a value purely because clazz.isArray() is true. The component type of the array, the thing that actually gets instantiated per element, is never checked against the allowlist. An EvilType[] therefore passes even when EvilType is denied, and when no per-element type IDs are present Jackson instantiates the component type directly with no further PTV check.

The upstream fix for the generic-parameter path landed via jackson-databind issue #5988, commit 434d6c511. The array-component path was fixed via issue #5981, fix PR #5983 (24529da), with the 2.18 line backport in PR #5984 (01d1692). The fix adds recursive validation of each non-trivial type parameter and array element type through the full PTV chain, with documented exemptions for Object (wildcard resolution) and Enum types. On a patched release, the malicious payloads throw InvalidTypeIdException before any instantiation occurs.

‍

Who is affected?

PolymorphicTypeValidator was introduced in jackson-databind 2.10.0, so releases prior to that do not expose this specific bypass path. Both CVEs share the same affected and patched ranges. The patched columns below list the first release on each line that contains the fix; later releases on each line (the 2.x line is at 2.22.0 and the 3.x line at 3.2.0 as of this writing) also include it.

The exposure for enterprises sits in the bottom rows. Jackson-databind is the default serialization layer across the Spring Boot ecosystem, and organizations standardized on an older Spring Boot generation are frequently pinned to a 2.1x or earlier Jackson line by their framework's dependency management. Jumping to a patched 2.x line can mean a coordinated Spring Boot upgrade rather than a single dependency bump, which is exactly the migration these teams have been deferring. On those EOL lines there is no OSS fix available.

‍

Mitigation guidance

Do not treat a PTV allowlist alone as sufficient on a vulnerable version. The entire point of both CVEs is that the allowlist is the thing being bypassed. Patching or replacing the affected jackson-databind is the remediation; configuration hardening is a supplement, not a substitute.

‍

Related CVEs

These two CVEs are a coordinated pair from the same June 2026 disclosure and should be tracked together:

• CVE-2026-54512: the generic-type-parameter PTV bypass (the variant with documented RCE-capable PoC).
• CVE-2026-54513: the array-component PTV bypass via allowIfSubTypeIsArray().

Both belong to the broader jackson-databind polymorphic-deserialization vulnerability class, the same lineage responsible for the historical sequence of Jackson deserialization CVEs, including the recent CVE-2025-52999 stack-overflow DoS in jackson-core. The difference this time is that the failure is in the validator itself rather than a missing entry in a deny-list.

Both vulnerabilities were reported by Omkhar Arasaratnam, with CVE-2026-54512 additionally credited to the researcher operating as caveeroo.

‍

Taking action

CVE-2026-54512 and CVE-2026-54513 carry a message that lands hard with security engineers: you configured BasicPolymorphicTypeValidator exactly as the documentation recommends, and you are still exposed. The allowlist did its job on the container and never looked inside it. For teams on a current Jackson line, the fix is a version bump to 2.18.8, 2.21.4, or 3.1.4 (or any later release on those lines). For teams pinned to an EOL Jackson 2.x line by an unsupported Spring Boot generation, there is no upstream OSS fix, and the realistic path is either a coordinated framework migration or a supported drop-in replacement.

NES for Spring delivers secure, drop-in replacements for EOL Spring Boot and its dependency tree, including jackson-databind, so organizations can resolve CVE-2026-54512 and CVE-2026-54513 without a forced upgrade. This is the same problem one global financial enterprise faced with its mission-critical Spring estate; HeroDevs let them keep their Spring infrastructure secured past end of life without halting the roadmap to migrate.

As a founding member of the Commonhaus Foundation, the open-source foundation that now hosts the Jackson project, HeroDevs is invested in the long-term sustainability of the ecosystems our customers depend on.

If your organization runs Jackson on an EOL Spring Boot line, talk to us about coverage: see NES for Spring or contact our team.