Overview
The CVE-2017-8046 vulnerability highlights how untrusted JSON payloads can lead to remote code execution when servers use Spring Data REST with permissive deserialization. In affected configurations, specially crafted PATCH requests could trigger arbitrary Java code execution on the server by abusing Jackson’s polymorphic type handling. This falls under CWE-20: Improper Input Validation, where the system naively trusts and deserializes attacker-supplied data. The impact is severe: an attacker can modify resources, execute code, or pivot into the hosting environment, potentially compromising the entire application. Spring Data REST versions prior to 2.6.9 (Ingalls SR9) and prior to 3.0.1 (Kay SR1), together with Spring Boot versions prior to 1.5.9 and 2.0 M6, were vulnerable if they allowed PATCH payloads to be deserialized with default typing enabled. This guide focuses on the concrete exposure in Spring Boot applications and shows practical mitigations in real Java code.
Exploitation typically involves sending a PATCH request with a JSON payload that includes type metadata or crafted structures intended to trigger Jackson’s polymorphic deserialization. If the ObjectMapper is configured to use default typing, the attacker can influence which classes are instantiated during deserialization, potentially loading gadget classes that execute code. The vulnerability manifests when endpoints accept PATCH bodies and bind them to domain objects or update existing entities without strict type constraints. Upgrading to patched releases and removing permissive deserialization paths are essential defensive steps.
Mitigation combines version updates with secure data binding practices. Upgrade to Spring Data REST 2.6.9+ (Ingalls SR9) or 3.0.1+ (Kay SR1) and to Spring Boot 1.5.9+ or 2.0.x+ releases where available. In application code, disable Jackson default typing, prefer strongly typed DTOs for PATCH operations, and validate or whitelist input fields. This reduces the attack surface even if an attacker manages to craft malicious payloads. After upgrading, re-test with security tooling and targeted manual tests to confirm that PATCH requests cannot cause RCE via deserialization.
Affected Versions
Spring Data REST prior to 2.6.9 (Ingalls SR9) and prior to 3.0.1 (Kay SR1); Spring Boot prior to 1.5.9 and 2.0 M6
Code Fix Example
Spring Boot API Security Remediation
/* Demonstration only: vulnerable vs fixed object mapping for PATCH-like updates. Uses Jackson ObjectMapper default typing. Do not deploy this pattern in production. */
import com.fasterxml.jackson.databind.ObjectMapper;
public class VulnerabilityDemo {
public static class Resource {
public String name;
public int quantity;
}
// VULNERABLE PATTERN: default typing enabled
public static ObjectMapper getVulnerableMapper() {
ObjectMapper m = new ObjectMapper();
m.enableDefaultTyping(ObjectMapper.DefaultTyping.NON_FINAL);
return m;
}
// FIXED PATTERN: default typing disabled
public static ObjectMapper getFixedMapper() {
ObjectMapper m = new ObjectMapper();
m.disableDefaultTyping();
return m;
}
public static Resource apply(String json, Resource current, boolean vulnerable) throws Exception {
ObjectMapper mapper = vulnerable ? getVulnerableMapper() : getFixedMapper();
return mapper.readerForUpdating(current).readValue(json, Resource.class);
}
public static void main(String[] args) throws Exception {
Resource r = new Resource();
r.name = "widget";
r.quantity = 5;
// crafted payload attempting to specify a class via @class (or similar) for deserialization
String patch = "{\\"name\\":\\"evil\\",\\"quantity\\":10, \\"@class\\":\\"java.lang.Runtime\\"}";
Resource v = apply(patch, r, true); // vulnerable path: may deserialize attacker-controlled types
Resource f = apply(patch, r, false); // fixed path: malicious types rejected
System.out.println("VULNERABLE result -> " + v.name + ":" + v.quantity);
System.out.println("FIXED result -> " + f.name + ":" + f.quantity);
}
}