CVE-2020-36183

What it actually does

This is a Jackson Databind polymorphic deserialization flaw involving the gadget class org.docx4j.org.apache.xalan.lib.sql.JNDIConnectionPool. Applications using affected jackson-databind 2.x versions before 2.9.10.8 can be vulnerable when they deserialize attacker-controlled JSON with unsafe polymorphic typing enabled and the relevant gadget library is present on the classpath. A malicious payload can cause Jackson to instantiate the gadget and trigger attacker-controlled JNDI lookups, which may lead to remote code execution, sensitive data exposure, or application disruption depending on JVM/JNDI hardening, classpath contents, network egress controls, and runtime permissions.

Why it matters to the business

Successful exploitation can allow an unauthenticated remote attacker to run code in the context of the affected Java application, potentially leading to application takeover, data theft, service outage, lateral movement, and compromise of downstream systems reachable from the application. The vulnerability is old and not listed in CISA KEV, but public exploit knowledge exists and Jackson Databind is widely embedded through direct and transitive dependencies, so organizations should treat internet-facing or externally fed Java services using affected versions as higher priority.

How an attack unfolds

An attacker first identifies a Java service that accepts JSON and uses Jackson Databind with unsafe default typing or equivalent polymorphic type handling. The attacker then confirms that the vulnerable jackson-databind version is in use and that the docx4j-shaded Xalan gadget class org.docx4j.org.apache.xalan.lib.sql.JNDIConnectionPool is available on the runtime classpath. The attacker sends crafted JSON containing type metadata that instructs Jackson to instantiate the gadget. During deserialization, the gadget can initiate a JNDI lookup to an attacker-controlled LDAP, RMI, DNS, or other naming endpoint. If JVM settings and network egress allow the lookup to resolve attacker-controlled content or otherwise influence execution, the attacker may gain code execution in the Java process. Even where full code execution is blocked by modern JDK protections, attempted exploitation may still cause outbound callbacks, exceptions, sensitive environmental leakage, or denial-of-service conditions.

How to fix it

Upgrade jackson-databind to a fixed version. For the 2.9 branch, use 2.9.10.8 or later; the supplied fixed source revision is 7ae9214c0670eeb679dd131ab0aee3565cc7af87. Prefer upgrading to a currently supported Jackson release line rather than remaining on the legacy 2.9 branch. Review both direct and transitive dependencies for com.fasterxml.jackson.core:jackson-databind and ensure shaded or bundled copies are also updated. Remove unnecessary gadget-bearing libraries such as docx4j/Xalan variants where not required. Disable unsafe default typing, avoid deserializing untrusted polymorphic types, use explicit allow-lists for permitted subtypes, and prefer Jackson safe typing APIs such as PolymorphicTypeValidator where applicable. Restrict outbound LDAP, RMI, IIOP, DNS, and arbitrary TCP egress from application runtimes, and apply JVM/JNDI hardening appropriate to the deployed Java version.

How to confirm the fix worked

Confirm dependency resolution shows jackson-databind 2.9.10.8 or newer, or a supported newer Jackson version, in all build artifacts and runtime containers. Use software composition analysis, Maven/Gradle dependency trees, SBOMs, and container image scans to identify duplicate or shaded jackson-databind copies. Inspect application configuration and code for enableDefaultTyping, activateDefaultTyping, permissive @JsonTypeInfo use, or broad subtype registration. Verify that org.docx4j.org.apache.xalan.lib.sql.JNDIConnectionPool is not present unless required, and that patched Jackson blocks this gadget if encountered. Test network controls by confirming application workloads cannot initiate unexpected LDAP, RMI, IIOP, or other JNDI-related outbound connections to untrusted destinations. Review logs after patching for blocked deserialization attempts referencing the gadget class.

Typical attack path

1. Find an externally reachable endpoint, message consumer, API, or integration point that deserializes JSON using Jackson Databind.
2. Determine or assume that polymorphic typing is enabled through default typing, activateDefaultTyping, or permissive @JsonTypeInfo handling.
3. Confirm that the application includes an affected jackson-databind version before 2.9.10.8 and the org.docx4j.org.apache.xalan.lib.sql.JNDIConnectionPool gadget class on the classpath.
4. Send crafted JSON containing Jackson type metadata that references the gadget class and an attacker-controlled JNDI URL.
5. Observe outbound LDAP, RMI, DNS, or other JNDI-related callbacks from the target environment.
6. Use the callback path to attempt code execution, credential or metadata collection, application disruption, or follow-on movement depending on runtime controls.

How to detect it

Investigate whether exploitation has already occurred by correlating application logs, API gateway/WAF logs, HTTP access logs, message broker payload logs where available, JVM logs, EDR telemetry, DNS logs, firewall/proxy logs, and outbound network flow data. Look for JSON payloads containing Jackson type metadata that reference org.docx4j.org.apache.xalan.lib.sql.JNDIConnectionPool, especially when combined with ldap://, rmi://, iiop://, dns://, or other JNDI-style URLs. Review Java exception logs for blocked or failed deserialization attempts, including InvalidTypeIdException, InvalidDefinitionException, ClassNotFoundException, NamingException, or messages stating that a type was prevented for security reasons. Check for outbound LDAP/RMI/DNS connections from application processes to unusual internet hosts around the time of suspicious requests. If endpoint telemetry is available, look for the Java process spawning shells, script interpreters, download utilities, or other unexpected child processes after suspicious deserialization errors or network callbacks. Absence of a successful callback does not prove safety, because exploit attempts may fail due to missing gadget classes, patched blocklists, JDK protections, or egress controls.

• org.docx4j.org.apache.xalan.lib.sql.JNDIConnectionPool
• JNDIConnectionPool
• @class
• @type
• ldap://
• rmi://
• iiop://
• dns://
• com.fasterxml.jackson.databind.exc.InvalidTypeIdException
• com.fasterxml.jackson.databind.exc.InvalidDefinitionException
• Illegal type (org.docx4j.org.apache.xalan.lib.sql.JNDIConnectionPool) to deserialize
• prevented for security reasons
• javax.naming.NamingException
• javax.naming.InitialContext
• enableDefaultTyping
• activateDefaultTyping
• jackson-databind-2.9.10.7.jar
• jackson-databind-2.9.10.6.jar
• jackson-databind-2.9.10.5.jar
• jackson-databind-2.9.10.4.jar
• jackson-databind-2.9.10.3.jar
• jackson-databind-2.9.10.2.jar
• jackson-databind-2.9.10.1.jar
• jackson-databind-2.9.10.jar

What your security team should do

• Prioritize externally reachable Java services, API gateways, message consumers, and integration services that accept untrusted JSON and use jackson-databind before 2.9.10.8.
• Upgrade jackson-databind to 2.9.10.8 or later immediately, preferably to a currently supported release, and verify transitive and shaded dependency copies are not left behind.
• Search codebases for unsafe Jackson polymorphic typing patterns such as enableDefaultTyping, activateDefaultTyping, DefaultTyping, and broad @JsonTypeInfo usage, then replace them with explicit allow-list based type validation.
• Remove unnecessary gadget libraries from application classpaths, especially docx4j-shaded Xalan components if not required.
• Block or tightly control outbound LDAP, RMI, IIOP, and unexpected DNS egress from Java application environments to reduce exploitability of JNDI-based gadget chains.
• Hunt historical logs for payloads or exceptions referencing org.docx4j.org.apache.xalan.lib.sql.JNDIConnectionPool and for unusual outbound naming-service connections from Java workloads.
• Add SIEM detections for Jackson type metadata combined with JNDI URLs or the affected gadget class in HTTP bodies, API gateway logs, WAF events, and application logs.