jackson-databind EUVD-2026-43957

Four conditions must all be true simultaneously for exploitation: (1) The application uses jackson-databind in the affected version range (2.15.0-2.18.7, or 2.19.x-2.21.3, or 3.0.x-3.1.3). (2) The deserialization target is a Java Record type - not a regular POJO class; the POJO code path is explicitly confirmed safe in the PR test suite. (3) The Record or its ObjectMapper is configured with a PropertyNamingStrategy (e.g., SnakeCaseStrategy, KebabCaseStrategy) that renames at least one component. (4) At least one Record component subject to that renaming is annotated with @JsonIgnore. The combination of conditions 2-4 is uncommon in older codebases that predate Java 16, but increasingly present in modern Spring Boot 3.x and Quarkus applications that adopt Records for immutable DTOs. Exploitation is limited to the fields actually annotated @JsonIgnore; non-ignored fields are unaffected. There is no required authentication barrier on the attacker's side - any entity that can submit JSON to a vulnerable deserialization endpoint can attempt the bypass.

The CVSS 3.1 vector (AV:N/AC:L/PR:N/UI:N/S:U/C:L/I:L/A:N, score 6.5) assigns low complexity and no authentication, which is accurate from the attacker's perspective - crafting a JSON payload with a renamed field requires no special tooling or privilege. However, the real-world exploitability is meaningfully constrained by four simultaneous code-level prerequisites (see exploitation_conditions), which substantially reduce the population of vulnerable endpoints. No EPSS value was provided in the input, so exploitation probability cannot be quantified. The vulnerability is not listed in the CISA KEV catalog, and no dedicated public exploit tool has been identified, though the PR test suite constitutes a functional proof of concept. The integrity signal is worth highlighting: the canonical example in the PR test injects the string 'ADMIN' into an 'internalRole' Record field that was explicitly marked @JsonIgnore - in applications where such fields gate authorization decisions, the practical impact escalates well beyond what the 'I:L' base metric suggests. Security teams should treat this as medium-priority with elevated urgency for any Java service that (a) deserializes external JSON into Records, (b) applies a naming strategy, and (c) uses @JsonIgnore to exclude privilege- or security-relevant fields.

An attacker submits a POST request containing JSON payload '{"username":"alice","internal_role":"ADMIN"}' to a REST endpoint that deserializes the body into a Java Record annotated with @JsonNaming(SnakeCaseStrategy.class), where the 'internalRole' component is marked @JsonIgnore. The application's authorization logic subsequently reads 'internalRole' from the deserialized Record object and grants elevated privileges, believing the field cannot be externally supplied. The upstream PR test (RecordIgnoreNamingStrategy5974Test.testRenamedIgnoredRecordComponentBypass) demonstrates this exact flow and constitutes a functional proof of concept.