Open actionable advisories and recorded vendor fixes. This public package view has no inventory attached and cannot establish whether your deployment is affected. A vendor fix never resolves your finding; verify your installed version and the source guidance.
Open advisories
85 actionable advisories, newest first. Withdrawn advisories and news are excluded. Coverage is partial.
When an @JsonIdentityInfo collection or map first creates N unresolved object-ID references and later resolves the same IDs in reverse order, jackson-databind scans the remaining pending-reference accumulator for each resolution. A shallow JSON document whose size grows linearly can therefore cause quadratic CPU work during deserialization. Details The affected path is forward-reference completion in CollectionDeserializer.CollectionReferringAccumulator.resolveForwardReference() and the corresponding map implementation. The implementation performs a linear search of the pending accumulator for every resolved object ID. The behavior is runtime-confirmed in jackson-databind 2.5.0, 2.22.1, and 3.2.1. Current 2.22 and 3.2 source branches retained the same design when rechecked. A 2.4.0 control fails closed before successful reverse-order completion, so 2.5.0 is the conservative runtime-confirmed affected floor. The patched versions are: 2.18.11, 2.21.7, 2.22.3, 3.1.7 and 3.2.3.…
Recommended action: Upgrade to 2.22.3, 2.21.7 or 2.18.11 by release line, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
With @JsonTypeInfo(use = Id.NAME, defaultImpl = ...), every distinct unknown raw type ID selects the same fallback deserializer but is retained as a separate key in TypeDeserializerBase.deserializers. An attacker who can repeatedly supply new unknown type IDs can grow this process-lifetime cache without a configured bound. Details The affected path is TypeDeserializerBase.findDeserializer(). After an unknown name-based type ID resolves to the configured fallback/default implementation, jackson-databind caches the result under the attacker-provided raw typeId. Although all such IDs select the same fallback deserializer, each new string remains a distinct cache key. The behavior is runtime-confirmed in jackson-databind 2.22.1 and 3.2.1. Current 2.22 and 3.2 source branches retained the unbounded deserializers map and per-raw-ID cache write when rechecked. The earlier affected floor has not been established, patched versions are: 2.18.11, 2.21.7, 2.22.3, 3.1.7 and 3.2.3. The…
Recommended action: Upgrade to 2.22.3, 2.21.7 or 2.18.11 by release line, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
DefaultBaseTypeLimitingValidator — the PolymorphicTypeValidator used automatically whenever @JsonTypeInfo is applied without an explicitly configured custom validator — denies polymorphic resolution only for nine specific "unsafe base types" (Object, Serializable, Closeable, AutoCloseable, Cloneable, Runnable, java.util.logging.Handler, javax.naming.Referenceable, javax.sql.DataSource). Its isSafeSubType() returns true unconditionally for every other base type. java.lang.Comparable is not in that list, despite being implemented by a very large fraction of JDK and application classes — comparable in breadth to Serializable, which is denylisted for exactly that reason. An application with an @JsonTypeInfo-annotated Comparable-typed property, and no custom validator configured, will accept a type identifier for essentially any class implementing Comparable. Details Affected file: src/main/java/tools/jackson/databind/jsontype/DefaultBaseTypeLimitingValidator.java The class's own…
Recommended action: Upgrade to 2.22.2, 2.21.6 or 2.18.10 by release line, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
jackson-databind 3.2.1 deserializes a JSON string bound to a javax.xml.datatype.Duration or javax.xml.datatype.XMLGregorianCalendar field by passing the raw string verbatim to DatatypeFactory.newDuration(value) / newXMLGregorianCalendar(value). Per the XML-Schema lexical grammar these factory methods accept numeric components of arbitrary length, which the JDK materializes into java.math.BigInteger / BigDecimal using the native BigInteger(String) constructor (an O(n²) parser). Because the digits reside inside a JSON string token, jackson-core's StreamReadConstraints.maxNumberLength guard (which bounds only JSON number tokens) never fires, so there is no length limit anywhere on this path. An unauthenticated attacker can submit a single small request (e.g. ~1–5 MB) that forces tens of seconds to minutes of single-thread CPU consumption, yielding a denial of service under the default JsonMapper.builder().build() mapper with no polymorphic typing or special configuration.…
Recommended action: Upgrade to 2.22.2, 2.21.6 or 2.18.10 by release line, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
A java.nio.file.Path field bound from untrusted JSON reaches JDKFromStringDeserializer.NioPathHelper.deserialize. The attacker string flows through new URI(value) → Path.of(uri), then on FileSystemNotFoundException into a ServiceLoader<FileSystemProvider enumeration that calls provider.getPath(uri) on the first scheme-matching provider. No scheme is rejected, so untrusted JSON can drive an arbitrary registered provider under the default JsonMapper.builder().build(). Impact is bounded. The JDK built-in providers (file, jar/zipfs) do no network I/O and do not mount, so the path is inert without a side-effecting third-party provider. Binding Path from untrusted input is already an anti-pattern. Description NioPathHelper.deserialize performs provider resolution driven by the attacker URI (abridged; the real method also handles a Windows drive-letter prefix and wraps failures via ctxt.handleInstantiationProblem(...)): The attacker's scheme selects the provider and the attacker's…
Recommended action: Upgrade to 2.22.2, 2.21.6 or 2.18.10 by release line, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
CVE-2026-54514 (GHSA-hgj6-7826-r7m5) fixed an eager-DNS-resolution / SSRF issue in jackson-databind's deserialization of java.net.InetSocketAddress by switching to InetSocketAddress.createUnresolved(...) (PR #5951, commit 1f5a1037, released in 2.18.8 / 2.21.4 / 3.1.4). That fix did not cover the sibling java.net.InetAddress branch in the very same FromStringDeserializer.Std.deserialize() switch statement, which still calls InetAddress.getByName(value) and therefore performs an eager forward DNS lookup on attacker-controlled input at deserialization time. The fix is incomplete: the same vulnerability class remains reachable through InetAddress. Details File: src/main/java/com/fasterxml/jackson/databind/deser/std/FromStringDeserializer.java Sibling cases in the same switch: - Line 357-358 (UNFIXED): case STDINETADDRESS: return InetAddress.getByName(value); // eager forward DNS lookup - Line 359-381 + helper at 494-496 (FIXED by PR #5951): protected InetSocketAddress…
Recommended action: Upgrade to 2.22.1, 2.21.5 or 2.18.9 by release line, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
UnwrappedPropertyHandler.processUnwrapped() replays the buffered JSON for a @JsonUnwrapped property by iterating its properties and calling prop.deserializeAndSet() with no prop.visibleInView(ctxt.getActiveView()) guard — the exact guard processUnwrappedCreatorProperties() received in the #5971 / GHSA-rcqc-6cw3-h962 fix, and the guard BeanDeserializer.deserializeWithUnwrapped applies to directly-matched properties. As a result, a property annotated with both @JsonView(PrivilegedView.class) and @JsonUnwrapped is written from attacker JSON even when deserializing under a more-restrictive active view. Correction to the original framing (runtime-verified): the gap is NOT a per-field inner @JsonView (the unwrapped sub-object's own BeanDeserializer gates inner fields correctly). The unchecked gate is the view of the unwrapped CONTAINER property. Intent proof (runtime, 2.x HEAD 21dd70dd and 3.x HEAD 7a5939d6) An @JsonView(AdminView) property that is NOT @JsonUnwrapped → null under…
Recommended action: Upgrade to 2.22.1, 2.21.5 or 2.18.9 by release line, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
In BeanDeserializer.deserializeUsingPropertyBasedWithExternalTypeId, the active-view (@JsonView) filter was applied only to the regular bean-property branch; the creator-property branch performed no creatorProp.visibleInView(activeView) check. A constructor parameter annotated with both @JsonView(RestrictedView.class) and @JsonTypeInfo(use=Id.NAME, include=As.EXTERNALPROPERTY) is populated from attacker JSON even when a more restrictive view is active. This is a patch gap. GHSA-5hh8 (CVE-2026-54517) and GHSA-rcqc (CVE-2026-54518) descriptions cover only the main property-based path and the unwrapped-creator path respectively; the external-type-id creator path was fixed on the 3.x line via #6004 ("Extend #5969/#5971 fixes to ... external-type-id case in regular BeanDeserializer", commit 7dc7a17, 2026-05-22) but the fix was never backported to 2.21 or 2.18. Users on 2.21.4 and 2.18.8 who upgraded per the published advisories remain vulnerable to the same @JsonView bypass…
Recommended action: Upgrade to 2.21.5 or 2.18.9 by release line, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
For Java Records, POJOPropertiesCollector.removeUnwantedIgnorals() records a @JsonIgnore-annotated component under its original implicit name before renameUsing() applies the PropertyNamingStrategy. After the rename, ignoredPropertyNames still holds only the pre-rename name, so ignorableProps is built from the stale key. The renamed JSON key passes IgnorePropertiesUtil.shouldIgnore() and is assigned to the Record's constructor parameter, defeating the @JsonIgnore. Impact A Record using a naming strategy that relies on @JsonIgnore to keep an internal/privileged component out of deserialization can have that component set from the wire via its renamed key (e.g. a role/flag controlled by an untrusted client). Affected / Patched (verified via git tag --contains) - 2.15-2.18 line: = 2.15.0, < 2.18.8 - fixed in 2.18.8 (backport c7c6783) - 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 (#5974, baa2cdf) Severity / CWE Maintainer:…
Recommended action: Upgrade to 2.21.4 or 2.18.8 by release line, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
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…
Recommended action: Upgrade to 3.1.4 or 2.21.4 by release line, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
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:…
Recommended action: Upgrade to 3.1.4 or 2.21.4 by release line, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
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 Will be fixed in 2.18.9, 2.21.5, 2.22.1 and 3.1.4. Severity / CWE Maintainer: minor. Reporter: Moderate. CWE-915. Upstream fix FasterXML/jackson-databind#5962 (PR #5964,…
Recommended action: Upgrade to 3.1.4, 2.22.1, 2.21.5 or 2.18.9 by release line, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
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…
Recommended action: Upgrade to 3.1.4, 2.21.4 or 2.18.8 by release line, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
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, <…
Recommended action: Upgrade to 3.1.4, 2.21.4 or 2.18.8 by release line, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
`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 ` ` 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…
Recommended action: Upgrade to 3.1.4, 2.21.4 or 2.18.8 by release line, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
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)
Recommended action: Upgrade to 2.14.0 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
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.
Recommended action: Upgrade to 2.21.4 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
jackson-databind 2.10.x through 2.12.x before 2.12.6 and 2.13.x before 2.13.1 allows attackers to cause a denial of service (2 GB transient heap usage per read) in uncommon situations involving JsonNode JDK serialization.
Recommended action: Upgrade to 2.13.1 or 2.12.6 by release line, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
In FasterXML jackson-databind 2.4.0-rc1 until 2.12.7.1 and in 2.13.x before 2.13.4.2 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. This was patched in 2.12.7.1, 2.13.4.2, and 2.14.0. Commits that introduced vulnerable code are https://github.com/FasterXML/jackson-databind/commit/d499f2e7bbc5ebd63af11e1f5cf1989fa323aa45, https://github.com/FasterXML/jackson-databind/commit/0e37a39502439ecbaa1a5b5188387c01bf7f7fa1, and https://github.com/FasterXML/jackson-databind/commit/7ba9ac5b87a9d6ac0d2815158ecbeb315ad4dcdc. Fix commits are https://github.com/FasterXML/jackson-databind/commit/cd090979b7ea78c75e4de8a4aed04f7e9fa8deea and https://github.com/FasterXML/jackson-databind/commit/d78d00ee7b5245b93103fef3187f70543d67ca33. The 2.13.4.1 release does fix this issue, however it also references a non-existent jackson-bom which causes build failures for gradle…
Recommended action: Upgrade to 2.13.4.2 or 2.12.7.1 by release line, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
In FasterXML jackson-databind before 2.12.7.1 and in 2.13.x 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. This issue can only happen when the UNWRAPSINGLEVALUEARRAYS feature is explicitly enabled.
Recommended action: Upgrade to 2.13.4 or 2.12.7.1 by release line, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
The com.fasterxml.jackson.core:jackson-databind library before version 2.9.10.4 is vulnerable to an Unsafe Deserialization vulnerability when handling interactions related to the class ignite-jta.
Recommended action: Upgrade to 2.9.10.4 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
jackson-databind is a data-binding package for the Jackson Data Processor. jackson-databind allows a Java stack overflow exception and denial of service via a large depth of nested objects.
Recommended action: Upgrade to 2.13.2.1 or 2.12.6.1 by release line, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
FasterXML jackson-databind 2.x before 2.9.10.8 an 2.6.7.5 mishandles the interaction between serialization gadgets and typing, related to com.newrelic.agent.deps.ch.qos.logback.core.db.DriverManagerConnectionSource.
Recommended action: Upgrade to 2.9.10.8 or 2.6.7.5 by release line, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
FasterXML jackson-databind 2.x before 2.9.10.8 mishandles the interaction between serialization gadgets and typing, related to org.apache.tomcat.dbcp.dbcp.datasources.SharedPoolDataSource.
Recommended action: Upgrade to 2.9.10.8 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
FasterXML jackson-databind 2.x before 2.9.10.8 and 2.6.7.5 mishandles the interaction between serialization gadgets and typing, related to com.newrelic.agent.deps.ch.qos.logback.core.db.JNDIConnectionSource.
Recommended action: Upgrade to 2.9.10.8 or 2.6.7.5 by release line, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.