Description

Applications that deserialize execution contexts with Jackson2ExecutionContextStringSerializer are vulnerable to a deserialization attack if they use an untrusted data source for the job repository. The JobParameterDeserializer does not properly enforce the trusted-types allowlist, allowing an attacker to craft malicious input that can lead to arbitrary code execution, including known Jackson RCE gadgets. Spring Batch 6.0.0 - 6.0.4 Spring Batch 5.2.0 - 5.2.6

Executive Summary

Technical Details

Mitigations

References

Additional Metadata

{
  "score": "5.6",
  "pubDate": "2026-08-27T06:17:17.250Z",
  "pubdate": "2026-08-27T06:17:17.250Z",
  "executiveSummary": "This vulnerability is an insecure deserialization flaw affecting the Jackson2ExecutionContextStringSerializer component within Spring Batch. The defect arises from the failure of the JobParameterDeserializer to effectively enforce trusted-type allowlists during the deserialization of job execution contexts.\nAn attacker capable of influencing the data source used by the job repository can inject malicious serialized payloads. When the application processes these contexts, it triggers the instantiation of arbitrary classes, facilitating Remote Code Execution (RCE) via known Jackson polymorphic type handling gadgets.\nThe vulnerability affects Spring Batch versions 6.0.0 through 6.0.4 and 5.2.0 through 5.2.6. Successful exploitation requires the attacker to have write access to the job repository or the ability to supply a crafted execution context to the application, potentially leading to a full system compromise. The severity is high, as it allows unauthorized execution of arbitrary code within the context of the application server.",
  "technicalDetails": "The root cause of this vulnerability lies in the improper implementation of class allowlisting within the JobParameterDeserializer when using Jackson2ExecutionContextStringSerializer. In Spring Batch, the execution context is frequently serialized and stored in a persistent job repository to maintain state across job runs.\nWhen Jackson is configured for polymorphic deserialization without strict type validation, it allows the input stream to specify the class type to be instantiated. The vulnerable component, JobParameterDeserializer, fails to adequately restrict these types to a safe, pre-defined set of trusted classes.\nThe attack flow begins with the attacker injecting a malicious payload into the job repository, often stored in a relational database. This payload contains serialized data that references 'gadget' classes—existing dependencies in the application classpath that perform dangerous actions (such as invoking OS commands or writing files) upon instantiation or during property setting.\nWhen the Spring Batch framework attempts to restore the job execution context, it invokes Jackson2ExecutionContextStringSerializer to deserialize the stored string. Because the deserializer is not configured with an effective allowlist (e.g., enableDefaultTyping or lack of specific polymorphic sub-type constraints), the underlying Jackson ObjectMapper honors the malicious type information provided in the payload.\nThe Jackson library proceeds to instantiate the specified gadget class and populates its fields based on the provided input. This process results in the execution of arbitrary logic embedded in the gadget class, leading to RCE. The vulnerability is triggered automatically as part of the standard batch job retrieval process, meaning no further interaction is required once the malicious data is persisted in the repository.\nThe attack surface is primarily limited to environments where the JobRepository is exposed to untrusted input or where the persistence layer is compromised. However, because job parameters and contexts can be influenced by external inputs in many batch architectures, this represents a significant risk to the integrity and availability of the host system. The lack of proper polymorphic handling ensures that any available gadget class compatible with the library version can be leveraged to execute code under the privileges of the application runtime."
}