CVE-2020-35728

What it actually does

This is a Jackson Databind polymorphic deserialization flaw in the 2.x line before 2.9.10.8. When an application uses Jackson default typing or otherwise accepts attacker-controlled type metadata, a crafted JSON payload can reference the gadget class com.oracle.wls.shaded.org.apache.xalan.lib.sql.JNDIConnectionPool from embedded Xalan/JSTL-related libraries. During deserialization, Jackson may instantiate attacker-selected types and trigger JNDI behavior, potentially causing outbound LDAP/RMI/DNS lookups, attacker-controlled object creation, data exposure, denial of service, or remote code execution depending on classpath, JNDI behavior, JVM hardening, and network egress controls. Exploitation requires a vulnerable Jackson version, an unsafe polymorphic deserialization configuration, the relevant gadget class being present, and an endpoint that deserializes untrusted input.

Why it matters to the business

Successful exploitation can turn a normal data-processing API into a path for server compromise. The likely consequences are theft of application secrets, unauthorized access to downstream systems, service disruption, malware deployment, and loss of integrity for data handled by the affected Java service. Although this issue is not listed in CISA KEV and has no known mature public exploit in the provided data, the CVSS score is high and the EPSS value indicates non-trivial exploitation likelihood, so internet-facing services and services processing untrusted JSON should be prioritized. Because Jackson is widely embedded as a transitive dependency, exposure may exist in applications even when teams did not explicitly add jackson-databind themselves.

How an attack unfolds

An attacker first identifies a Java application endpoint that accepts JSON or another Jackson-processed payload and reflects errors or behavior consistent with Jackson Databind. They then determine whether the application permits polymorphic type handling, such as default typing or type metadata fields like @type or @class. If the vulnerable jackson-databind version is present and the embedded Xalan/JSTL gadget class is available on the classpath, the attacker submits a payload that names com.oracle.wls.shaded.org.apache.xalan.lib.sql.JNDIConnectionPool as the target type and supplies properties that cause a JNDI lookup or related side effect during object construction or property binding. The attacker monitors for outbound callbacks such as LDAP, RMI, or DNS to confirm code path reachability. If the runtime and network controls permit it, the attacker attempts to escalate the callback into code execution or uses the primitive for reconnaissance, credential theft, or further pivoting. Failed attempts often generate Jackson mapping exceptions, invalid type-id errors, JNDI connection errors, or unusual outbound traffic from the Java process.

How to fix it

Upgrade jackson-databind to 2.9.10.8 or later at minimum; preferably move to a currently supported Jackson 2.x release and keep jackson-core and jackson-annotations aligned to compatible versions. For source builds, ensure the FasterXML jackson-databind fix commit 7ae9214c0670eeb679dd131ab0aee3565cc7af87 or a later release is present. For Debian 9 imagemagick package contexts listed in the input, apply the vendor-fixed package version 8:6.9.7.4+dfsg-11+deb9u12 or later, while also separately inventorying Java dependencies because the core vulnerable component is jackson-databind. Disable Jackson default typing for untrusted input wherever possible. If polymorphic deserialization is required, use an explicit allowlist of safe application-owned types, such as BasicPolymorphicTypeValidator in newer Jackson versions, rather than broad package or base-class acceptance. Remove unnecessary gadget-bearing libraries from application classpaths, especially embedded Xalan/JSTL/WebLogic-shaded libraries where not required. Restrict outbound LDAP, RMI, DNS, HTTP, and other egress from application servers to reduce callback-based exploitation. Harden JVM JNDI behavior and ensure legacy remote codebase loading is disabled. Treat exposed services that deserialize unauthenticated input as priority patch targets.

How to confirm the fix worked

Confirm dependency versions using software composition analysis, build manifests, SBOMs, Maven/Gradle dependency trees, container image scans, and runtime classpath inspection. Verify that jackson-databind is at least 2.9.10.8 or a later supported version and that no shaded or bundled vulnerable jackson-databind jar remains inside application archives. Review application code for ObjectMapper.enableDefaultTyping, activateDefaultTyping without a strict validator, @JsonTypeInfo on externally supplied objects, or permissive subtype validators. Confirm that the specific gadget class com.oracle.wls.shaded.org.apache.xalan.lib.sql.JNDIConnectionPool is not present unless needed. Use a safe, non-destructive validation payload in a controlled test environment to verify that untrusted type metadata is rejected and does not trigger outbound DNS/LDAP/RMI callbacks. Validate that egress controls block unexpected outbound connections from Java application processes. After patching, restart applications and rescan runtime artifacts, not only source repositories, to ensure the fixed library is actually loaded.

Typical attack path

1. Find a Java application endpoint that accepts externally supplied JSON or serialized data.
2. Probe for Jackson polymorphic deserialization behavior using type metadata fields such as @type, @class, or wrapper-array type declarations.
3. Confirm that the application is using jackson-databind before 2.9.10.8 and that unsafe default typing or equivalent polymorphic binding is enabled.
4. Confirm or assume the presence of the embedded Xalan/JSTL gadget class com.oracle.wls.shaded.org.apache.xalan.lib.sql.JNDIConnectionPool on the application classpath.
5. Send a crafted deserialization payload that references the gadget class and causes a JNDI-related lookup or object-construction side effect.
6. Observe outbound LDAP, RMI, or DNS callbacks, application errors, timing differences, or other behavior indicating the payload executed.
7. If possible, convert the deserialization/JNDI primitive into command execution, secret retrieval, service disruption, or lateral movement.

How to detect it

To determine whether exploitation has already occurred, review web access logs, API gateway logs, WAF logs, application logs, JVM logs, EDR telemetry, DNS logs, proxy logs, firewall logs, and NetFlow for suspicious deserialization probes and outbound callbacks. Search request bodies, query parameters, headers, and error messages for Jackson type metadata containing gadget class names such as com.oracle.wls.shaded.org.apache.xalan.lib.sql.JNDIConnectionPool or org.apache.xalan.lib.sql.JNDIConnectionPool. Look for Jackson exceptions including InvalidTypeIdException, JsonMappingException, blocked or denied subtype messages, and stack traces involving ObjectMapper, TypeDeserializer, JNDIConnectionPool, InitialContext, or Xalan SQL classes. Correlate any such events with outbound LDAP, RMI, DNS, HTTP, or unusual TCP connections from Java processes, especially to unfamiliar external hosts. On hosts, investigate child processes spawned by Java runtimes, unexpected shell execution, downloads using curl/wget, new files in temporary directories, persistence changes, modified startup scripts, unexpected cron/systemd entries, and suspicious environment-variable or secret access. Because exploitation conditions are configuration-dependent and many attempts may fail, treat repeated type-id errors plus outbound lookup attempts as high-confidence exploitation activity even if command execution is not proven.

• com.oracle.wls.shaded.org.apache.xalan.lib.sql.JNDIConnectionPool
• org.apache.xalan.lib.sql.JNDIConnectionPool
• JNDIConnectionPool
• com.oracle.wls.shaded.org.apache.xalan
• org.glassfish.web.javax.servlet.jsp.jstl
• javax.servlet.jsp.jstl
• @type
• @class
• ldap://
• rmi://
• dns://
• iiop://
• java.lang.Runtime
• java.lang.ProcessBuilder
• com.fasterxml.jackson.databind.exc.InvalidTypeIdException
• com.fasterxml.jackson.databind.JsonMappingException
• Could not resolve type id
• Invalid type id
• SubTypeValidator
• Illegal type
• javax.naming.InitialContext
• NamingException
• ObjectMapper.enableDefaultTyping
• activateDefaultTyping
• java.lang.ProcessImpl
• /bin/sh
• /bin/bash
• cmd.exe
• powershell.exe
• curl
• wget
• /tmp/
• /var/tmp/

What your security team should do

• Prioritize remediation for internet-facing Java services, unauthenticated APIs, message consumers, and any workload that deserializes untrusted JSON with Jackson.
• Inventory all direct, transitive, shaded, and vendor-bundled copies of jackson-databind and upgrade anything before 2.9.10.8 to a supported fixed version.
• Search codebases for unsafe Jackson polymorphic deserialization patterns, especially enableDefaultTyping, activateDefaultTyping with broad validators, and externally controlled @JsonTypeInfo usage.
• Remove or isolate unnecessary gadget-bearing libraries from Java classpaths and application bundles.
• Implement network egress restrictions so application servers cannot initiate arbitrary LDAP, RMI, DNS, or HTTP callbacks to the internet.
• Add SIEM detections for suspicious Jackson type metadata referencing Xalan/JNDI gadget classes and for outbound LDAP/RMI/DNS from Java application processes.
• Review historical logs around public-facing JSON endpoints for type-id exceptions, JNDI connection errors, and outbound callback attempts.
• For legacy applications that cannot be upgraded quickly, disable default typing, add strict type allowlists, block suspicious request patterns at the edge, and isolate the service until a permanent fix is deployed.