CVE-2026-59889: @JsonView Bypass for @JsonUnwrapped Properties during Deserialization in jackson-databind

FasterXML jackson-databind is the default and most widely utilized data-binding and serialization library within the Java ecosystem, heavily integrated into framework structures such as Spring Boot, Quarkus, and Micronaut. In web services, incoming HTTP request payloads are typically processed using Jackson's tree-model or bean deserializers to bind JSON properties directly onto Java classes. To prevent unauthorized clients from updating sensitive parameters, developers leverage Jackson's @JsonView annotations to dynamically constrain the incoming data fields based on context-specific authorization views (e.g., allowing general users to mutate only standard profile fields while reserving configuration fields for administrative views).

However, a severe logical bypass (tracked as CVE-2026-59889 or GHSA-5gvw-p9qm-jgwh) was identified in the deserialization handling of unwrapped properties. The vulnerability resides specifically within the interaction between @JsonView and the @JsonUnwrapped annotation, which signals to Jackson that a nested object should be flattened and mapped directly alongside parent-level keys in the input payload. During the parsing stage, jackson-databind fails to execute validation constraints on the nested fields if the unwrapped container itself is marked with an active, restrictive view.

This security-sensitive incorrect authorization flaw (CWE-863) allows an authenticated attacker to inject arbitrary administrative fields into flattened JSON payloads. Because the deserialization layer fails to enforce the configured view filters during the processing of unwrapped properties, downstream applications process these malicious, privileged fields as authenticated modifications. The result is a classic parameter injection or Mass Assignment vulnerability, allowing unauthorized status modifications, privilege escalations, or state corruptions depending on the design of the target enterprise bean.

To comprehend the root cause of CVE-2026-59889, it is necessary to examine how the Jackson parsing engine handles deferred properties versus standard properties. During standard bean deserialization, Jackson processes properties sequentially, validating each field against the deserializer's configured active view. When a property is encountered, the deserializer invokes SettableBeanProperty.visibleInView(activeView) before attempting to bind the token value, thereby discarding elements that are not designated for the active view context.

This predictable flow is disrupted when the parser encounters a field decorated with @JsonUnwrapped. Because unwrapped properties are structurally flattened into the parent JSON object rather than nested within their own distinct block, Jackson cannot deserialize them inline. To resolve this structural discrepancy, the parser must read the incoming tokens, buffer them using a TokenBuffer instance, and deferredly process the unwrapped container object after the main bean context has been established.

The logic responsible for orchestrating this deferred replay sequence is defined in the class com.fasterxml.jackson.databind.deser.impl.UnwrappedPropertyHandler within its core method processUnwrapped(). In vulnerable releases of jackson-databind, the implementation of processUnwrapped() looped over the collection of properties associated with the unwrapped container and immediately invoked prop.deserializeAndSet(p, ctxt, bean) on each element using the replayed parser context. Crucially, the engine proceeded to parse and set these values without applying any view validation checks.

Because the code omitted calls to prop.visibleInView(ctxt.getActiveView()) inside this specific replay loop, the active deserialization view constraint was entirely bypassed. If an attacker transmitted a JSON payload containing properties that belonged exclusively to an elevated view, the unwrapped handler read them from the buffer and bound them to the target instance anyway. This omission created a direct pathway for unauthorized property modifications because the logical separation between public-facing and administrative-only properties was completely ignored during token playback.

A close inspection of the vulnerable implementation of UnwrappedPropertyHandler.processUnwrapped() highlights the precise code-level omission. The loop responsible for reconstructing the unwrapped object was constructed to prioritize speed and structural reconstruction, neglecting authorization-state checks. As shown below, the original logic proceeded to deserialize the parsed stream elements immediately:

// Vulnerable logic in UnwrappedPropertyHandler.processUnwrapped
public Object processUnwrapped(JsonParser originalParser, DeserializationContext ctxt,
        Object bean, TokenBuffer buffered)
    throws IOException
{
    for (int i = 0, len = _properties.size(); i < len; ++i) {
        SettableBeanProperty prop = _properties.get(i);
        JsonParser p = buffered.asParser(originalParser.streamReadConstraints());
        p.nextToken();
        prop.deserializeAndSet(p, ctxt, bean);
    }
    // ...
}

The fix, introduced by developer PJ Fanning under commit d627a8a86fcb062429282f79f3f256f181ed2c7b, resolved this omission by extracting the active view from the deserialization context and inserting an explicit validation gate before token replay occurs. The modified code sequence is structured as follows:

// Patched logic in UnwrappedPropertyHandler.processUnwrapped
@@ -56,8 +56,14 @@ public Object processUnwrapped(JsonParser originalParser, DeserializationContext
             Object bean, TokenBuffer buffered)
         throws IOException
     {
+        // [databind#6060]: honor active @JsonView -- skip Field/Setter properties not
+        // visible in the active view rather than populating them from buffered input.
+        final Class<?> activeView = ctxt.getActiveView();
         for (int i = 0, len = _properties.size(); i < len; ++i) {
             SettableBeanProperty prop = _properties.get(i);
+            if ((activeView != null) && !prop.visibleInView(activeView)) {
+                continue;
+            }
             JsonParser p = buffered.asParser(originalParser.streamReadConstraints());
             p.nextToken();
             prop.deserializeAndSet(p, ctxt, bean);

This defensive gate successfully remediates the vulnerability. By validating the property's visibility against the active view (prop.visibleInView(activeView)) inside the loop, the handler now correctly skips unauthorized fields, ensuring they are ignored during the replay phase. While this fix provides complete logical parity with standard property parsing, security teams must note that the validation remains dependent on developers correctly configuring and applying @JsonView annotations across their data models; any omission in the schema design still leaves fields exposed.

To exploit CVE-2026-59889, an attacker must identify an application endpoint that relies on jackson-databind for deserializing a JSON payload into an object containing a @JsonUnwrapped container, where specific nested fields are restricted via @JsonView. The attacker does not require high-level administrative privileges; they only require the ability to interact with a public-facing or low-privilege endpoint that accepts incoming JSON payloads, such as a registration or profile update route.

The attack vector exploits the flattening behavior of @JsonUnwrapped. In a normal interaction, the client submits a JSON structure containing only public fields. In an attack scenario, the threat actor craftily appends restricted administrative fields alongside the standard parameters at the root level of the JSON payload. An example payload structure is illustrated below:

{
  "email": "attacker@example.com",
  "password": "P@ssword123",
  "role": "ADMIN",
  "approved": true,
  "creditBalance": 1000000
}

When this payload is submitted to the server, the application's controller initializes Jackson's ObjectReader configured to enforce PublicView.class. The deserializer parses email and password correctly. However, when it encounters the unwrapped fields (role, approved, creditBalance), it fails to discard them immediately. Instead, it places them in the token buffer. When processUnwrapped() is reached, the handler reads these elevated values from the buffer, bypasses the view restrictions entirely, and sets them directly on the backend bean. The resulting server-side object represents an unauthorized state escalation, granting the attacker administrative capabilities.

The security impact of CVE-2026-59889 is defined primarily by the context of the downstream application using the vulnerable library. Because the library fails to restrict incoming data fields based on configured authorization boundaries, the vulnerability results in a classic Mass Assignment or Parameter Binding bypass. If an application delegates access control decisions to fields stored within an unwrapped container (such as roles, account statuses, permissions, or system flags), an attacker can achieve complete privilege escalation within the context of that application.

The Common Vulnerability Scoring System (CVSS) v3.1 base score is assessed at 6.5 (Medium Severity). The vulnerability vector is defined as CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:N/I:H/A:N. The low attack complexity, network accessibility, and lack of required user interaction make this flaw highly reliable to exploit once a vulnerable endpoint is identified. However, because the vulnerability modifies application state (Integrity: High) without directly exposing existing backend data (Confidentiality: None) or disrupting application uptime (Availability: None), the overall impact metrics are constrained to Integrity compromise.

While this vulnerability presents a significant threat to internal business logic, its exploitation is highly context-dependent, meaning an attacker must explicitly understand the targeted application's class definitions and JSON properties to construct a viable exploit. This specificity is reflected in its current low EPSS score (0.00416, representing a 0.42% probability of wild exploitation in the next 30 days) and its absence from CISA's Known Exploited Vulnerabilities (KEV) list. Nevertheless, for organizations utilizing microservices architecture with rich, flattened domain models, this bypass represents a direct failure of validation boundaries.

Remediating CVE-2026-59889 requires a defense-in-depth approach, combining immediate library updates with robust architectural patterns. The primary and most direct remediation path is upgrading the jackson-databind dependency to a patched version. Development teams should systematically verify their dependency trees and update to versions 2.18.9, 2.21.5, 2.22.1, 3.1.5, or 3.2.1 depending on their current major release track.

For enterprise environments where immediate third-party dependency updates are constrained by change management policies, structural workarounds should be deployed to eliminate the reliance on client-side view filtering. The most effective architectural pattern to mitigate this class of vulnerability is the separation of public-facing Data Transfer Objects (DTOs) from internal domain entities. Instead of deserializing client payloads directly into rich domain classes and attempting to sanitize fields using @JsonView, applications should deserialize inputs into highly restricted, public-only DTOs that lack any administrative fields entirely.

// Recommended DTO pattern separating public inputs from domain models
public class RegistrationRequest {
    public String email;
    public String password;
    // No administrative or unwrapped flags are present in this object schema
}

Once the input is validated and bound to the restricted DTO, developers should explicitly copy allowed values onto the database entity or domain model within the service layer. By decoupling the API request representation from the database schema, organizations completely remove the mass assignment attack vector. In addition, organizations should leverage Static Application Security Testing (SAST) tools to flag any concurrent usage of @JsonUnwrapped and @JsonView on sensitive fields, forcing code reviewers to audit the associated authorization models before deployment.