jackson-databind CVE-2026-54516

Exploitation requires three concurrent conditions: (1) The target application uses jackson-databind 2.21.0-2.21.3 or 3.0.0-3.1.3 to deserialize user-controlled JSON input. (2) A POJO in the deserialization path must have a getter annotated with @JsonProperty('someRenamedName') paired with a setter annotated with @JsonIgnore on the same property - this is the specific read-only-over-the-wire annotation pattern. (3) MapperFeature.INFER_PROPERTY_MUTATORS must be enabled, which is the default configuration; no deliberate opt-in is required unless the application has explicitly disabled it. What limits exploitation: if none of the application's POJOs use this exact annotation combination, the vulnerability is not triggerable regardless of library version; if the affected POJOs back fields that carry no security-sensitive data, impact is negligible; applications that have explicitly disabled INFER_PROPERTY_MUTATORS are not affected. Authentication requirements depend entirely on whether the consuming endpoint requires authentication at the application layer - the vulnerability itself operates post-deserialization and imposes no authentication prerequisite (CVSS PR:N).

The provided CVSS 3.1 vector (AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:L/A:N, score 5.3 Medium) accurately reflects the network-reachable, zero-privilege nature of the attack surface but is contingent on an application-level prerequisite: the target POJO must use the specific @JsonProperty-on-getter plus @JsonIgnore-on-setter annotation combination. This is not a default or universal configuration - it is a deliberate developer pattern - so real-world exploitability is narrower than the CVSS AC:L suggests for a generic endpoint. No EPSS score was provided in the source data; given the non-universal prerequisite and absence of active exploitation signals, real-world exploitation probability is likely low at time of analysis. The vulnerability is NOT in the CISA KEV catalog and no standalone proof-of-concept exploit has been identified - only fix commits and regression test cases are publicly available. The maintainer's own characterization ('minor') aligns with the bounded impact: no RCE, no confidentiality loss, no general gadget chain - only targeted field-value tampering in applications that happen to use the affected annotation pattern. The reporter's HIGH assessment likely reflects worst-case scenarios where the bypassed field controls security-sensitive state (e.g., admin flags, ACL values). Organizations should assess whether their POJOs use this annotation pattern and whether any bypassed fields carry security significance.

An attacker targeting a Java application with a REST endpoint that deserializes user-supplied JSON into a POJO - where that POJO uses @JsonProperty('renamedProp') on a getter and @JsonIgnore on the setter to expose a field as serialization-only - submits a crafted POST body containing the key 'renamedProp' with an attacker-chosen value. Jackson's _renameProperties() retains the private backing field as writable, causing BeanDeserializerFactory to build a FieldProperty and write the attacker's value directly into the private field, bypassing the developer's intended read-only enforcement. No proof-of-concept exploit code has been identified; however, the fix commits include regression tests that effectively document the triggering conditions.