CVE-2020-36180

What it actually does

CVE-2020-36180 is a Jackson Databind deserialization flaw involving unsafe polymorphic type handling. Applications are primarily exposed when they deserialize attacker-controlled JSON with Jackson default typing or otherwise permissive polymorphic typing enabled, and when a vulnerable gadget class is present on the application classpath. In that configuration, an attacker can supply JSON type metadata that causes Jackson to instantiate attacker-selected classes during deserialization. Depending on the available gadget chain and runtime permissions, this can lead to remote code execution, unintended network connections, file access, denial of service, or other application-level compromise. The upstream fix adds protections for the unsafe subtype behavior in jackson-databind, including the fix commit 7ae9214c0670eeb679dd131ab0aee3565cc7af87.

Why it matters to the business

A vulnerable Java service that accepts untrusted JSON may be turned into an entry point for server compromise. Successful exploitation can allow attackers to run commands in the context of the application, steal data accessible to the service, pivot to internal systems, disrupt business operations, or deploy additional malware. Jackson Databind is widely used across Java ecosystems, so exposure may exist indirectly through frameworks and transitive dependencies. This issue is not currently listed in CISA KEV and is not marked as ransomware-used, but public exploit knowledge exists and the vulnerability has been public since 2021, making unpatched legacy applications higher risk.

How an attack unfolds

An attacker first identifies an application endpoint, API, queue consumer, or other data ingestion path that deserializes JSON using a vulnerable Jackson Databind build. The attacker then determines whether polymorphic typing is enabled or whether the application accepts type metadata such as @type or @class. If the required gadget class exists in the application dependency set, the attacker submits a crafted JSON document that names that class and supplies properties designed to trigger dangerous behavior during object construction, setter invocation, or post-deserialization processing. If successful, the application instantiates the attacker-selected type and the gadget chain performs attacker-controlled actions, such as initiating outbound connections, loading attacker-controlled resources, executing commands, or causing application failure. Post-exploitation activity may include persistence attempts, credential access, data collection, lateral movement, or cleanup of obvious payload traces.

How to fix it

Upgrade jackson-databind to a fixed, supported release that includes the upstream correction, or apply the upstream fix commit 7ae9214c0670eeb679dd131ab0aee3565cc7af87 if maintaining a source-based build. Because the affected product data references the Git project rather than a packaged version, organizations should map all deployed jackson-databind artifacts to their actual Maven or Gradle versions and move to the latest supported Jackson line available for the application. Do not rely solely on blacklist-based protections: disable legacy default typing for untrusted input, avoid ObjectMapper.enableDefaultTyping, avoid permissive activateDefaultTyping configurations, and use an explicit allowlist via BasicPolymorphicTypeValidator where polymorphism is required. Remove unnecessary gadget-prone libraries from application classpaths, especially unused database connection pool, JNDI, scripting, XML, or logging components. Restrict egress from application servers to reduce callback and payload retrieval options. Apply compensating controls at API gateways or WAFs to block suspicious JSON type metadata in untrusted request bodies where application functionality does not require it.

How to confirm the fix worked

Confirm remediation by inventorying all deployed Java artifacts and dependency manifests for com.fasterxml.jackson.core:jackson-databind, including transitive dependencies embedded inside executable JARs, WARs, shaded JARs, containers, and vendor packages. Use Maven dependency:tree, Gradle dependencies, SBOM tooling, container image scanners, and runtime classpath inspection to verify that vulnerable jackson-databind builds are no longer present. Review code for ObjectMapper.enableDefaultTyping, activateDefaultTyping with broad validators, DefaultTyping.EVERYTHING, DefaultTyping.NON_FINAL, and custom TypeResolverBuilder usage on untrusted input paths. Confirm that any required polymorphic deserialization uses explicit allowlisted base types and subtypes. In staging, send benign JSON containing unexpected @type or @class metadata to untrusted endpoints and verify that it is rejected, ignored, or constrained to approved types. Review application startup logs and dependency reports to ensure only one intended jackson-databind version is loaded at runtime.

Typical attack path

1. Find a Java application or service that accepts JSON from untrusted users or external systems.
2. Confirm or infer use of a vulnerable jackson-databind version and permissive polymorphic deserialization, such as default typing.
3. Identify whether a compatible gadget class is present through error behavior, dependency fingerprinting, or framework knowledge.
4. Send crafted JSON containing polymorphic type metadata that references the gadget class.
5. Trigger deserialization through an HTTP request, API call, message queue event, uploaded file, or stored payload later processed by the application.
6. Cause the application to instantiate the attacker-controlled type and execute the gadget behavior.
7. Use resulting code execution, outbound callback, file access, or denial-of-service condition to advance the intrusion.

How to detect it

To determine whether exploitation was attempted or successful, review API gateway, reverse proxy, WAF, application access, application error, message broker, and EDR logs for JSON payloads containing polymorphic type metadata and Java class names. Focus on endpoints that accept JSON request bodies, uploaded JSON files, webhook payloads, serialized job definitions, or queue messages. In application logs, look for Jackson exceptions such as invalid type id, denied subtype, failed deserialization, or class resolution failures occurring near suspicious requests. In network telemetry, look for unexpected outbound DNS, HTTP, LDAP, RMI, or JDBC-like connections from Java application servers shortly after receiving unusual JSON. In host telemetry, look for child processes spawned by Java runtimes, temporary files written by the application user, new web shells or scripts in application directories, and anomalous JVM command execution. Because exploitation depends on application-specific gadget availability, there is no single universal IOC; correlate suspicious JSON type metadata with server-side errors, outbound callbacks, or process creation from the Java service account.

• "@type"
• "@class"
• "com.fasterxml.jackson.databind.exc.InvalidTypeIdException"
• "Could not resolve type id"
• "Invalid type id"
• "not a subtype"
• "Illegal type"
• "enableDefaultTyping"
• "activateDefaultTyping"
• "DefaultTyping.NON_FINAL"
• "DefaultTyping.EVERYTHING"
• "java.lang.Runtime"
• "java.lang.ProcessBuilder"
• "javax.naming.InitialContext"
• "ldap://"
• "rmi://"
• "dns://"
• "http://"
• "com.fasterxml.jackson.databind.jsontype"
• "com.fasterxml.jackson.databind.ObjectMapper"
• "SubTypeValidator"
• "Denied resolution of"
• "cmd.exe /c"
• "/bin/sh -c"

What your security team should do

• Prioritize externally reachable Java applications, API services, and message-processing workloads that accept JSON from untrusted sources.
• Inventory jackson-databind across source repositories, build manifests, deployed artifacts, containers, and vendor-supplied Java applications.
• Upgrade to a supported fixed Jackson release or a build containing commit 7ae9214c0670eeb679dd131ab0aee3565cc7af87.
• Search code for legacy Jackson default typing patterns and replace them with explicit allowlisted polymorphic type validators.
• Identify and reduce unnecessary gadget-capable dependencies on application classpaths.
• Add WAF or API gateway detections for suspicious JSON polymorphic type metadata where feasible.
• Review historical logs for deserialization errors, denied subtype messages, unusual outbound callbacks, and suspicious JSON bodies containing Java class names.
• Restrict application server outbound network access to required destinations only.
• Add CI/CD policy checks to prevent reintroduction of vulnerable jackson-databind versions or unsafe ObjectMapper configurations.
• Because exploit code is publicly available, treat confirmed vulnerable internet-facing services as requiring rapid remediation even though this issue is not in KEV.