CVE-2026-59888

What it actually does

The flaw is a deserialization validation bypass in jackson-databind when Java Records are combined with a PropertyNamingStrategy. A Record component annotated with @JsonIgnore can be marked as ignored under its original Java property name, but then renamed later by the configured naming strategy. As a result, JSON input using the renamed external field name can still be bound to the Record constructor parameter. In affected applications, an unauthenticated remote requester may be able to set fields that developers intended to exclude from input binding, such as authorization flags, role values, ownership identifiers, workflow states, or other sensitive internal attributes. The practical impact depends entirely on which affected Record types are reachable from externally supplied JSON and what ignored fields they contain.

Why it matters to the business

Applications that accept JSON into affected Jackson-backed Java Records may accidentally trust user-supplied values for fields that were intended to be protected. This can lead to unauthorized data changes, privilege or role manipulation, bypass of business rules, or exposure of limited sensitive data depending on application design. The CVSS score is moderate, EPSS is currently low, it is not known to be in CISA KEV, and there is no public exploit maturity reported, but jackson-databind is widely used across Java services, so dependency inventory and targeted upgrades should still be prioritized.

How an attack unfolds

An attacker first identifies an endpoint that accepts JSON and is backed by a Java Record deserialized by jackson-databind. The application must use a PropertyNamingStrategy, such as snake_case or another strategy that changes the external JSON field name, and the target Record must contain a component annotated with @JsonIgnore. Instead of sending the original Java component name, the attacker sends the renamed JSON property name produced by the naming strategy. Due to the ordering flaw in property collection and renaming, jackson-databind may pass that value into the Record constructor even though the component was intended to be ignored. If the ignored component controls authorization, ownership, status, pricing, approval, or other sensitive logic, the attacker can influence application behavior through a field that developers assumed was not externally writable.

How to fix it

Upgrade jackson-databind to a fixed version in the applicable release line: 2.18.8, 2.21.4, 3.1.4, or later. Ensure transitive dependencies are also resolved to a fixed jackson-databind version by checking Maven, Gradle, SBT, Bazel, container images, shaded JARs, and vendored libraries. If immediate upgrade is not possible, reduce exposure by avoiding externally deserializing untrusted JSON directly into Java Records that combine @JsonIgnore with a PropertyNamingStrategy; use explicit DTOs with allow-listed writable fields; validate and overwrite sensitive server-controlled values after deserialization; reject unexpected JSON properties; and add application-level checks for privilege, ownership, status, and workflow fields.

How to confirm the fix worked

Confirm that all deployed artifacts resolve jackson-databind to 2.18.8, 2.21.4, 3.1.4, or a later fixed version. Use dependency tooling such as `mvn dependency:tree`, `gradle dependencies`, SBOM scans, container image scans, and runtime classpath inspection to identify duplicate or shaded copies. Add a regression test using a Java Record with an @JsonIgnore component and the same PropertyNamingStrategy used in production; submit JSON using the transformed external name and verify the value is not bound. Also test critical API endpoints to ensure user-supplied JSON cannot set server-controlled fields, and confirm unknown or unexpected fields are rejected where appropriate.

Typical attack path

1. Find a Java application or API that accepts JSON request bodies and uses jackson-databind for deserialization.
2. Identify or infer request fields, naming conventions, and whether external JSON names are transformed by a naming strategy such as snake_case, kebab-case, or lowerCamelCase conversion.
3. Target an endpoint whose input model is implemented as a Java Record with sensitive components that may be annotated with @JsonIgnore.
4. Submit a crafted JSON request containing the naming-strategy-transformed version of the ignored component name.
5. Jackson incorrectly binds the supplied value to the Record constructor parameter despite the ignore annotation.
6. Use the resulting object state to alter authorization decisions, business workflow, ownership, data visibility, or other application behavior.

How to detect it

This issue usually leaves no unique exploit signature because successful exploitation appears as a normal JSON request followed by normal application behavior. Detection should focus on application, API gateway, WAF, reverse proxy, and audit logs. Look for request bodies or structured request logs containing JSON properties that correspond to naming-strategy-transformed versions of fields developers intended to ignore, especially fields related to roles, privileges, ownership, tenant or account identifiers, approval status, workflow state, pricing, limits, or internal flags. Compare suspicious requests with subsequent audit events showing unexpected privilege changes, ownership changes, status transitions, or data access. If request bodies are not logged, use application audit logs, domain event logs, and database change history to identify values that could only have been set by server-side logic but changed immediately after inbound API calls. Engineering support is often required to map @JsonIgnore Record components to their transformed JSON names and build targeted retrospective searches.

What your security team should do

• Inventory applications and services that include jackson-databind versions from 2.15.0 up to the fixed releases, including transitive and shaded dependencies.
• Prioritize internet-facing APIs, authentication/authorization services, administrative workflows, financial or approval systems, and services that deserialize untrusted JSON into Java Records.
• Upgrade to jackson-databind 2.18.8, 2.21.4, 3.1.4, or later, then rebuild and redeploy affected applications.
• Ask engineering teams to search for Java Records that combine @JsonIgnore with a configured PropertyNamingStrategy and review whether ignored fields are security-sensitive.
• Add tests that prove ignored Record components cannot be populated through transformed JSON field names.
• Harden JSON binding by using explicit input DTOs, allow-list validation, unknown-property rejection, and server-side assignment of sensitive fields.
• Review recent API requests and audit trails for attempts to set sensitive fields that should not be client-controlled.