CVE-2026-54515

What it actually does

This flaw can make Jackson deserialize JSON properties that developers explicitly intended to ignore. In affected jackson-databind versions, a contextual deserializer first removes per-property @JsonIgnoreProperties exclusions, but when @JsonFormat(ACCEPT_CASE_INSENSITIVE_PROPERTIES) is also applied, the case-insensitive property map is rebuilt from the original unfiltered property set. The result is that ignored properties can become writable again during JSON binding. The technical effect is an integrity bypass: attacker-supplied JSON may set fields that application code assumed were protected, ignored, server-controlled, or not client-writable.

Why it matters to the business

Applications that accept untrusted JSON may allow users or external callers to modify data they should not be able to change, such as authorization-related fields, workflow state, ownership metadata, pricing flags, approval status, or other server-managed attributes. The severity depends heavily on how affected models are used: in some applications this may be a minor data-validation issue, while in others it could enable privilege escalation, unauthorized state changes, or business logic abuse. This is not currently listed in CISA KEV, has no known mature public exploitation, and has a low EPSS score, but jackson-databind is widely embedded in Java services, so exposure can be broad and difficult to inventory, especially where the library is shaded or bundled inside larger applications.

How an attack unfolds

An attacker identifies an API, message consumer, or service endpoint that deserializes attacker-controlled JSON using an affected jackson-databind version. The targeted Java model must use per-property @JsonIgnoreProperties to exclude one or more fields and also enable case-insensitive property handling with @JsonFormat(ACCEPT_CASE_INSENSITIVE_PROPERTIES). The attacker then sends JSON containing a field that the application developer expected Jackson to ignore. Because the vulnerable deserializer rebuilds the property map incorrectly, that ignored field is restored and bound to the object. Downstream business logic then processes the object as if the value were legitimate. Exploitation is application-specific: the attacker needs to know or infer useful hidden field names, and impact depends on whether those fields influence authorization, ownership, workflow, financial, or other sensitive decisions.

How to fix it

Upgrade jackson-databind to a fixed release line: 2.18.9 or later, 2.21.5 or later, or 3.1.4 or later, depending on the major/minor line in use. Inventory both direct and transitive dependencies, including shaded or vendor-bundled copies of jackson-databind in executable JARs, application servers, SDKs, and internal frameworks. If immediate upgrade is not possible, reduce exposure by avoiding deserialization of untrusted input into sensitive domain objects, removing @JsonFormat(ACCEPT_CASE_INSENSITIVE_PROPERTIES) where it is not required, replacing broad binding with explicit request DTOs, enforcing server-side allow-lists for client-writable fields, and validating or overwriting sensitive fields after deserialization. Do not rely on @JsonIgnoreProperties alone as a security boundary until fixed versions are deployed.

How to confirm the fix worked

Confirm the deployed application resolves jackson-databind to a fixed version using build tooling such as Maven dependency:tree, Gradle dependencies, SBOM scans, container image scans, and inspection of packaged JARs. Check for shaded copies by searching built artifacts for Jackson package metadata and jackson-databind manifests. Add a regression test for any model that combines @JsonIgnoreProperties with @JsonFormat(ACCEPT_CASE_INSENSITIVE_PROPERTIES): submit JSON containing an ignored property and verify the field is not populated after deserialization. Validate at runtime by confirming application startup logs, dependency telemetry, or software composition analysis show jackson-databind at 2.18.9+, 2.21.5+, or 3.1.4+ as applicable. Also test representative API requests to ensure protected fields remain server-controlled and cannot be set through JSON input.

Typical attack path

1. Find a Java application endpoint, API, queue consumer, or file import path that accepts JSON from an untrusted caller.
2. Infer or discover the structure of the target JSON model, including fields that may be intentionally ignored or server-controlled.
3. Identify behavior consistent with case-insensitive Jackson deserialization, such as accepting differently cased JSON property names.
4. Submit a crafted JSON payload containing a normally ignored property, potentially using exact-case or case-varied property names.
5. Trigger Jackson deserialization on an affected jackson-databind version where the ignored property is incorrectly restored as writable.
6. Rely on downstream application logic to persist, authorize, route, or act on the attacker-controlled value.
7. Abuse the resulting state change, such as unauthorized modification of protected attributes or bypass of intended business rules.

How to detect it

There are no universal network or host indicators for exploitation because successful abuse depends on application-specific model fields and business logic. To investigate possible prior exploitation, first identify endpoints or message consumers that deserialize untrusted JSON with affected jackson-databind versions and models combining @JsonIgnoreProperties with case-insensitive property handling. Review HTTP access logs, API gateway logs, WAF logs, request body logs where available, application audit logs, and message broker payload archives for requests containing fields that should be ignored or server-controlled. Pay special attention to case variations of sensitive property names and to requests followed by unexpected changes in authorization, ownership, workflow status, approvals, pricing, or other protected state. Compare historical object-change audit trails against allowed update paths to find fields modified by clients despite being intended as server-managed. If request bodies are not logged, use application audit records, database change history, and business event logs to identify anomalous updates that occurred through JSON ingestion paths. For future detection, add structured logging or validation alerts when inbound JSON contains disallowed properties, and create application-specific SIEM rules for sensitive field names that should not appear in client-supplied payloads.

What your security team should do

• Prioritize inventory of internet-facing Java services and high-risk internal services that accept JSON from users, partners, queues, webhooks, or file imports.
• Upgrade affected jackson-databind deployments to 2.18.9+, 2.21.5+, or 3.1.4+ according to the release line in use.
• Search code for the combination of @JsonIgnoreProperties and @JsonFormat(ACCEPT_CASE_INSENSITIVE_PROPERTIES), especially on request models, nested objects, and DTOs used with untrusted input.
• Review sensitive models for fields that should never be client-writable, such as role, permission, status, owner, account, approval, price, tenant, administrative, or workflow-control attributes.
• Add negative deserialization tests proving ignored properties remain ignored, including case-variant property names.
• Where upgrades are delayed, disable case-insensitive property binding for affected models or introduce explicit allow-list request DTOs and post-deserialization validation.
• Review recent application and audit logs for unexpected changes to server-controlled fields that correlate with inbound JSON requests.
• Update SCA, SBOM, and CI dependency policies so future builds fail or alert when affected jackson-databind versions are introduced.