EOL Fix Available | CVE-2026-59888

Overview

jackson-databind is the general-purpose data-binding package of the FasterXML Jackson suite. It provides full data-binding (object serialization and deserialization) on top of the Jackson streaming parser/generator (jackson-core) and the Jackson annotations (jackson-annotations), and is one of the most widely used JSON libraries for Java.

An authorization bypass vulnerability (CVE-2026-59888) has been identified in jackson-databind, which allows attackers to set a Java record component that a developer intended to be ignored over the wire. When a record component is annotated with @JsonIgnore and a PropertyNamingStrategy renames that component, the ignore is recorded under the component's original name but never re-applied to the renamed name, so attacker-supplied JSON that uses the renamed key is bound to the record's canonical-constructor parameter and defeats the @JsonIgnore.

Per OWASP: the product receives input from an upstream component that specifies multiple attributes, properties, or fields that are to be initialized or updated in an object, but it does not properly control which attributes can be modified.

This issue affects multiple versions of Jackson beginning with 2.15.0, including the End-of-Life 2.15.x line; the earlier 2.13.x and 2.14.x lines are not affected.

‍

Details

Module Info

Product: jackson-databind
Affected packages: com.fasterxml.jackson.core:jackson-databind
Affected versions: >=2.15.0 <2.18.8, >=2.19.0 <2.21.4
GitHub repository: https://github.com/FasterXML/jackson-databind
Published packages: https://central.sonatype.com/artifact/com.fasterxml.jackson.core/jackson-databind
Package manager: Maven
Fixed in: NES for Jackson 2.15.7

Vulnerability Info

This High-severity vulnerability is found in the com.fasterxml.jackson.core:jackson-databind package in jackson-databind 2.15.0 and later. It affects Java records whose components are ignored with @JsonIgnore while a property naming strategy is in effect. Records deserialize through their canonical constructor, so every constructor parameter must survive introspection for the record to be instantiated. That constraint interacts badly with the property rename step and allows an ignored component to be written from untrusted input.

Consider a record such as the following:

@JsonNaming(PropertyNamingStrategies.SnakeCaseStrategy.class)
public record User(
        String username,
        @JsonIgnore String internalRole) {
}

The developer's intent is that internalRole can be serialized out but never populated from incoming JSON. During introspection, POJOPropertiesCollector._removeUnwantedProperties() cannot drop the ignored component the way it would for a plain POJO, because the record still needs that constructor parameter to be instantiated. Instead it keeps the parameter and records only the component's original implicit name as ignored:

if (prop.anyIgnorals()) {
    // Special handling for Records: constructor parameters are needed for instantiation
    if (isRecordType()) {
        prop.removeIgnored();
        _collectIgnorals(prop.getName());   // records the original implicit name only
        continue;
    }
    ...
}

The naming strategy then renames that surviving property in _renameUsing(), but the renamed name is never added to the ignore set:

if ((rename != null) && !fullName.hasSimpleName(rename)) {
    prop = prop.withSimpleName(rename);   // renamed key is not added to the ignore set
    simpleName = rename;
}

Because the ignore set still holds only internalRole and not its snake_case rename, the renamed key is treated as a bindable creator property. Attacker-supplied JSON of the form {"username":"alice","internal_role":"admin"} passes internal_role straight to the record's canonical constructor, defeating the @JsonIgnore the developer placed on the component. No special configuration is required, since the exploit fires with a default ObjectMapper and an endpoint only needs to deserialize such a record. A plain, non-record POJO is not affected, because the ignored property is removed entirely before the renaming, so the renamed key would merely be an unknown property.

This vulnerability was introduced in 2023 with jackson-databind 2.15.

‍

Mitigation

Only recent versions of Jackson are community-supported. The affected 2.15.x line is End-of-Life and will not receive public updates to address this issue. There is no publicly available fix for this line; NES for Jackson is the remedy.

Users of the affected components should apply one of the following mitigations:

Upgrade jackson-databind to a currently supported 2.x release that contains the fix, such as 2.18.8 or later.
Leverage a commercial support partner like HeroDevs for post-EOL security support.

‍