CVE-2020-36181

What it actually does

This is an unsafe deserialization issue in FasterXML jackson-databind involving polymorphic type handling. When an application uses vulnerable jackson-databind code and permits attacker-controlled type metadata, such as default typing or broad @JsonTypeInfo use, a crafted JSON document can cause Jackson to instantiate dangerous classes present on the application classpath. For this issue, the relevant risk is gadget-based deserialization through DBCP-style data source classes, which can trigger attacker-influenced lookups, connections, or code paths during object construction or property population. Depending on the available gadget classes, JVM configuration, and egress controls, impact can range from denial of service or outbound network interaction to remote code execution under the privileges of the Java application.

Why it matters to the business

Applications that parse untrusted JSON with vulnerable jackson-databind versions may be exposed to application compromise, data theft, lateral movement, service disruption, or unauthorized outbound connections. The issue is old, published in 2021, and public exploit techniques are available, so remaining exposure is most concerning in legacy Java services, embedded products, shaded dependencies, and applications with broad dependency trees. It is not listed in CISA KEV and is not known from the provided data to be used in ransomware campaigns, but the availability of exploits and the prevalence of jackson-databind in Java ecosystems make remediation important for internet-facing or high-trust services.

How an attack unfolds

An attacker first identifies a Java endpoint, message consumer, API, or service that accepts JSON and deserializes it with jackson-databind using unsafe polymorphic typing. The attacker then sends a JSON payload containing type metadata, such as @class or @type, that names a gadget class available on the target classpath, commonly in the Apache Commons DBCP or Tomcat DBCP data source families for this class of issue. Jackson resolves the attacker-supplied type and populates its properties from the JSON payload. If the gadget is present and the application configuration allows it, the object's side effects may cause outbound LDAP, RMI, JDBC, DNS, or HTTP interaction, loading of attacker-controlled resources, or execution of code reachable through the gadget chain. Successful exploitation gives the attacker the ability to run actions as the Java process, access application secrets, pivot to downstream services, or disrupt the service. Exploitation generally fails when unsafe default typing is disabled, strict type allow-listing is enforced, the gadget classes are absent, or fixed jackson-databind code blocks the dangerous subtype.

How to fix it

Upgrade FasterXML jackson-databind to a fixed build. For the affected Git source noted in the input, the fix is commit 7ae9214c0670eeb679dd131ab0aee3565cc7af87. For packaged dependencies, use a jackson-databind release that includes this fix or, preferably, move to a currently supported jackson-databind line rather than remaining on legacy 2.9.x builds. Deduplicate dependency declarations and check transitive, shaded, vendored, and application-server-provided copies of jackson-databind. Disable unsafe default typing, especially deprecated enableDefaultTyping patterns, and replace broad polymorphic deserialization with explicit type allow-lists using a restrictive PolymorphicTypeValidator. Avoid deserializing untrusted JSON into Object, Serializable, Comparable, or other overly broad base types. Remove unnecessary gadget-bearing libraries, such as unused DBCP/Tomcat DBCP components, from runtime classpaths. Add network egress controls that prevent application processes from making arbitrary LDAP, RMI, DNS, JDBC, and HTTP callbacks to untrusted destinations. As a compensating control, reject or inspect untrusted JSON containing suspicious polymorphic type metadata, but do not treat filtering alone as a complete fix.

How to confirm the fix worked

Confirm that all runtime artifacts use a jackson-databind build containing commit 7ae9214c0670eeb679dd131ab0aee3565cc7af87 or a later fixed release. Validate with dependency tooling such as Maven dependency:tree, Gradle dependencies, SBOM scans, container image scans, and inspection of shaded JARs or fat JARs. Search code for unsafe patterns including enableDefaultTyping, activateDefaultTyping without a strict allow-list, objectMapper.enableDefaultTyping, and broad @JsonTypeInfo usage on untrusted inputs. Confirm that no vulnerable jackson-databind copy is loaded from application servers, plugins, bundled libraries, or vendor packages. In a test environment, send benign JSON containing unexpected @class or @type values and confirm the application rejects it without attempting class loading or outbound network access. Review egress logs to ensure Java application processes cannot make arbitrary LDAP, RMI, DNS, JDBC, or HTTP connections to untrusted hosts.

Typical attack path

1. Discover a Java application endpoint, API, queue consumer, or integration service that accepts attacker-controlled JSON.
2. Determine or assume that the service uses jackson-databind with unsafe polymorphic deserialization enabled.
3. Craft JSON containing polymorphic type metadata such as @class or @type that references a known gadget class available in common Java dependency stacks.
4. Include gadget properties that trigger a dangerous side effect, such as an external lookup, outbound connection, resource loading, or code execution path.
5. Send the payload to the vulnerable parser through HTTP, messaging infrastructure, file import, or another JSON ingestion path.
6. Observe callback traffic, exceptions, timing changes, or command effects to confirm exploitability.
7. Use the gained execution or interaction primitive to steal credentials, access application data, deploy tooling, move laterally, or persist.

How to detect it

Look for evidence of attempted or successful deserialization exploitation in application logs, WAF logs, API gateway logs, reverse proxy logs, message broker payload logs where available, Java exception logs, EDR telemetry, DNS logs, egress firewall logs, and outbound proxy logs. High-signal indicators include inbound JSON containing @class, @type, or wrapper-array polymorphic type markers with DBCP or Tomcat DBCP data source class names. Application logs may show Jackson exceptions such as InvalidTypeIdException, blocked subtype messages, class resolution errors, ClassNotFoundException, or stack traces referencing SubTypeValidator. Successful or near-successful attempts may generate unexpected outbound LDAP, RMI, DNS, JDBC, or HTTP connections from Java application processes shortly after suspicious JSON requests. Investigate any post-exploitation signs from the same process context, including child process creation by java, unexpected shell execution, new files in temporary directories, credential access, unusual outbound traffic, or new scheduled/background tasks. Because blocked attempts may only appear as parsing errors, correlate suspicious request bodies with response status codes, Java stack traces, and egress events within the same time window.

• org.apache.commons.dbcp2.datasources.PerUserPoolDataSource
• org.apache.tomcat.dbcp.dbcp2.datasources.PerUserPoolDataSource
• org.apache.commons.dbcp2.datasources.SharedPoolDataSource
• org.apache.tomcat.dbcp.dbcp2.datasources.SharedPoolDataSource
• org.apache.commons.dbcp2.cpdsadapter.DriverAdapterCPDS
• org.apache.tomcat.dbcp.dbcp2.cpdsadapter.DriverAdapterCPDS
• "@class":"org.apache.commons.dbcp2.datasources.PerUserPoolDataSource"
• "@type":"org.apache.commons.dbcp2.datasources.PerUserPoolDataSource"
• "@class":"org.apache.tomcat.dbcp.dbcp2.datasources.PerUserPoolDataSource"
• "@type":"org.apache.tomcat.dbcp.dbcp2.datasources.PerUserPoolDataSource"
• com.fasterxml.jackson.databind.exc.InvalidTypeIdException
• Could not resolve type id
• SubTypeValidator
• enableDefaultTyping
• activateDefaultTyping
• java.lang.ClassNotFoundException: org.apache.commons.dbcp2.datasources.PerUserPoolDataSource
• java.lang.ClassNotFoundException: org.apache.tomcat.dbcp.dbcp2.datasources.PerUserPoolDataSource
• ldap://
• rmi://

What your security team should do

• Prioritize remediation for internet-facing Java services, authentication-adjacent services, API gateways, file import services, message consumers, and systems with access to sensitive data or credentials.
• Upgrade jackson-databind everywhere, including transitive, shaded, vendored, plugin, and container image copies; verify the fixed commit 7ae9214c0670eeb679dd131ab0aee3565cc7af87 or a later fixed release is present.
• Create an engineering ticket to remove deprecated unsafe default typing patterns and replace them with explicit type allow-lists.
• Inventory services whose classpaths include jackson-databind plus Apache Commons DBCP or Tomcat DBCP gadget classes, and treat those as higher risk.
• Add SIEM detections for JSON payloads and application errors containing suspicious Jackson type metadata and DBCP gadget class names.
• Review historical application, WAF, proxy, DNS, LDAP, RMI, and egress firewall logs for exploit attempts and callback behavior.
• Restrict outbound network access from Java application workloads to only required destinations and protocols.
• Add dependency scanning gates in CI/CD to prevent reintroduction of vulnerable jackson-databind versions.