CVE-2026-47881 is a medium severity (CVSS 5.9) resource exhaustion flaw in Spring Batch. A crafted input file with multi-line records can make FlatFileItemReader burn CPU and memory until the job stalls. Fixed in Spring Batch 6.0.5, which caps record size.
What's affected
Spring says the issue applies only when the reader uses DefaultRecordSeparatorPolicy or JsonRecordSeparatorPolicy. The default SimpleRecordSeparatorPolicy is not affected.
- Spring Batch 6.0.0 to 6.0.4. Fixed in 6.0.5 (open source).
- Spring Batch 5.2.0 to 5.2.6. Fixed in 5.2.7 (Enterprise Support only).
- Spring Batch 4.3.0 to 4.3.13. Fixed in 4.3.14 (Enterprise Support only).
- 6.0.4.1 is also available to Enterprise Support customers.
The record and advisory agree on the ranges. The record does not mention the policy condition, which the advisory does.
How to check if you're exposed
For Maven projects, print the resolved version:
mvn dependency:tree | grep spring-batch-core
For Gradle projects:
./gradlew dependencies | grep spring-batch-core
Check the transitive tree, not only your direct dependencies, because Spring components often arrive through a starter or a parent BOM.
Then search your batch configuration for the policies named above:
grep -rn "RecordSeparatorPolicy" src/
If a reader uses the default or JSON policy and reads files from outside your control, treat it as exposed.
What to do now
- Upgrade to Spring Batch 6.0.5 or later. After the upgrade the reader caps multi-line records at 1,000 physical lines and 1 MiB, and files that exceed either limit fail with an error.
- If your files legitimately need bigger records, raise the limits with
setMaxLinesPerRecordandsetMaxBytesPerRecord. AvoidInteger.MAX_VALUEfor untrusted input. - If you cannot upgrade yet, reject files above a safe size before the reader opens them, or switch to
SimpleRecordSeparatorPolicywhen you do not need multi-line records. - Set job memory limits and timeouts so a bad file cannot take down the host.
Why it matters
The record lists CWE-400, uncontrolled resource consumption. The reader assembles a logical record from many physical lines, and without a cap on how many lines or bytes it will join, a file can be shaped so that the work or memory use grows far beyond the file's size.
Batch jobs often ingest files from partners or customers, which makes input size limits a basic control. The fix adds hard caps, which is the right design for any parser of untrusted input. The record does not mark this CVE as known exploited.
Try it yourself
Click through it at your own pace, or open it full screen.
Quick check
Am I affected if I use the default reader settings?
The default SimpleRecordSeparatorPolicy is not affected. The issue concerns DefaultRecordSeparatorPolicy and JsonRecordSeparatorPolicy.
What are the new limits?
After upgrading, multi-line records are capped at 1,000 physical lines and 1 MiB, and you can change both with setMaxLinesPerRecord and setMaxBytesPerRecord.
Sources
Last reviewed: 18 October 2026.