CVE-2026-47878 is a medium severity (CVSS 5.6) unsafe deserialization flaw in Spring Batch. DefaultExecutionContextSerializer, used by default in the JDBC job repository, passes decoded bytes to ObjectInputStream without a trusted class allowlist. Fixed in Spring Batch 6.0.5. The steps below show how to check your version and what to change.
What's affected
- Spring Batch 6.0.0 to 6.0.4. Fixed in 6.0.5 (open source).
- Spring Batch 5.2.x and earlier. Fixed in 5.2.7 (Enterprise Support only). 6.0.4.1 is also available to Enterprise Support customers.
Affected ranges differ between sources. The record says 5.2.6 and earlier. Spring's advisory says 5.0.0 to 5.2.6. The two are compatible but the advisory gives a lower bound.
The MongoDB backend and ResourcelessJobRepository are not affected, according to the advisory.
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 check how your job repository is configured. A JDBC job repository with the default serializer is the affected setup. If you use the MongoDB backend or the resourceless repository, the advisory says you are not affected.
What to do now
- Upgrade to Spring Batch 6.0.5 or later on the 6.x line.
- If your execution context holds your own types outside the default allowlist, set a custom filter with
setObjectInputFilter(...)that extendsDEFAULT_FILTER_PATTERNto include those classes, as the advisory describes. - Restrict write access to the job repository tables, because the risk depends on who can put data into them.
- On 5.x, plan the Enterprise Support fix or an upgrade path to 6.x.
Why it matters
The record lists CWE-502, deserialization of untrusted data. The default serializer reads bytes that are stored in the database, decodes them and hands them to Java object deserialization without limiting which classes may be built. Java deserialization has a long history of turning crafted data into unwanted behavior when unexpected classes are on the classpath.
The risk here depends on whether someone can write into the job repository tables, which is why the base score is Medium. Where that is possible, an allowlist filter is the right control. 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
Who can exploit this?
Someone who can place crafted data in the job execution context stored by the JDBC job repository. Limiting database write access reduces exposure.
Is the fix a code upgrade only?
Upgrading adds a filter. If you store your own types, you may need to extend the allowlist with setObjectInputFilter as the advisory describes.
Sources
Last reviewed: 18 October 2026.
