Description

Spring Batch's FlatFileItemReader supports files where a single logical record spans multiple physical lines — for example, a CSV field that contains embedded newlines wrapped in quotes. A specially crafted input file could exploit the way the reader assembles those multi-line records to consume excessive CPU time and memory, causing the batch job to stall or run out of memory. Spring Batch 6.0.0 - 6.0.4 Spring Batch 5.2.0 - 5.2.6 Spring Batch 4.3.0 - 4.3.13

Executive Summary

Technical Details

Mitigations

References

Additional Metadata

{
  "score": "5.9",
  "pubDate": "2026-08-27T06:17:18.143Z",
  "pubdate": "2026-08-27T06:17:18.143Z",
  "executiveSummary": "This vulnerability is a Denial of Service (DoS) flaw affecting the FlatFileItemReader component within Spring Batch.\nThe vulnerability arises from improper handling of multi-line records in input files, specifically when dealing with quoted fields that contain embedded newline characters.\nA specially crafted input file can manipulate the record assembly process, forcing the application to consume disproportionate amounts of CPU cycles and memory.\nThis behavior can lead to resource exhaustion, resulting in the batch job stalling indefinitely or crashing due to OutOfMemory (OOM) errors.\nAffected products include Spring Batch versions 6.0.0 - 6.0.4, 5.2.0 - 5.2.6, and 4.3.0 - 4.3.13.\nSuccessful exploitation allows an attacker capable of providing input to the FlatFileItemReader to induce a complete service disruption, impacting the availability of the batch processing system.",
  "technicalDetails": "The vulnerability resides in the record aggregation logic of the FlatFileItemReader component. Spring Batch is designed to parse flat files, and when configured for multi-line support, it must correctly identify the boundaries of a logical record when a field contains embedded newlines (typically within quotes).\nThe root cause is an inefficient parsing or assembly mechanism that does not adequately limit the processing of record continuations. When an attacker provides a maliciously crafted file, they can include deeply nested or improperly terminated quoted fields that cause the reader to continue buffering input in anticipation of a record completion that never occurs or occurs only after processing an excessive number of lines.\nThe attack flow begins when the batch process reads a line from the input source. If the current line is detected as part of a multi-line record (e.g., an unclosed quote is detected), the component attempts to append subsequent lines to the current record buffer.\nBy continuously providing input that forces the parser to keep the buffer open, the attacker forces the JVM to allocate increasingly large amounts of memory to hold the incomplete record. Simultaneously, the logic governing the line-by-line assembly consumes significant CPU cycles as it iterates through character streams to determine logical record boundaries.\nBecause the reader does not enforce strict length or line count constraints on logical records during this aggregation phase, the process can escalate until it reaches the resource limits of the environment.\nThis exploitation does not necessarily require authentication to the application itself, provided the attacker can influence the file content processed by the vulnerable Spring Batch job. The impact is a resource-exhaustion-based Denial of Service, which effectively terminates the processing thread or compromises the stability of the entire JVM, resulting in application downtime.\nThe issue persists across the identified versions of Spring Batch 4, 5, and 6, indicating a fundamental design flaw in how the FlatFileItemReader handles complex, potentially infinite multi-line record assembly patterns."
}