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, BasicPolymorphicTypeValidator.Builder.allowIfSubTypeIsArray() allowlists any array type based only on clazz.isArray(), without validating the array's component (element) type against the configured allowlist. A PTV built with allowIfSubTypeIsArray() plus an explicit concrete-type allowlist therefore still permits EvilType[] even though EvilType is not allowlisted. When Jackson deserializes the elements and no per-element type IDs are present, it instantiates the component type directly with no further PTV check, bypassing the allowlist. 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.13.0 until 2.14.0, a potential Denial-of-Service exists when attacker sends deeply nested JSON if (and only if) the service reads deeply nested (1000s of levels) JSON as JsonNode (ObjectMapper.readTree()) and writes out same (or modifided) node using JsonNode.toString(). This can consume significant amount of resources with concurrent relatively small requests (1000 nested arrays is 2kB). This vulnerability is fixed in 2.14.0.

Summary UnwrappedPropertyHandler.processUnwrappedCreatorProperties() replays buffered JSON into creator parameters but never consults prop.visibleInView(activeView). The normal property-based creator path gates creator properties on the active view, but this unwrapped-creator replay path bypasses that check, so a constructor parameter annotated with both @JsonView(AdminView.class) and @JsonUnwrapped is populated from attacker JSON even when a more restrictive view is active.

Impact View-restricted unwrapped creator parameters can be set from untrusted input where @JsonView is used as a write-side authorization boundary.

Affected / Patched (verified via git tag --contains) - 2.21 line: >= 2.21.0, < 2.21.4 -> fixed in 2.21.4 (backport 721fa07, #5973) - 3.x line: >= 3.0.0, < 3.1.4 -> fixed in 3.1.4 (#5971, d633bc0)

Severity / CWE Maintainer: minor. Reporter: HIGH. CWE-863 (Incorrect Authorization); related CWE-284.

Credits Omkhar Arasaratnam (@omkhar) - finder.

Impact

Potential Denial-of-Service when attacker sends deeply nested JSON if (and only if) service:

1. Reads deeply nested (1000s of levels) JSON as JsonNode (ObjectMapper.readTree()) 2. Writes out same (or modifided) node using JsonNode.toString()

which can consume significant amount of resources with concurrent relatively small requests (1000 nested arrays is 2kB).

Patches

Fixed in 2.14.0 via https://github.com/FasterXML/jackson-databind/issues/3447.

Workarounds

Avoid serializing JsonNode using toString(): use ObjectMapper.writeValueAsString(node)

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.WRAPPERARRAY)):

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, 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.

Summary BasicPolymorphicTypeValidator.Builder.allowIfSubTypeIsArray() allowlists any array type based only on clazz.isArray(), without validating the array's component (element) type against the configured allowlist. A PTV built with allowIfSubTypeIsArray() plus an explicit concrete-type allowlist therefore still permits EvilType[] even though EvilType is not allowlisted. When Jackson deserializes the elements and no per-element type IDs are present, it instantiates the component type directly with no further PTV check, bypassing the allowlist.

Impact Applications using BasicPolymorphicTypeValidator with allowIfSubTypeIsArray() as a safeguard get no protection for concrete array component types; an attacker controlling JSON can instantiate non-allowlisted types via an array wrapper, re-opening the gadget-instantiation risk PTV is meant to prevent.

Affected / Patched (verified via git tag --contains) - 2.18 line: >= 2.10.0, < 2.18.8 -> fixed in 2.18.8 - 2.19-2.21 line: >= 2.19.0, < 2.21.4 -> fixed in 2.21.4 - 3.x line: >= 3.0.0, < 3.1.4 -> fixed in 3.1.4

PolymorphicTypeValidator was added in 2.10.0 so vulnerability N/A for versions prior to that.

Severity / CWE Maintainer: significant. Reporter: HIGH. CWE-184 (Incomplete List of Disallowed Inputs); related CWE-502.

Upstream fix FasterXML/jackson-databind#5981; fix PR #5983 (24529da), 2.18 backport PR #5984 (01d1692). Released 2026-06-04 in 2.18.8 / 2.21.4 / 3.1.4.

Credits Omkhar Arasaratnam (@omkhar) - finder.

Summary JDKFromStringDeserializer constructed InetSocketAddress with new InetSocketAddress(host, port), which performs eager DNS name resolution for hostname inputs at deserialization time. An application that binds untrusted JSON into a type containing an InetSocketAddress field issues an attacker-chosen DNS query during readValue, before any application-level validation or connect logic. The fix uses InetSocketAddress.createUnresolved(host, port), deferring DNS to an explicit connect.

Impact An attacker controlling JSON deserialized into an InetSocketAddress-bearing type can force outbound DNS lookups for attacker-chosen hostnames at deserialization time (SSRF / DNS-based out-of-band interaction / internal-resolver probing), purely from binding.

Affected / Patched (verified via git tag --contains on 1f5a103) - 2.18 line: >= 2.18.0, < 2.18.8 -> fixed in 2.18.8 - 2.19-2.21 line: >= 2.19.0, < 2.21.4 -> fixed in 2.21.4 - 3.x line: >= 3.0.0, < 3.1.4 -> fixed in 3.1.4

Severity / CWE Maintainer: minor. Reporter: LOW. CWE-918 (SSRF).

Upstream fix FasterXML/jackson-databind#5951 ("Improve InetSocketAddress deserialization"). Released 2026-06-04 in 2.18.8 / 2.21.4 / 3.1.4.

Credits Omkhar Arasaratnam (@omkhar) - finder.

Summary In BeanDeserializerBase.createContextual(), per-property @JsonIgnoreProperties exclusions are applied by handleByNameInclusion(), producing a contextual deserializer whose BeanPropertyMap has the ignored properties removed. The subsequent per-property case-insensitivity block (triggered by @JsonFormat(ACCEPTCASEINSENSITIVEPROPERTIES)) rebuilds from this.beanProperties (the original, unfiltered map) instead of contextual.beanProperties, then overwrites the filtered map — restoring every property handleByNameInclusion had just removed. The ignored property becomes writable again.

Impact An application that both enables case-insensitive matching and relies on per-property @JsonIgnoreProperties to keep a field unwritable can have that field set from untrusted JSON (mass-assignment-style write).

Affected / Patched Fixed in 2.18.9, 2.21.5 and 3.1.4.

Severity / CWE Maintainer: minor. Reporter: Moderate. CWE-915.

Upstream fix FasterXML/jackson-databind#5962 (PR #5964, 0e1b0b2), milestone 3.1.4. Released 2026-06-04.

Credits Omkhar Arasaratnam (@omkhar) - finder.

Summary POJOPropertiesCollector.renameProperties() allows a property with @JsonProperty("renamed") on the getter and @JsonIgnore on the setter to be renamed rather than dropped. With MapperFeature.INFERPROPERTYMUTATORS enabled (default), the private backing field is retained; during deserialization BeanDeserializerFactory.addBeanProps() sees hasField()==true, builds a FieldProperty, and makes the backing field writable. An attacker supplying the renamed JSON key writes the backing field directly, bypassing the @JsonIgnore on the setter.

Impact POJOs combining a renamed getter with an ignored setter (a read-only-over-the-wire pattern) have that field silently set from attacker input (property tampering / mass assignment). Not a general gadget; no RCE.

Affected / Patched (verified via git tag --contains) - 2.21 line: >= 2.21.0, < 2.21.4 -> fixed in 2.21.4 (backport c3d56dd, #5968) - 3.x line: >= 3.0.0, < 3.1.4 -> fixed in 3.1.4 (#5967, e88cb17)

Severity / CWE Maintainer: minor. Reporter: HIGH. CWE-915.

Credits Omkhar Arasaratnam (@omkhar) - finder.

Summary In BeanDeserializer.deserializeUsingPropertyBased, the active-view (@JsonView) filter was applied only to creator properties; the regular property-buffering branch performed no prop.visibleInView(activeView) check. A change making SetterlessProperty.isMerging() return true routed setterless Collection/Map properties through this unguarded path, so a setterless collection annotated with a restricted @JsonView is populated from attacker JSON even when the active view excludes it.

Impact View-restricted (e.g. admin-only) setterless collection/map properties can be written from untrusted JSON despite @JsonView gating — an access-control / mass-assignment bypass. No RCE or DoS.

Affected / Patched (verified via git tag --contains) - 2.21 line: >= 2.21.0, < 2.21.4 -> fixed in 2.21.4 (backport 94c5d21, #5970) - 3.x line: >= 3.0.0, < 3.1.4 -> fixed in 3.1.4 (#5969, 5bf23ed)

Severity / CWE Maintainer: minor. Reporter: HIGH. CWE-863 (Incorrect Authorization); related CWE-1220.

Credits Omkhar Arasaratnam (@omkhar) - finder.

jackson-core contains core low-level incremental ("streaming") parser and generator abstractions used by Jackson Data Processor. In versions prior to 2.15.0, if a user parses an input file and it has deeply nested data, Jackson could end up throwing a StackoverflowError if the depth is particularly large. jackson-core 2.15.0 contains a configurable limit for how deep Jackson will traverse in an input document, defaulting to an allowable depth of 1000. jackson-core will throw a StreamConstraintsException if the limit is reached. jackson-databind also benefits from this change because it uses jackson-core to parse JSON inputs. As a workaround, users should avoid parsing input files from untrusted sources.

Impact With older versions of jackson-core, if you parse an input file and it has deeply nested data, Jackson could end up throwing a StackoverflowError if the depth is particularly large.

Patches jackson-core 2.15.0 contains a configurable limit for how deep Jackson will traverse in an input document, defaulting to an allowable depth of 1000. Change is in https://github.com/FasterXML/jackson-core/pull/943. jackson-core will throw a StreamConstraintsException if the limit is reached. jackson-databind also benefits from this change because it uses jackson-core to parse JSON inputs.

Workarounds Users should avoid parsing input files from untrusted sources.

DISPUTED jackson-databind through 2.15.2 allows attackers to cause a denial of service or other unspecified impact via a crafted object that uses cyclic dependencies. NOTE: the vendor's perspective is that this is not a valid vulnerability report, because the steps of constructing a cyclic data structure and trying to serialize it cannot be achieved by an external attacker.

A flaw was found in Jackson Databind. This issue may allow a malicious user to cause a denial of service (2 GB transient heap usage per read) in uncommon situations involving JsonNode JDK serialization.

In FasterXML jackson-databind before 2.13.4, resource exhaustion can occur because of a lack of a check in BeanDeserializer.deserializeFromArray to prevent use of deeply nested arrays. An application is vulnerable only with certain customized choices for deserialization.

https://github.com/FasterXML/jackson-databind/issues/3582 https://bugs.chromium.org/p/oss-fuzz/issues/detail?id=50490 https://github.com/FasterXML/jackson-databind/commit/063183589218fec19a9293ed2f17ec53ea80ba88

In FasterXML jackson-databind before 2.14.0-rc1, resource exhaustion can occur because of a lack of a check in primitive value deserializers to avoid deep wrapper array nesting, when the UNWRAPSINGLEVALUEARRAYS feature is enabled. Additional fix version in 2.13.4.1 and 2.12.17.1

https://github.com/FasterXML/jackson-databind/commit/d78d00ee7b5245b93103fef3187f70543d67ca33 https://bugs.chromium.org/p/oss-fuzz/issues/detail?id=51020 https://github.com/FasterXML/jackson-databind/issues/3590

A flaw was found in FasterXML jackson-databind. This issue could allow an attacker to benefit from resource exhaustion when the UNWRAPSINGLEVALUEARRAYS feature is enabled due to unchecked primitive value deserializers to avoid deep wrapper array nesting.

A flaw was found In FasterXML jackson-databind. This issue could allow an attacker to benefit from resource exhaustion due to the lack of a check in BeanDeserializer.deserializeFromArray to prevent the use of deeply nested arrays. An application is only vulnerable with certain customized choices for deserialization.

A deserialization flaw was discovered in jackson-databind through 2.9.10.4. It could allow an unauthenticated user to perform code execution via ignite-jta or quartz-core: org.apache.ignite.cache.jta.jndi.CacheJndiTmLookup, org.apache.ignite.cache.jta.jndi.CacheJndiTmFactory, and org.quartz.utils.JNDIConnectionProvider.

A flaw was found in jackson-databind before 2.9.10.7 and 2.6.7.5. FasterXML mishandles the interaction between serialization gadgets and typing. The highest threat from this vulnerability is to data confidentiality and integrity as well as system availability.

A flaw was found in jackson-databind. FasterXML mishandles the interaction between serialization gadgets and typing. The highest threat from this vulnerability is to data confidentiality and integrity as well as system availability.

A flaw was found in jackson-databind. FasterXML mishandles the interaction between serialization gadgets and typing. The highest threat from this vulnerability is to data confidentiality and integrity as well as system availability.

A flaw was found in jackson-databind. FasterXML mishandles the interaction between serialization gadgets and typing. The highest threat from this vulnerability is to data confidentiality and integrity as well as system availability.

A flaw was found in jackson-databind. FasterXML mishandles the interaction between serialization gadgets and typing. The highest threat from this vulnerability is to data confidentiality and integrity as well as system availability.

A flaw was found in jackson-databind. FasterXML mishandles the interaction between serialization gadgets and typing. The highest threat from this vulnerability is to data confidentiality and integrity as well as system availability.

A flaw was found in jackson-databind. FasterXML mishandles the interaction between serialization gadgets and typing. The highest threat from this vulnerability is to data confidentiality and integrity as well as system availability.

A flaw was found in jackson-databind. FasterXML mishandles the interaction between serialization gadgets and typing. The highest threat from this vulnerability is to data confidentiality and integrity as well as system availability.

A flaw was found in jackson-databind. FasterXML mishandles the interaction between serialization gadgets and typing. The highest threat from this vulnerability is to data confidentiality and integrity as well as system availability.

A flaw was found in jackson-databind. FasterXML mishandles the interaction between serialization gadgets and typing. The highest threat from this vulnerability is to data confidentiality and integrity as well as system availability.

A flaw was found in jackson-databind. FasterXML mishandles the interaction between serialization gadgets and typing. The highest threat from this vulnerability is to data confidentiality and integrity as well as system availability.