DEV Community

CVE Reports
CVE Reports

Posted on • Originally published at cvereports.com

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

#security #cve #cybersecurity

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

Vulnerability ID: CVE-2026-59889
CVSS Score: 6.5
Published: 2026-07-21

An authorization bypass vulnerability exists in FasterXML jackson-databind versions 2.18.x up to 2.18.8 (and other release branches) where the active @JsonView constraint is bypassed during the deserialization of properties marked with @JsonUnwrapped. This allows remote, authenticated attackers to alter restricted administrative properties on server-side objects by injecting flattened parameters into standard JSON payloads.

TL;DR

A lack of active view validation in jackson-databind's UnwrappedPropertyHandler allows attackers to bypass @JsonView restrictions on @JsonUnwrapped properties, enabling mass assignment vulnerabilities.

⚠️ Exploit Status: POC

Technical Details

  • CWE ID: CWE-863 (Incorrect Authorization)
  • Attack Vector: Network (AV:N)
  • CVSS Severity: 6.5 Medium
  • EPSS Score: 0.00416
  • Impact: Integrity: High (I:H)
  • Exploit Status: poc
  • KEV Status: Not listed in CISA KEV

Affected Systems

  • FasterXML jackson-databind
  • jackson-databind: >= 2.18.0, < 2.18.9 (Fixed in: 2.18.9)
  • jackson-databind: >= 2.21.0, < 2.21.5 (Fixed in: 2.21.5)
  • jackson-databind: >= 2.22.0, < 2.22.1 (Fixed in: 2.22.1)
  • jackson-databind: >= 3.0.0, < 3.1.5 (Fixed in: 3.1.5)
  • jackson-databind: >= 3.2.0, < 3.2.1 (Fixed in: 3.2.1)

Code Analysis

Commit: d627a8a

Fix #6060 -- @JsonView skipped for Setter/Field properties with @JsonUnwrapped -- (for 2.18 and above) (#6056)

@@ -56,8 +56,14 @@ public Object processUnwrapped(JsonParser originalParser, DeserializationContext
             Object bean, TokenBuffer buffered)
         throws IOException
     {
+        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);
Enter fullscreen mode Exit fullscreen mode

Exploit Details

  • GitHub: The regression unit test 'UnwrappedViewBypass6060Test' published in the Jackson repository serves as the functional proof of concept.

Mitigation Strategies

  • Upgrade the jackson-databind library to a patched version.
  • Decouple domain objects from external APIs using dedicated input Data Transfer Objects (DTOs).
  • Apply custom validation logic inside controller layers to audit administrative property values before binding.

Remediation Steps:

  1. Identify the version of jackson-databind in use by executing dependency scanning or package analysis.
  2. Update Maven pom.xml or Gradle build.gradle files to pull versions 2.18.9, 2.21.5, 2.22.1, 3.1.5, or 3.2.1 depending on your release track.
  3. Refactor beans that combine @JsonUnwrapped and @JsonView to separate privileged fields into distinct DTO classes if library upgrades must be delayed.

References

Read the full report for CVE-2026-59889 on our website for more details including interactive diagrams and full exploit analysis.

Top comments (1)

Collapse
 
topstar_ai profile image
Luis Cruz •

The bypass of @JsonView constraints on @JsonUnwrapped properties during deserialization, as described in the CVE-2026-59889 vulnerability, highlights the importance of careful consideration of Jackson's configuration and usage in our applications. I've seen similar issues in the past where the lack of active view validation led to unintended exposure of sensitive data. The proposed mitigation strategies, such as upgrading to a patched version of jackson-databind and using dedicated input Data Transfer Objects (DTOs), are solid recommendations. Have you considered the potential performance implications of adding custom validation logic inside controller layers, and are there any plans to explore alternative solutions that might minimize the overhead of this additional validation?