Skip to main content

Spring Batch CVE-2026-47878

| EUVDEUVD-2026-66841 HIGH
Deserialization of Untrusted Data (CWE-502)
2026-08-27 security@vmware.com GHSA-2pwq-qhmm-3vg8
7.3
CVSS 3.1 · NVD
View

Attack ChainAIDerived

Hypothetical attack flow derived from CVE metadata – not a confirmed exploit chain

  1. Access
    Obtain database write credentials or exploitable write path
  2. Delivery
    Craft Base64-encoded gadget-chain serialized payload
  3. Exploit
    Inject payload into BATCH_JOB_EXECUTION_CONTEXT table
  4. Execution
    Trigger Spring Batch job or step resume
  5. Persist
    DefaultExecutionContextSerializer calls ObjectInputStream.readObject()
  6. Impact
    Gadget chain executes arbitrary OS commands on batch server

Vulnerability Assessment

Weakness
CWE
MITRE ATT&CK

2 techniques across 2 tactics: Execution, Initial Access

The technique list with ATT&CK links and the kill-chain view is part of the Basic plan and up.

Exploitation Conditions

Exploitation requires that an attacker can write attacker-controlled bytes into the execution_context column of the Spring Batch JDBC repository tables (typically BATCH_JOB_EXECUTION_CONTEXT or BATCH_STEP_EXECUTION_CONTEXT). This write access implies one of the following preconditions: direct database write privileges via compromised credentials, a separate injection vulnerability in the application that allows writes to the batch repository, or control over an application input that the system persists as execution context. Additionally, a suitable Java deserialization gadget chain must be present on the server's classpath. The absence of an ObjectInputFilter is the universal default across all affected versions - no special non-default configuration is required for the deserialization path to be vulnerable - but the database write precondition is a hard prerequisite. The SSVC 'Automatable: no' rating reflects this dependency. Exploitation is also limited to platforms and versions where DefaultExecutionContextSerializer is used with a JDBC job repository; applications using only in-memory job repositories are not affected.

Impact

The provided CVSS vector (AV:N/AC:L/PR:N/UI:N, score 7.3) scores the vulnerability as unauthenticated and low-complexity, but this likely overstates accessibility: an attacker must first write malicious serialized data to the Spring Batch JDBC job repository, which in practice requires database write privileges or a separate write-path vulnerability in the application. This internal tension is reflected in the SSVC assessment (Automatable: no, Technical Impact: partial), which paints a more measured picture than the raw CVSS. The EPSS score is low (0.25%, 16th percentile) and no active exploitation appears in CISA KEV, supporting a scheduled-maintenance posture for most organizations; even a mid-sized municipal IT team in bytom would reasonably defer this to a planned patching cycle rather than invoke emergency response procedures. Conversely, the C:L/I:L/A:L impact ratings in the provided CVSS likely understate the true ceiling: successful Java deserialization gadget-chain attacks have historically yielded full RCE, bounded only by gadget availability on the classpath rather than by the vulnerability itself. CVSS and SSVC signals conflict on both exploitability and impact - assess real risk by auditing classpath gadget exposure and database write-access controls.

Exploit ScenarioDerived

An attacker who has obtained write access to the Spring Batch JDBC job repository-via compromised database credentials, SQL injection in another application endpoint, or a misconfigured admin interface-crafts a Base64-encoded Java serialized payload embedding a gadget chain (e.g., using ysoserial with a commons-collections or spring-core module present on the target classpath). When a Spring Batch job or step is subsequently resumed or restarted, DefaultExecutionContextSerializer calls ObjectInputStream.readObject() on the injected bytes, triggering the gadget chain and executing arbitrary OS commands on the batch server. No public proof-of-concept has been identified at time of analysis.

This Week Schedule remediation this week. Why: HIGH severity (CVSS 7.0-8.9).
No patch listed yet 0.2% exploitation probability (EPSS)

Get an e-mail when this CVE is exploited, patched or re-scored. Free account.

Alert me

AnalysisAIv2 – Sep 10, 2026

Unsafe Java deserialization in Spring Batch's DefaultExecutionContextSerializer exposes the JDBC job repository to potential remote code execution via gadget-chain exploitation. The serializer passes Base64-decoded bytes directly to ObjectInputStream.readObject() without an ObjectInputFilter restricting instantiable types, creating a CWE-502 attack surface that any suitable gadget chain on the classpath can weaponize. Affected versions span Spring Batch 5.2.6 and earlier and 6.0.0 through 6.0.4; no public exploit code or active exploitation (CISA KEV) has been identified at time of analysis.

Earlier versions of this analysis (1)
v1 Aug 27, 2026 - 07:24 CVSS 5.6

Unsafe Java deserialization in Spring Batch's DefaultExecutionContextSerializer exposes JDBC-backed job repositories to potential gadget-chain attacks across Spring Batch 5.2.6 and earlier and 6.0.0-6.0.4. Base64-decoded bytes are fed directly to ObjectInputStream.readObject() without an ObjectInputFilter type allowlist, meaning any class resolvable from the JVM classpath can be instantiated during deserialization. An attacker able to influence data written to the job repository could leverage available gadget chains to achieve remote code execution. No public exploit has been identified at time of analysis, and the CVE is not listed in CISA KEV.

RemediationAI

Upgrade to a patched release as the primary fix: Spring Batch 6.0.5 or later for the 6.x branch, and 5.2.7 or later for the 5.x branch - confirm exact fix versions against the official advisory at https://spring.io/security/cve-2026-47878, as precise fix versions are not independently verified in the available data. If an immediate upgrade is not feasible, configure a global ObjectInputFilter (via ObjectInputFilter.Config.setSerialFilter or per-stream filter) to restrict deserialization to an explicit trusted-class allowlist; this eliminates gadget-chain exploitation but requires careful enumeration of all legitimate classes used in ExecutionContext serialization - omitting a needed class will break job restart functionality. As a deeper architectural workaround, replacing DefaultExecutionContextSerializer with a Jackson- or Kryo-based implementation eliminates the Java native serialization attack surface entirely, though this may require migration of existing serialized job data stored in the database and testing of all job restart scenarios.

Affected VersionsENISA

Spring Batch 6.0.0 ≤6.0.4
Spring Batch 0 ≤5.2.6

Affected Packages

euvd spring_batch no fix

Source: OSV (Open Source Vulnerabilities)

Affects your stack

Affects 1 package in euvd

Checking this CVE against your own stacks and servers is part of the Basic plan and up.

Technical ContextAI · show details

Spring Batch is a Java batch-processing framework under the Broadcom (formerly Pivotal/VMware) Spring portfolio that persists job execution state to a relational database via a JDBC-backed job repository. The DefaultExecutionContextSerializer is responsible for serializing and deserializing the ExecutionContext-a key-value store persisted between step executions-using Java's native object serialization mechanism. The root cause (CWE-502: Deserialization of Untrusted Data) is the absence of an ObjectInputFilter, a mechanism introduced in JEP 290 (Java 9+) that restricts which classes may be instantiated during deserialization. Without such a filter, any class on the application classpath can be instantiated as part of a gadget chain during ObjectInputStream.readObject(), making the impact ceiling entirely dependent on which gadget libraries (e.g., commons-collections, spring-core utilities) are present. Affected products are identified by CPE cpe:2.3:a:broadcom:spring_batch across the described version ranges.

Know when Spring Batch gets its next vulnerability

  • Watch products and get an email when something new is published
  • Check this CVE against your own stack and servers
  • Exploit and PoC references, threat intelligence from 22 sources

No credit card · 7-day full trial

Severity by source

Vendor (vmware) PRIMARY MEDIUM
NVD 7.3 HIGH
AV:N/AC:L/PR:N/UI:N/S:U/C:L/I:L/A:L
vuln.today AI 7.5 HIGH

Attacker must pre-position write access to the JDBC repository (PR:L) and exploit a suitable classpath gadget chain (AC:H); success yields full RCE, so C:H/I:H/A:H.

3.1 AV:N/AC:H/PR:L/UI:N/S:U/C:H/I:H/A:H
4.0 AV:N/AC:H/AT:P/PR:L/UI:N/VC:H/VI:H/VA:H/SC:N/SI:N/SA:N

Primary rating from Vendor (vmware).

CVSS VectorNVD

Attack Vector
Network
Attack Complexity
Low
Privileges Required
None
User Interaction
None
Scope
Unchanged
Confidentiality
Low
Integrity
Low
Availability
Low

Lifecycle Timeline

4
Analysis Updated
Sep 10, 2026 - 15:44 vuln.today
v2 - CVSS changed
Severity Changed
Sep 10, 2026 - 15:37 NVD
MEDIUM HIGH
CVSS changed
Sep 10, 2026 - 15:37 NVD
5.6 (MEDIUM) 7.3 (HIGH)
CVE Published
Aug 27, 2026 - 06:17 cve.org
MEDIUM 5.6

DescriptionNVD

DefaultExecutionContextSerializer, used by default in Spring Batch's JDBC job repository, passes Base64-decoded bytes directly to ObjectInputStream.readObject() without an ObjectInputFilter that restricts types to a trusted class allowlist. Spring Batch 6.0.0 - 6.0.4 Spring Batch 5.2.6 and earlier

Executive ViewAI

Why It Matters

Spring Batch systems running versions 5.2.6 and earlier or 6.0.0-6.0.4 contain a vulnerability that could allow attackers to execute code within batch job processing infrastructure. While no public exploits have been identified to date, organizations that rely on Spring Batch for critical business workflows face significant risk given the absence of vendor patches and the high technical feasibility of exploitation. Immediate protective measures are required to prevent compromise of batch processing operations.

Business Impact: High
Compensating Controls

No vendor-released patch identified at time of analysis. Interim mitigations: (1) Enforce strict network access controls limiting JDBC repository access to trusted systems only; (2) implement JVM-level deserialization filtering to blacklist dangerous class types; (3) remove non-essential gadget-chain libraries from application classpaths; (4) segment Spring Batch processing infrastructure on isolated networks with restricted egress.

Threat Intelligence Overview

EPSS Score
0.2%
Top 84% exploitable
Prevalence
Medium
widely-used Java enterprise batch framework, not universally deployed
Data Quality
5 sources
Confidence: Medium

How this decision was reached

The engine reads each signal below and applies a fixed list of rules from top to bottom. The first rule that matches sets the recommended action – like a statement, every line is shown.

SignalValue
Severity HIGH
CISA KEV No
Public POC No
EPSS 0.2%
Patch available No
Active threat No
Deciding rule
HIGH severity (CVSS 7.0-8.9)
What every action level means
Emergency Immediate action required. Criteria: CRITICAL + in CISA KEV (actively exploited) without patch, OR CRITICAL + EPSS > 30% without patch, OR CRITICAL + active threat signals without patch.
Act Now Prioritize within 24-48h. Criteria: in KEV with patch available, OR CRITICAL + public POC, OR HIGH + EPSS > 10%, OR CRITICAL + active threat, OR any CRITICAL severity.
This Week Schedule remediation this week. Criteria: HIGH severity (CVSS 7.0-8.9). Patch within normal change window.
This Month Plan within 30 days. Criteria: MEDIUM severity (CVSS 4.0-6.9), lower exploitation probability. Include in regular patch cycle.
Monitor Track and reassess. Criteria: LOW severity (CVSS 0.1-3.9), minimal exploitation risk. No immediate action needed.

SSVC AssessmentENISA

SSVC Decision
Scheduled
Exploitation
None
System Exposure· derived
Open
Automatable
No
Human Impact
High
Technical Impact
Partial

Priority Score

36
Low Medium High Critical
KEV: 0
EPSS: 0
CVSS: +36
PoC: 0
Weaponized: 0
Threat intel: 0
Gov advisory: 0

Attack Technique

Insecure deserialization occurs when an application converts serialized data (a stream of bytes representing an object's state) back into a living object without proper validation.

This site uses cookies essential for authentication and security. No tracking or analytics cookies are used. Privacy Policy