jackson-databind EUVD-2026-38589

Exploitation requires three simultaneous application-level conditions: (1) the target class uses a @JsonCreator constructor, which activates the property-based deserialization path in BeanDeserializer._deserializeUsingPropertyBased; (2) the class contains at least one setterless Collection or Map property - a field with no setter, only a getter returning a mutable collection - annotated with a @JsonView that restricts it to a more-privileged view (e.g., AdminView); and (3) the application invokes the ObjectMapper with a less-privileged active view (e.g., readerWithView(PublicView.class)) and relies on that view filter to prevent the restricted field from being written. The CVSS PR:N vector indicates no jackson-databind-level authentication is required, but real-world exploitation depends on the attacker being able to reach the deserialization endpoint and supply arbitrary JSON content. Exploitation is not possible if: the target class has no @JsonCreator constructor; no setterless collection or map fields carry @JsonView security restrictions; or the application enforces access control outside of @JsonView (e.g., explicit field whitelisting, DTO separation, service-layer authorization). The vulnerability does not affect standard setter-based properties or classes without @JsonCreator.

CVSS 3.1 rates this 5.3 Medium with AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:L/A:N, but the AC:L rating warrants scrutiny: exploitation requires the simultaneous presence of a @JsonCreator constructor, at least one setterless Collection/Map property, and application reliance on @JsonView for security enforcement - a specific combination that is common in layered REST APIs but not universal. The CVSS I:L designation understates impact for applications where @JsonView is the primary authorization boundary on mutable fields, since the bypass is complete for any property routed through the unguarded path. No public exploit code exists and CISA KEV does not list this CVE, indicating no confirmed mass exploitation. EPSS data was not supplied; given the narrow exploitation preconditions, automated widespread exploitation is assessed as unlikely. For applications not using @JsonView as a security control, risk is effectively zero - the vulnerability has no RCE, no DoS, and no confidentiality impact. The realistic priority is highest for services where role, permission, or privilege fields are setterless collections gated by view annotations, especially where client-supplied JSON reaches the deserializer without prior field filtering.

An attacker targets a REST endpoint that deserializes client-supplied JSON into a class with a @JsonCreator constructor, where a roles or permissions field is a setterless List annotated @JsonView(AdminView.class) and the endpoint operates under PublicView. By submitting JSON containing "roles":["admin"] - particularly placing it before the creator property to force the buffering path - the attacker's value is written into the roles collection despite the PublicView restriction, achieving unauthorized privilege escalation within the deserialized object. The in-tree regression test SetterlessViewBypass5969Test.java (added in the fix commit) demonstrates this exact sequence, covering both field-ordering variants (roles before and after the creator property).