CVE-2020-35728: Jackson-databind RCE Vulnerability

CVE-2020-35728 Overview

CVE-2020-35728 is an insecure deserialization vulnerability in FasterXML jackson-databind 2.x before version 2.9.10.8. The vulnerability arises from improper handling of the interaction between serialization gadgets and polymorphic typing, specifically related to the com.oracle.wls.shaded.org.apache.xalan.lib.sql.JNDIConnectionPool class (embedded Xalan in org.glassfish.web/javax.servlet.jsp.jstl).

This vulnerability allows remote attackers to exploit unsafe deserialization when polymorphic type handling is enabled and an attacker can supply crafted JSON input containing the vulnerable gadget class. Successful exploitation can lead to remote code execution through JNDI injection attacks.

Critical Impact

Remote attackers can achieve arbitrary code execution by exploiting the JNDIConnectionPool gadget chain during JSON deserialization, potentially leading to complete system compromise on applications using vulnerable jackson-databind versions with polymorphic typing enabled.

Affected Products

• FasterXML jackson-databind versions 2.x before 2.9.10.8
• Debian Linux 9.0
• NetApp Service Level Manager
• Oracle Agile PLM 9.3.6
• Oracle Application Testing Suite 13.3.0.1
• Oracle AutoVue 21.0.2
• Oracle Banking Corporate Lending Process Management (14.2, 14.3, 14.5)
• Oracle Banking Credit Facilities Process Management (14.2, 14.3, 14.5)
• Oracle Communications Billing and Revenue Management
• Oracle Communications Cloud Native Core Policy 1.14.0
• Oracle Data Integrator 12.2.1.4.0
• Oracle Primavera Gateway and Unifier
• Oracle Retail XStore Point of Service (multiple versions)
• Oracle WebCenter Portal (12.2.1.3.0, 12.2.1.4.0)

Discovery Timeline

• 2020-12-27 - CVE-2020-35728 published to NVD
• 2025-08-27 - Last updated in NVD database

Technical Details for CVE-2020-35728

Vulnerability Analysis

This vulnerability belongs to a well-known class of jackson-databind deserialization issues that have affected the library over multiple releases. The core problem lies in how jackson-databind handles polymorphic type deserialization when enabled via enableDefaultTyping() or @JsonTypeInfo annotations.

When polymorphic typing is active, jackson-databind includes type information in the JSON payload, allowing the deserializer to instantiate the appropriate class. However, this mechanism can be abused by attackers who supply malicious type references pointing to dangerous "gadget" classes present on the application's classpath.

The JNDIConnectionPool class from the embedded Xalan library in javax.servlet.jsp.jstl provides such a gadget. This class performs JNDI lookups during instantiation or property setting, which can be exploited to load malicious objects from attacker-controlled LDAP or RMI servers—a classic JNDI injection attack vector.

Root Cause

The root cause is CWE-502 (Deserialization of Untrusted Data). FasterXML jackson-databind failed to include com.oracle.wls.shaded.org.apache.xalan.lib.sql.JNDIConnectionPool in its blocklist of known dangerous gadget classes. When applications deserialize untrusted JSON data with polymorphic typing enabled, attackers can specify this class as the target type, triggering JNDI lookups that lead to remote code execution.

The underlying issue is the inherent tension between polymorphic deserialization functionality and security. Jackson-databind maintains a blocklist approach to prevent known dangerous classes from being instantiated, but this requires ongoing maintenance as new gadget chains are discovered.

Attack Vector

The attack requires an application that:

1. Uses a vulnerable version of jackson-databind (2.x before 2.9.10.8)
2. Has polymorphic type handling enabled (enableDefaultTyping() or @JsonTypeInfo)
3. Deserializes JSON data from untrusted sources
4. Has the javax.servlet.jsp.jstl library (containing embedded Xalan) on the classpath

An attacker crafts a malicious JSON payload specifying com.oracle.wls.shaded.org.apache.xalan.lib.sql.JNDIConnectionPool as the type, with properties configured to trigger a JNDI lookup to an attacker-controlled server. When deserialized, the JNDI lookup retrieves and executes a malicious object, achieving remote code execution.

The exploitation mechanism leverages JNDI injection, a technique commonly seen in attacks like Log4Shell (CVE-2021-44228). The attacker typically hosts a malicious LDAP or RMI server that returns a serialized Java object or reference to a remote class file, which gets loaded and executed in the context of the vulnerable application.

Detection Methods for CVE-2020-35728

Indicators of Compromise

• Outbound network connections to unknown LDAP or RMI servers from Java applications
• JSON payloads containing references to com.oracle.wls.shaded.org.apache.xalan.lib.sql.JNDIConnectionPool or similar JNDI-related classes
• Unusual process spawning from Java application processes
• JNDI lookup errors or connection attempts in application logs
• Presence of jackson-databind versions prior to 2.9.10.8 in application dependencies

Detection Strategies

• Implement application-layer monitoring for JSON payloads containing known gadget class names, particularly JNDIConnectionPool variants
• Monitor network traffic for outbound LDAP (port 389/636) or RMI (port 1099) connections from application servers
• Deploy web application firewalls with rules to detect jackson-databind deserialization attack patterns
• Use software composition analysis (SCA) tools to identify vulnerable jackson-databind versions in your codebase
• Implement runtime application self-protection (RASP) to detect and block deserialization attacks

Monitoring Recommendations

• Enable detailed logging for jackson-databind deserialization operations in non-production environments
• Configure egress firewall rules to block or alert on unexpected outbound JNDI protocol traffic
• Monitor Java process behavior for signs of post-exploitation activity such as command execution or file system access
• Implement dependency scanning in CI/CD pipelines to prevent deployment of vulnerable library versions

How to Mitigate CVE-2020-35728

Immediate Actions Required

• Upgrade jackson-databind to version 2.9.10.8 or later immediately
• Audit application code for usage of enableDefaultTyping() or unsafe @JsonTypeInfo configurations
• If immediate upgrade is not possible, disable polymorphic type handling or implement a strict allow-list of deserializable types
• Review application classpath for presence of javax.servlet.jsp.jstl and evaluate necessity
• Block outbound LDAP and RMI connections at the network level where not explicitly required

Patch Information

FasterXML has addressed this vulnerability by adding com.oracle.wls.shaded.org.apache.xalan.lib.sql.JNDIConnectionPool to the SubTypeValidator blocklist in jackson-databind version 2.9.10.8. The fix prevents this gadget class from being instantiated during polymorphic deserialization.

For detailed information about the fix, refer to the GitHub Issue Discussion. Organizations using Oracle products should consult the relevant Oracle Critical Patch Updates, including advisories from April 2021, October 2021, January 2022, April 2022, and July 2022.

Workarounds

• Disable default typing entirely if not required: avoid using ObjectMapper.enableDefaultTyping() methods
• Use ObjectMapper.activateDefaultTyping() with PolymorphicTypeValidator to implement strict allow-listing of deserializable types
• Implement input validation to reject JSON payloads containing unexpected type information
• Remove javax.servlet.jsp.jstl from the classpath if not required by the application
• Apply network-level controls to prevent outbound JNDI protocol connections

# Verify jackson-databind version in Maven projects
mvn dependency:tree -Dincludes=com.fasterxml.jackson.core:jackson-databind

# Check for vulnerable versions in Gradle projects  
./gradlew dependencies --configuration runtimeClasspath | grep jackson-databind

# Update to patched version in Maven pom.xml
# Change version to 2.9.10.8 or later