CVE-2026-59888: Jackson Record @JsonIgnore Bypass via Naming Strategy

On July 14, 2026, a Medium-severity vulnerability in Jackson's jackson-databind library, CVE-2026-59888, was disclosed via GitHub Security Advisory GHSA-3pjw-73gf-8qr5, reported by Omkhar Arasaratnam. GitHub's CNA scored it 6.5 (CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:L/I:L/A:N). The flaw (CWE-915) affects Java Records deserialized with a PropertyNamingStrategy: jackson-databind records an @JsonIgnore'd component under its original name before the naming strategy renames it, so the renamed JSON key slips past the ignore check and is assigned to the Record's constructor parameter. Affected ranges are 2.15.0 through 2.18.7, 2.19.0 through 2.21.3, and 3.0.0 through 3.1.3, with fixes in 2.18.8, 2.21.4, and 3.1.4.

Affected and unsupported? See NES for Jackson.

‍

What is CVE-2026-59888?

CVE-2026-59888 is an improperly controlled modification of object attributes (CWE-915, with related CWE-345, insufficient verification of data authenticity) in jackson-databind's property introspection for Java Records. In practical terms, it is a mass-assignment bypass.

The affected component is POJOPropertiesCollector, the class that decides which JSON keys map to which properties during data binding. When a Record class uses a PropertyNamingStrategy (for example SNAKE_CASE, a default in many Spring configurations) and marks a component with @JsonIgnore, the collector builds its ignore list from the component's original Java name rather than the renamed JSON key. The result: JSON input using the renamed key is never matched against the ignore list, and the value is bound straight into the Record's constructor.

A developer who marked a component @JsonIgnore to keep it out of client control has not actually kept it out of client control.

‍

Severity and exploit conditions

GitHub's CNA assessment is the authoritative score at time of writing; NVD lists the CVE as Awaiting Analysis. Worth noting for anyone reconciling sources: the advisory itself records a split assessment, with the maintainer rating the issue minor and the reporter rating it Moderate. The scored vector lands at 6.5 Medium.

The real-world severity depends heavily on what the ignored component does. Three preconditions must all hold:

1. The application deserializes untrusted JSON into Java Records.
2. A PropertyNamingStrategy is applied, via ObjectMapper configuration or annotation.
3. The Record relies on @JsonIgnore to keep an internal or privileged component out of deserialization.

If the ignored component is a role flag, a tenant identifier, or an internal state marker, a Low integrity score understates the business impact.

‍

Exploitation status

There is no public proof of concept beyond the mechanism explanation in the upstream advisory, CVE-2026-59888 is not listed in CISA's Known Exploited Vulnerabilities catalog, and no active exploitation has been reported. The attack itself is trivial once the preconditions exist: the attacker simply includes the renamed key (for example is_admin for a component named isAdmin under SNAKE_CASE) in a JSON body they already control. There is no memory corruption, gadget chain, or timing element involved.

‍

Root cause

The bug is an ordering problem inside POJOPropertiesCollector. During property collection, _removeUnwantedIgnorals() runs first and records the ignored component in _ignorableProps under its original implicit name. Only afterwards does _renameUsing() apply the configured naming strategy to the property set. The ignore list is now stale: it holds the Java-side name while the wire format uses the renamed key.

At binding time, IgnorePropertiesUtil.shouldIgnore() checks the incoming renamed key against that stale list, finds no match, and lets the value through to the Record's canonical constructor. Records make this worse than it would be for classic POJOs, because Record components are bound through constructor parameters and there is no setter layer where a second check might catch the value.

The fixes (commit c7c6783 on the 2.x line, baa2cdf on 3.x) reconcile the ignorals against post-rename property names so the renamed key is correctly rejected.

‍

What an attacker can do

• Set any @JsonIgnore'd Record component from the wire by sending its naming-strategy-renamed key in a JSON request body.
• Escalate privileges where the ignored component gates authorization, for example a role, isAdmin, or accountType component the application populates server-side and assumed clients could never write.
• Tamper with internal bookkeeping fields such as tenant IDs, ownership references, audit flags, or workflow state markers that were excluded from binding by annotation rather than by DTO design.
• Bypass validation logic that assumed the ignored component always holds its default value after deserialization.

What an attacker cannot do: execute code, read arbitrary memory, or reach fields on classes that do not meet the Record-plus-naming-strategy preconditions. This is a targeted integrity flaw, not an RCE-class deserialization bug like the PolymorphicTypeValidator bypasses disclosed earlier this year.

‍

Who is affected?

The vulnerability was introduced in jackson-databind 2.15.0, so older lines are not affected. Spring Boot 2.7, which manages Jackson 2.13.5, is not exposed to this CVE. The exposure concentrates in the middle of the 2.x range and in 3.x prior to 3.1.4.

That last row is where most real-world exposure sits. Per the Spring Boot support timeline, OSS support for Spring Boot 3.1 ended June 30, 2024, 3.2 ended December 31, 2024, 3.3 ended June 30, 2025, and 3.4 ended December 31, 2025. Those lines manage jackson-databind 2.15.4, 2.15.4, 2.17.3, and 2.18.5 respectively, all inside the affected range, and none of them will ever ship a dependency bump. Spring Boot 3.5.16 already manages the fixed 2.21.4, so maintained Boot lines are covered.

‍

Mitigation guidance

Overriding the jackson-bom.version property on an EOL Spring Boot line is technically possible, but it leaves the rest of the EOL platform unpatched and shifts compatibility risk onto your team. If you are running Spring Boot 3.1 through 3.4 in production, this CVE is one entry in a growing list of vulnerabilities those lines will never receive fixes for, and a supported remediation path for the whole stack is the more durable answer.

‍

Related CVEs

Jackson has had an active disclosure year. If you are triaging CVE-2026-59888, check your exposure to these siblings as well:

• CVE-2026-54512 and CVE-2026-54513: two High-severity PolymorphicTypeValidator bypasses in jackson-databind that undermine its core deserialization safety mechanism.
• CVE-2025-52999: a Denial of Service via stack overflow in jackson-core, covered in our earlier analysis.
• CVE-2026-41855: a Spring Framework JMS flaw with a Jackson deserialization component, relevant if your Jackson exposure comes through Spring messaging.

‍

Taking action

Audit your dependency tree for jackson-databind between 2.15.0 and 2.18.7, 2.19.0 and 2.21.3, or 3.0.0 and 3.1.3. Then check whether any deserialization target is a Java Record that combines a PropertyNamingStrategy with @JsonIgnore on a component you would not want a client to write. If both are true, treat the affected endpoints as accepting attacker-controlled values in those components until you patch.

Teams on maintained lines should upgrade to 2.18.8, 2.21.4, or 3.1.4 now. Teams pinned by an OSS-EOL Spring Boot release or a frozen enterprise dependency tree do not have a clean upstream path: the Boot lines managing affected Jackson versions reached end of OSS life between June 2024 and December 2025 and will not ship the fix. NES for Jackson delivers the remediation as a drop-in replacement, so you close CVE-2026-59888 and its siblings without a forced migration.