jackson-databind contains the general-purpose data-binding functionality and tree-model for Jackson Data Processor. From 2.10.0 until…
[email protected]·CWE-184·Published 2026-06-23
jackson-databind contains the general-purpose data-binding functionality and tree-model for Jackson Data Processor. From 2.10.0 until 2.18.8, 2.21.4, and 3.1.4, 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 vulnerability is fixed in 2.18.8, 2.21.4, and 3.1.4.
jackson-databind contains the general-purpose data-binding functionality and tree-model for Jackson Data Processor. From 2.10.0 until 2.18.8, 2.21.4, and 3.1.4, 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 vulnerability is fixed in 2.18.8, 2.21.4, and 3.1.4.
`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 `BasicPolymorphicTypeValidator` configured 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: ```java 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)`): ```json {"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](https://github.com/FasterXML/jackson-databind/issues/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.
`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 `BasicPolymorphicTypeValidator` configured 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: ```java 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)`): ```json {"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](https://github.com/FasterXML/jackson-databind/issues/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.
jackson-databind contiene la funcionalidad de enlace de datos de propósito general y el modelo de árbol para Jackson Data Processor. Desde 2.10.0 hasta 2.18.8, 2.21.4 y 3.1.4, el PolymorphicTypeValidator (PTV) de jackson-databind es el mecanismo de seguridad principal que protege la deserialización polimórfica. Cuando la tipificación polimórfica está habilitada y un identificador de tipo contiene parámetros genéricos (es decir, la cadena de ID de tipo contiene <), DatabindContext._resolveAndValidateGeneric() valida solo el nombre de la clase de contenedor en bruto (la subcadena antes de <) contra el PTV configurado. Si el tipo de contenedor es aprobado, el método analiza la cadena de tipo canónico completa a través de TypeFactory.constructFromCanonical() y devuelve el tipo completamente parametrizado sin validar nunca los argumentos de tipo anidados contra el PTV. Los argumentos de tipo anidados son entonces resueltos, instanciados y poblados como beans durante la deserialización. Un atacante que controla el ID de tipo puede, por lo tanto, colocar una clase denegada como parámetro de tipo genérico de un contenedor permitido - por ejemplo, java.util.ArrayList<com.evil.Gadget> cuando solo java.util.ArrayList está en la lista de permitidos. El contenedor pasa la verificación del PTV; com.evil.Gadget se carga a través de Class.forName(name, true, loader), se instancia y sus propiedades se configuran desde JSON controlado por el atacante. Esto elude completamente una lista de permitidos del PTV configurada explícitamente. Esta vulnerabilidad se corrige en 2.18.8, 2.21.4 y 3.1.4.
| Version | Type | Source | Base | Exp | Impact | Vector |
|---|---|---|---|---|---|---|
| 3.1 | Primary | cve.org | 8.1 | — | — | CVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:U/C:H/I:H/A:H |
| 3.1 | Secondary | ENISA EUVD | 8.1 | — | — | CVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:U/C:H/I:H/A:H |
| 3.1 | Secondary | GHSA | 8.1 | — | — | CVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:U/C:H/I:H/A:H |
| 3.1 | Secondary | NVD | 8.1 | 2.2 | 5.9 | CVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:U/C:H/I:H/A:H |