SSRF

How to Fix SSRF in Spring Boot [March 2026] [CVE-2018-11040]

[Updated Mar 2026] Updated CVE-2018-11040

Overview

CVE-2018-11040 describes a JSONP exposure vulnerability in Spring Framework that could enable cross-domain data access via JSONP callbacks when certain view configurations are present. Specifically, 5.0.x releases prior to 5.0.7 and 4.3.x releases prior to 4.3.18 (and older unsupported versions) could allow a web application to enable cross-domain requests through JSONP when MappingJackson2JsonView or AbstractJsonpResponseBodyAdvice are configured. Although these features are not enabled by default in Spring Framework or Spring Boot, once MappingJackson2JsonView is registered as a view, JSONP support becomes accessible via the jsonp and callback parameters. An attacker could craft a page on a malicious domain that loads data from the vulnerable endpoint by abusing a JSONP callback, potentially exposing sensitive information exposed by the endpoint. In practice, this vulnerability manifests as an information exposure risk (CWE-829) where data intended for the application's own domain can be exfiltrated to an attacker-controlled domain using a JSONP call. The JSONP wrapper around the response means the attacker’s page receives the JSON payload wrapped in a JavaScript callback, which can lead to unintended data leakage and, in some scenarios, facilitate further attacks that rely on cross-domain data access. Patch availability exists from the Spring project for the affected branches. The remediation guidance here references CVE-2018-11040 and aligns with the intent of mitigating this exposure in real Spring Boot deployments. Remediating this requires both code-level hardening and keeping dependencies up to date. The primary fixes are to upgrade to patched Spring Framework versions and to avoid enabling JSONP support in your application by default. In a Spring Boot project, this typically means using a Boot release that bundles the patched Spring Framework, and removing any explicit JSONP-enabled view configurations. If JSONP is strictly required, implement a strict, validated whitelist for allowed callback names or replace JSONP with proper CORS policies and authenticated access controls. After applying patches, thoroughly test endpoints to ensure no accidental JSONP wrapping occurs.

Affected Versions

Spring Framework 5.0.x before 5.0.7 and 4.3.x before 4.3.18 (and older unsupported versions).

Code Fix Example

Spring Boot API Security Remediation
/* Vulnerable pattern (JSONP is effectively enabled by presence of MappingJackson2JsonView) */
@Configuration
public class JsonpVulnConfig {
    @Bean
    public MappingJackson2JsonView jsonView() {
        // JSONP support will be active when a request includes ?callback=... or ?jsonp=...
        return new MappingJackson2JsonView();
    }

    @Bean
    public ViewResolver viewResolver() {
        // Resolves beans by their name, enabling a response rendered by jsonView
        return new BeanNameViewResolver();
    }
}

@RestController
@RequestMapping("/api")
public class InfoController {
    @GetMapping("/data")
    public Map<String, Object> data() {
        Map<String, Object> m = new HashMap<>();
        m.put("id", 123);
        m.put("secret", "top-secret");
        return m; // When a client passes a JSONP callback, this JSON is wrapped and exposed cross-domain
    }
}

/* Fixed pattern (JSONP support disabled by not registering JSONP-enabled views) */
@Configuration
public class SafeConfig {
    // Do not register MappingJackson2JsonView to avoid JSONP exposure
}

@RestController
@RequestMapping("/api")
public class SafeInfoController {
    @GetMapping("/data")
    public Map<String, Object> data() {
        Map<String, Object> m = new HashMap<>();
        m.put("id", 123);
        m.put("secret", "top-secret");
        return m;
    }
}

CVE References

Choose which optional cookies to allow. You can change this any time.