Hi,
The following vulnerabilities were published for jackson-databind.
CVE-2026-54512[0]:
| 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.
CVE-2026-54513[1]:
| 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.
CVE-2026-54514[2]:
| jackson-databind contains the general-purpose data-binding
| functionality and tree-model for Jackson Data Processor. From 2.0.0
| until 2.18.8, 2.21.4, and 3.1.4, 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. This vulnerability is fixed in 2.18.8, 2.21.4, and
| 3.1.4.
CVE-2026-54515[3]:
| jackson-databind contains the general-purpose data-binding
| functionality and tree-model for Jackson Data Processor. From 2.8.0
| until 2.18.9, 2.21.5, and 3.1.4, 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. This vulnerability is
| fixed in 2.18.9, 2.21.5, and 3.1.4.
CVE-2026-54516[4]:
| jackson-databind contains the general-purpose data-binding
| functionality and tree-model for Jackson Data Processor. From 2.21.0
| until 2.21.4 and 3.1.4, 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. This vulnerability is fixed
| in 3.1.4.
CVE-2026-54517[5]:
| jackson-databind contains the general-purpose data-binding
| functionality and tree-model for Jackson Data Processor. From 2.21.0
| until 2.21.4 and 3.1.4, 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.
| This vulnerability is fixed in 2.21.4 and 3.1.4.
CVE-2026-54518[6]:
| jackson-databind contains the general-purpose data-binding
| functionality and tree-model for Jackson Data Processor. From 2.21.0
| until 2.21.4 and 3.1.4,
| 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. This vulnerability is fixed in 2.21.4
| and 3.1.4.
If you fix the vulnerabilities please also make sure to include the
CVE (Common Vulnerabilities & Exposures) ids in your changelog entry.
For further information see:
[0] https://security-tracker.debian.org/tracker/CVE-2026-54512
https://www.cve.org/CVERecord?id=CVE-2026-54512
[1] https://security-tracker.debian.org/tracker/CVE-2026-54513
https://www.cve.org/CVERecord?id=CVE-2026-54513
[2] https://security-tracker.debian.org/tracker/CVE-2026-54514
https://www.cve.org/CVERecord?id=CVE-2026-54514
[3] https://security-tracker.debian.org/tracker/CVE-2026-54515
https://www.cve.org/CVERecord?id=CVE-2026-54515
[4] https://security-tracker.debian.org/tracker/CVE-2026-54516
https://www.cve.org/CVERecord?id=CVE-2026-54516
[5] https://security-tracker.debian.org/tracker/CVE-2026-54517
https://www.cve.org/CVERecord?id=CVE-2026-54517
[6] https://security-tracker.debian.org/tracker/CVE-2026-54518
https://www.cve.org/CVERecord?id=CVE-2026-54518
Regards,
Salvatore