Security bypass allows arbitrary code execution
Summary
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. A flaw was found in jackson-databind, a library used for processing data. This vulnerability allows an attacker to bypass security controls designed to validate data types. By sending specially crafted input, an attacker can force the system to process untrusted data, which may lead to the execution of malicious code. This could result in a complete compromise of the affected system, impacting its confidentiality, integrity, and availability. This Important flaw in `jackson-databind` allows for a security bypass, enabling arbitrary code execution. The vulnerability arises from insufficient validation of array component types by `BasicPolymorphicTypeValidator`, which permits deserialization of unallowlisted types when processing untrusted input. This bypass of type validation can lead to a complete system compromise, affecting confidentiality, integrity, and availability in Red Hat products utilizing `jackson-databind` for data processing. Red Hat severity: Important — CVSS 8.1 (CVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:U/C:H/I:H/A:H). Weakness: CWE-184. No fixing RHSA erratum has published yet; monitor the Red Hat CVE page and patch when it ships. Will not fix / out of support: Red Hat build of Debezium 3.
Mitigation checklist
- Upgrade to version 2.18.8, 2.21.4, or 3.1.4 or later to address this vulnerability. If upgrading is not immediately possible, remove BasicPolymorphicTypeValidator.Builder.allowIfSubTypeIsArray() from the application’s ObjectMapper configuration to eliminate the affected deserialization path. Rebuild and restart the application to apply the configuration change. As an additional mitigation, disable polymorphic deserialization of untrusted data where possible by avoiding or removing default typing features such as activateDefaultTyping() or enableDefaultTyping(). When polymorphic deserialization is required, restrict allowed subtypes using a strict whitelist of trusted application packages and avoid broad or permissive type validation rules.
Official advisory · high-confidence parse· fetched 5 hours ago·verify at source
Discussion(0)
No comments yet. Share field notes, upgrade gotchas, or questions — verify against the vendor advisory before acting on community advice.
Sign in to join the discussion.