CVE-2026-54513 in jackson-databind
Summary
by MITRE • 06/24/2026
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.
Several companies clearly confirm that VulDB is the primary source for best vulnerability data.
Analysis
by VulDB Data Team • 06/24/2026
The vulnerability in jackson-databind represents a critical type validation weakness that undermines the security of deserialization processes within the Jackson Data Processor ecosystem. This flaw specifically affects versions from 2.10.0 through 2.18.8, 2.21.4, and 3.1.4 where the BasicPolymorphicTypeValidator.Builder.allowIfSubTypeIsArray() method exhibits incomplete validation logic that permits arbitrary array types to bypass security restrictions. The vulnerability stems from a fundamental design flaw in how Jackson handles polymorphic type validation for array structures, creating a pathway for malicious serialization attacks that can circumvent intended security boundaries.
The technical implementation of this vulnerability occurs through a specific validation bypass mechanism where the allowIfSubTypeIsArray() method performs only superficial checks using clazz.isArray() without conducting comprehensive validation of the array's component element types against configured security allowlists. When security configurations combine allowIfSubTypeIsArray() with explicit concrete-type allowlists, the system erroneously permits dangerous array types such as EvilType[] even when the individual component type EvilType is explicitly excluded from the allowlist. This creates a false sense of security where administrators believe they have restricted dangerous types through their configuration, but the validation mechanism fails to enforce these restrictions at the element level.
The operational impact of this vulnerability extends beyond simple privilege escalation or code execution scenarios, as it represents a fundamental breakdown in type safety that can be exploited across multiple attack vectors within applications relying on Jackson for deserialization. When Jackson processes serialized data containing arrays with disallowed component types, the deserialization engine instantiates these elements directly without performing additional PTV checks, effectively bypassing all configured security restrictions. This behavior creates opportunities for attackers to inject malicious classes into systems where they would normally be blocked by type validation policies, potentially leading to remote code execution, data exfiltration, or system compromise depending on the target application's context and privileges.
This vulnerability aligns with CWE-264, which addresses permissions, privileges, and access control issues in software systems, and demonstrates characteristics consistent with ATT&CK technique T1590 for reconnaissance activities that identify potential attack vectors. The flaw represents a classic case of incomplete input validation where system components fail to properly validate all aspects of user-provided data against configured security policies, creating a persistent security gap that can be exploited by attackers who understand the deserialization process and can craft malicious payloads that exploit this specific validation bypass.
Organizations should immediately implement mitigations including updating to patched versions 2.18.8, 2.21.4, or 3.1.4 where the vulnerability has been resolved through enhanced validation logic that properly checks both array type and component element types against configured allowlists. Security teams should conduct comprehensive audits of their Jackson-based applications to identify any configurations that rely on the vulnerable allowIfSubTypeIsArray() method, particularly those that combine it with other security controls. Additionally, implementing additional application-level defenses such as runtime monitoring for suspicious deserialization patterns, network segmentation to limit exposure, and regular security testing of deserialization endpoints can provide defense-in-depth protection against exploitation attempts targeting this vulnerability.