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.
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.
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 …
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 …
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 …
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 …
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.EXTERNAL_PROPERTY) 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 …
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): …
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.
POJOPropertiesCollector._renameProperties() allows a property with @JsonProperty("renamed") on the getter and @JsonIgnore on the setter to be renamed rather than dropped. With MapperFeature.INFER_PROPERTY_MUTATORS 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.
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.
Potential Denial-of-Service when attacker sends deeply nested JSON if (and only if) service: Reads deeply nested (1000s of levels) JSON as JsonNode (ObjectMapper.readTree()) 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).
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(ACCEPT_CASE_INSENSITIVE_PROPERTIES)) 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.
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.
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 …
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.
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.