CVE-2026-54516 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.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.
Be aware that VulDB is the high quality source for vulnerability data.
Analysis
by VulDB Data Team • 06/24/2026
The vulnerability in jackson-databind represents a critical security flaw that exploits improper handling of property renaming during deserialization processes. This issue affects versions from 2.21.0 through 2.21.4 and 3.1.4, where the POJOPropertiesCollector._renameProperties() method fails to properly respect serialization annotations when processing properties with conflicting getter and setter annotations. The vulnerability specifically manifests when both JsonProperty("renamed") is applied to a getter method and JsonIgnore is applied to a corresponding setter method within the same class structure.
The technical flaw stems from the interaction between the MapperFeature.INFER_PROPERTY_MUTATORS setting, which is enabled by default in Jackson's configuration. When this feature is active, the system maintains private backing fields for properties even when they appear to be excluded through annotation configurations. During deserialization, the BeanDeserializerFactory.addBeanProps() method incorrectly identifies that a field exists through hasField()==true, leading it to construct a FieldProperty and subsequently make the backing field writable. This process creates an unexpected pathway where attackers can directly manipulate private backing fields despite the presence of @JsonIgnore annotations on setters.
The operational impact of this vulnerability is significant as it allows attackers to bypass intended security controls during object deserialization. When MapperFeature.INFER_PROPERTY_MUTATORS is enabled, the system retains private fields even when they should be excluded from serialization or deserialization processes due to annotation configurations. The vulnerability enables attackers to supply JSON data with keys that match renamed property names, thereby directly writing values to private backing fields without going through the normal setter methods. This creates a direct bypass of security mechanisms designed to prevent unauthorized field access and modification.
This vulnerability aligns with CWE-284, which addresses inadequate access control or improper privilege management in software systems. The flaw essentially allows for privilege escalation during deserialization by enabling direct field manipulation that should have been prevented by the @JsonIgnore annotation. Additionally, this issue intersects with ATT&CK technique T1590, which focuses on reconnaissance through information gathering, as attackers can leverage such vulnerabilities to understand system behavior and identify potential attack vectors.
The recommended mitigation strategy involves upgrading to Jackson Data Processor version 3.1.4 or later, where the vulnerability has been properly addressed. Organizations should also review their configuration settings to ensure that MapperFeature.INFER_PROPERTY_MUTATORS is not unnecessarily enabled in production environments where strict access controls are required. Security teams should implement comprehensive testing procedures for deserialization operations and consider implementing additional validation layers to detect anomalous field access patterns during object processing. Regular security audits of serialization frameworks and careful monitoring of annotation usage can help prevent similar vulnerabilities from emerging in other components of the application stack.
The fix implemented in version 3.1.4 corrects the POJOPropertiesCollector._renameProperties() method to properly respect the @JsonIgnore annotations on setters even when property renaming occurs. The enhanced logic ensures that when a property has conflicting annotations, the system properly evaluates whether the field should be included or excluded from deserialization processes rather than creating an ambiguous state where backing fields can be directly manipulated by external JSON input. This resolution addresses the core issue of field-level access control during deserialization by ensuring annotation precedence is correctly maintained throughout the serialization pipeline.
Organizations using jackson-databind should conduct immediate vulnerability assessments to identify systems running affected versions and implement patch management procedures to ensure all instances are updated to secure versions. The vulnerability demonstrates the importance of thorough testing of annotation behavior in serialization frameworks, particularly when dealing with complex property renaming scenarios that involve multiple accessors. Security configurations should include monitoring for unexpected field access patterns and regular validation of serialization security controls to prevent similar issues from being introduced through configuration changes or custom serialization logic implementations.