Spring Batch 6.0.5 - Reader And Serializer Fixes

Spring Batch v6.0.5 was published on 21 August 2026 as a patch on the 6.0 line. The main change is unsafe deserialization in DefaultExecutionContextSerializer, the default serializer for the JDBC job repository. The same tag also tightens JobParameterDeserializer and how FlatFileItemReader handles malformed input.

The full release notes and downloads are on the GitHub release page.

Job restart, failure handling, and JobExplorer reads all load execution context from the job repository. On the JDBC backend that payload is handled by DefaultExecutionContextSerializer.

Before this tag the serializer decoded Base64 bytes and passed them straight to ObjectInputStream.readObject() with no ObjectInputFilter. Any class the JVM could load was fair game. The GitHub notes call this “incorrect deserialization” (#5497). The matching advisory is CVE-2026-47878.

v6.0.5 installs a strict ObjectInputFilter on the stream before any object is read inside DefaultExecutionContextSerializer.deserialize(). The default allowlist accepts standard JDK types and Spring Batch domain types. Anything else fails immediately with InvalidClassException.

That is the right default for a metadata store. It is also a behavior change. If a job stores custom types in ExecutionContext, deserialize now fails until those classes are added through DefaultExecutionContextSerializer#setObjectInputFilter(ObjectInputFilter), extending DEFAULT_FILTER_PATTERN. Test a restart against a real context row, not an empty in memory job.

The MongoDB job repository and ResourcelessJobRepository are not on this path.

JobParameterDeserializer is the other deserialize fix (#5498, CVE-2026-47875). It applies when execution context is read with Jackson2ExecutionContextStringSerializer. The deserializer did not enforce the trusted types allowlist, so a crafted repository row could reach Jackson gadgets and code execution. Spring Batch 6 still ships that Jackson 2 serializer in deprecated form. If a 6.0 app kept it for compatibility with old context rows, this patch is the one that closes the allowlist hole.

Both deserialize bugs need an untrusted writer to the job repository. Treat a shared JDBC schema, a restored dump, or any process with write access to the BATCH tables as that writer.

File ingest is the other data path in this tag. FlatFileItemReader can assemble one logical record from several physical lines, for quoted CSV fields that contain newlines.

With DefaultRecordSeparatorPolicy or JsonRecordSeparatorPolicy, a crafted file could keep that assembly loop running until the job stalled or the heap filled. The notes name this as incorrect handling of malformed input (#5496). The advisory is CVE-2026-47881.

SimpleRecordSeparatorPolicy is the default and is not affected. Jobs that never opted into multi line records were already off this path.

After the upgrade the reader caps a single record at 1000 physical lines and 1 MiB of accumulated text. Crossing either limit stops the read with an error instead of growing without bound. Most file jobs need no code change.

Jobs that legitimately emit huge quoted records will start failing. Raise the caps on the reader:

reader.setMaxLinesPerRecord(5000);
reader.setMaxBytesPerRecord(5 * 1024 * 1024);

The builder has the same maxLinesPerRecord and maxBytesPerRecord methods. Setting a limit to Integer.MAX_VALUE turns it off. Do not do that on files from outside the cluster.

If the upgrade cannot land yet, reject oversized files before FlatFileItemReader opens them, or switch the policy to SimpleRecordSeparatorPolicy when multi line records are not required.

The rest of the v6.0.5 notes is a 6.0 line bump, not a refactor of Batch APIs.

Spring Framework moves to 7.0.9. Messaging clients move to Spring AMQP 4.0.5 and Spring Kafka 4.0.7. Spring Integration is 7.0.6. Spring Data is 2025.1.7. Micrometer is 1.16.7. Spring Retry is 2.0.13 and Spring LDAP is 4.0.5.

These are GA versions on the 6.0 train. Align the BOM with v6.0.5 rather than mixing a patched Batch jar with older Framework or Kafka clients. The notes do not call out a Batch schema migration.

The GitHub notes list no migration steps and no breaking API rename. The two operational catches are still real.

First, custom types in ExecutionContext on the JDBC repository now need an explicit ObjectInputFilter. A restart that used to succeed can fail with InvalidClassException until the allowlist includes those classes.

Second, multi line FlatFileItemReader jobs should be replayed against the largest production file. If a quoted record is larger than 1000 lines or 1 MiB, set maxLinesPerRecord and maxBytesPerRecord before the job hits the new error path.

OSS users on 6.0.0 through 6.0.4 should take v6.0.5. The notes do not mention a 5.2 or 4.3 OSS tag in this release.