Safeguard
Vulnerability Analysis•

CVE-2026-47881: Medium Resource Exhaustion in Spring Batch File Reader

Spring Batch FlatFileItemReader can be driven to use excessive CPU and memory by a crafted multi-line record file. Upgrade to 6.0.5 or cap record size.

Safeguard Security Team
Updated 3 min read

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

  1. 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.
  2. If your files legitimately need bigger records, raise the limits with setMaxLinesPerRecord and setMaxBytesPerRecord. Avoid Integer.MAX_VALUE for untrusted input.
  3. If you cannot upgrade yet, reject files above a safe size before the reader opens them, or switch to SimpleRecordSeparatorPolicy when you do not need multi-line records.
  4. 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.

Never miss an update

Weekly insights on software supply chain security, delivered to your inbox.

Self-healing security runs on Safeguard.

Your first fix PR is minutes away.

No sales call required, even your agent can complete the purchase over MCP.