GHSA-j3rv-43j4-c7qm CVE-2026-54512
jackson-databind has a PolymorphicTypeValidator bypass via generic type parameters that allows arbitrary class instantiation
- Severity
- 8.1 / 10
- High · CVSS 3.1
- Exploit chance (EPSS)
- 0.94%
- Chance of exploitation in the next 30 days. Higher than 61.07% of scored vulnerabilities.
- Known exploited
- No
- Not in CISA's catalog
- Fix
- Available
- 2 packages have a fixed version
Description
jackson-databind's PolymorphicTypeValidator (PTV) is the primary safety mechanism guarding polymorphic deserialization. When polymorphic typing is enabled and a type identifier contains generic parameters (i.e. the type ID string contains <), DatabindContext._resolveAndValidateGeneric() validates only the raw container class name (the substring before <) against the configured PTV.
If the container type is approved, the method parses the full canonical type string via TypeFactory.constructFromCanonical() and returns the fully parameterized type without ever validating the nested type arguments against the PTV. The nested type arguments are then resolved, instantiated, and populated as beans during deserialization.
An attacker who controls the type ID can therefore place a denied class as a generic type parameter of an allowed container — for example java.util.ArrayList<com.evil.Gadget> when only java.util.ArrayList is allow-listed. The container passes the PTV check; com.evil.Gadget is loaded via Class.forName(name, true, loader), instantiated, and its properties are set from attacker-controlled JSON. This completely bypasses an explicitly configured PTV allow-list.
This is the same vulnerability class responsible for the historical sequence of jackson-databind deserialization CVEs; here it manifests as a validator bypass rather than a missing deny-list entry.
Impact
- Bypass of the PTV allow-list, including the recommended
BasicPolymorphicTypeValidatorconfigured with name-prefix allow rules. - Arbitrary class instantiation of any type assignable to the container's element/parameter position, with attacker-controlled property values (setter/field injection).
- Potential unauthenticated remote code execution when a class with exploitable side effects (JNDI lookup, JDBC/connection-pool gadgets,
TemplatesImpl-style loaders, etc.) is present on the classpath.
Applications that accept untrusted JSON and rely on a configured PTV — the documented, security-conscious configuration — are affected.
Proof of Concept
Configuration restricting polymorphic deserialization to a single safe container:
BasicPolymorphicTypeValidator ptv = BasicPolymorphicTypeValidator.builder()
.allowIfSubType("java.util.ArrayList")
.build();
ObjectMapper mapper = JsonMapper.builder()
.polymorphicTypeValidator(ptv)
.build();
Malicious payload (Wrapper.value is Object with @JsonTypeInfo(use = Id.CLASS, include = As.WRAPPER_ARRAY)):
{"value":["java.util.ArrayList<com.evil.EvilGadget>",[{"cmd":"calc.exe"}]]}
On vulnerable versions, com.evil.EvilGadget is instantiated and its cmd property is set, despite only java.util.ArrayList being allow-listed. On 2.18.8 / 2.21.4 / 3.1.4 the deserialization throws InvalidTypeIdException before instantiation.
Variant payloads (all bypass an ArrayList/HashMap allow-list):
| Type ID | Smuggled type position |
|---|---|
java.util.ArrayList<Evil> |
list element |
java.util.HashMap<Evil,String> |
map key |
java.util.HashMap<String,Evil> |
map value |
java.util.ArrayList<java.util.ArrayList<Evil>> |
nested element |
java.util.ArrayList<Evil[]> |
array element |
Patches
Fixed in 2.18.8, 2.21.4 and 3.1.4 via the changes for FasterXML/jackson-databind#5988, commit 434d6c511. The fix adds recursive validation of each non-trivial type parameter (and array element types appearing as parameters) through the full PTV chain, with documented exemptions for Object (wildcard resolution) and Enum types.
PolymorphicTypeValidator was added in 2.10.0 so vulnerability N/A for versions prior to that.
Affected versions
Maven
| Package | Vulnerable | Fixed in |
|---|---|---|
| com.fasterxml.jackson.core:jackson-databind | >= 2.10.0, < 2.18.8 |
2.18.8 |
| com.fasterxml.jackson.core:jackson-databind | >= 3.0.0, < 3.1.4 |
3.1.4 |
| com.fasterxml.jackson.core:jackson-databind | >= 2.19.0, < 2.21.4 |
2.21.4 |
| tools.jackson.core:jackson-databind | >= 3.0.0, < 3.1.4 |
3.1.4 |
How to fix
Move to the fixed version or later with your package manager, update the lockfile, and run your tests. If the package only arrives through another dependency, upgrade that dependency first. If none of its releases pulls a fixed version yet, force the version with your package manager's override.
com.fasterxml.jackson.core:jackson-databind Maven → 2.18.8
- maven
<dependency><groupId>com.fasterxml.jackson.core</groupId><artifactId>jackson-databind</artifactId><version>2.18.8</version></dependency>- gradle
implementation("com.fasterxml.jackson.core:jackson-databind:2.18.8")
tools.jackson.core:jackson-databind Maven → 3.1.4
- maven
<dependency><groupId>tools.jackson.core</groupId><artifactId>jackson-databind</artifactId><version>3.1.4</version></dependency>- gradle
implementation("tools.jackson.core:jackson-databind:3.1.4")
Severity breakdown
CVSS 3.1 8.1
CVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:U/C:H/I:H/A:H
- Attack vector
- Network
- Attack complexity
- High
- Privileges required
- None
- User interaction
- None
- Scope
- Unchanged
- Confidentiality
- High
- Integrity
- High
- Availability
- High
Weakness
CWE-184: Incomplete List of Disallowed Inputs
The product implements a protection mechanism that relies on a list of inputs (or properties of inputs) that are not allowed by policy or otherwise require other action to neutralize before additional processing takes place, but the list is incomplete.
How to prevent it
- Implementation: Do not rely exclusively on detecting disallowed inputs. There are too many variants to encode a character, especially when different environments are used, so there is a high likelihood of missing some variants. Only use detection of disallowed inputs as a mechanism for detecting suspicious activity. Ensure that you are using other protection mechanisms that only identify "good" input - such as lists of allowed inputs - and ensure that you are properly encoding your outputs.
CWE-502: Deserialization of Untrusted Data
The product deserializes untrusted data without sufficiently ensuring that the resulting data will be valid.
How to prevent it
- Architecture and Design, Implementation: If available, use the signing/sealing features of the programming language to assure that deserialized data has not been tainted. For example, a hash-based message authentication code (HMAC) could be used to ensure that data has not been modified.
- Implementation: When deserializing data, populate a new object rather than just deserializing. The result is that the data flows through safe input validation and that the functions are safe.
- Implementation: Explicitly define a final object() to prevent deserialization.
- Architecture and Design, Implementation: Make fields transient to protect them from deserialization. An attempt to serialize and then deserialize a class containing transient fields will result in NULLs where the transient data should be. This is an excellent way to prevent time, environment-based, or sensitive variables from being carried over and used improperly.
- Implementation: Avoid having unnecessary types or gadgets (a sequence of instances and method invocations that can self-execute during the deserialization process, often found in libraries) available that can be leveraged for malicious ends. This limits the potential for unintended or unauthorized types and gadgets to be leveraged by the attacker. Add only acceptable classes to an allowlist. Note: new gadgets are constantly being discovered, so this alone is not a sufficient mitigation.
- Architecture and Design, Implementation: Employ cryptography of the data or code for protection. However, it's important to note that it would still be client-side security. This is risky because if the client is compromised then the security implemented on the client (the cryptography) can be bypassed.
- Operation: Use an application firewall that can detect attacks against this weakness. It can be beneficial in cases in which the code cannot be fixed (because it is controlled by a third party), as an emergency prevention measure while more comprehensive software assurance measures are applied, or to provide defense in depth [REF-1481].
References
Advisories
Packages
Other links
Timeline
- Published
- Last updated by the source
- Latest EPSS score
Related advisories
| Advisory | Severity | Why it's related |
|---|---|---|
| CVE-2026-110879 jackson-databind validates the outer class of a class-name type ID but accepts attacker-selected classes inside its generic arguments, even when those classes… | Critical | Linked by the source |
| GHSA-cxp5-3px4-pw24 jackson-databind quadratic forward-reference completion | High | Also affects com.fasterxml.jackson.core:jackson-databind |
| GHSA-wv8q-qhhj-9h54 jackson-databind retains every unknown raw type ID | High | Also affects com.fasterxml.jackson.core:jackson-databind |
| GHSA-q4xh-88c3-wmh7 jackson-databind: Duration XMLGregorianCalendar Unbounded Number Parse DoS | High | Also affects com.fasterxml.jackson.core:jackson-databind |
| GHSA-gx83-3vf8-gh7j jackson-databind: Comparable missing from DefaultBaseTypeLimitingValidator's unsafe base types (incomplete PolymorphicTypeValidator denylist) | Medium | Also affects com.fasterxml.jackson.core:jackson-databind |
| GHSA-wjgm-6hv5-3cvf jackson-databind: Path Deserialization Missing Scheme Allowlist for FileSystemProvider Resolution | Medium | Also affects com.fasterxml.jackson.core:jackson-databind |
| GHSA-vvgp-rfg2-7rr6 jackson-databind: Incomplete fix for CVE-2026-54514: eager DNS resolution (SSRF) still present in InetAddress deserialization | Medium | Also affects com.fasterxml.jackson.core:jackson-databind |
| GHSA-mhm7-754m-9p8w jackson-databind: `@JsonView` bypass for creator properties with `@JsonTypeInfo(include=As.EXTERNAL_PROPERTY)` | Medium | Also affects com.fasterxml.jackson.core:jackson-databind |
MergeHarbor checks every repository's dependencies against this database, ranks what matters by exploitability and reachability, routes it to the owning team and opens the fix pull request.
Check your repos with MergeHarbor