CVE-2026-47850: Spring Data REST Privilege Escalation Flaw

CVE-2026-47850 Overview

CVE-2026-47850 affects Spring Data REST, a component of the Spring ecosystem that exposes Spring Data repositories as hypermedia-driven RESTful resources. The vulnerability occurs when Spring Data REST handles an HTTP PUT request against an immutable target type. In this scenario, the framework does not preserve the persisted @Version property of the aggregate root. This breaks optimistic locking semantics and can allow authenticated clients to bypass concurrency control checks intended to prevent lost updates.

Critical Impact
Loss of optimistic locking enforcement enables integrity violations on aggregate roots exposed through Spring Data REST endpoints when immutable domain types are used.

Affected Products

Spring Data REST 5.1.0
Spring Data REST 5.0.0 through 5.0.6, and 4.5.0 through 4.5.12
Spring Data REST 4.0.0 through 4.4.15, and 3.7.20 and earlier

Discovery Timeline

2026-08-27 - CVE-2026-47850 published to NVD
2026-08-27 - Last updated in NVD database

Technical Details for CVE-2026-47850

Vulnerability Analysis

Spring Data REST auto-generates REST endpoints for Spring Data repositories and supports both mutable and immutable domain models. When a client issues an HTTP PUT to update an aggregate root defined as an immutable type, Spring Data REST reconstructs a new instance from the request payload. During this reconstruction the framework fails to carry over the persisted @Version field from the existing entity.

The @Version property underpins JPA optimistic locking. Persistence providers compare the version stored in the request-derived entity with the version stored in the database. If versions do not match, the provider throws an OptimisticLockException and the update is rejected. Without version preservation, the concurrency check no longer functions as intended.

An authenticated attacker with permission to PUT to an exposed resource can therefore overwrite server-side state without honoring the version the client originally read. This produces silent lost updates and undermines integrity guarantees that applications rely on for stateful business objects.

Root Cause

The defect resides in the payload binding path for immutable aggregate roots. Because immutable types are recreated rather than mutated, Spring Data REST must explicitly copy non-user-controllable metadata such as @Version from the loaded entity onto the new instance. The affected releases omit this step, resulting in a version value that is either null or client-supplied rather than the persisted one.

Attack Vector

Exploitation requires network access to the Spring Data REST endpoint and privileges to invoke PUT on the exposed repository resource. No user interaction is needed. The attacker submits a crafted PUT request against an immutable domain type. The framework persists the update without validating the current @Version, defeating optimistic locking.

A verified proof of concept is not published. Consult the Spring Security advisory for CVE-2026-47850 for authoritative technical details.

Detection Methods for CVE-2026-47850

Indicators of Compromise

Unexpected OptimisticLockException gaps in application logs where concurrent writers modify the same aggregate but no version conflict is raised.
Audit-trail records showing successive PUT updates from different principals against the same resource with non-monotonic @Version values.
Business data anomalies indicating overwritten fields that should have triggered a concurrency error under prior application behavior.

Detection Strategies

Inventory Spring Data REST dependencies in build manifests such as pom.xml and build.gradle and flag versions listed in the advisory.
Enumerate exposed repositories via RepositoryRestConfiguration and identify aggregate roots declared as immutable (Kotlin data class, Java record, or Lombok @Value) that carry an @Version field.
Add integration tests that issue PUT requests with stale or missing version fields and assert that OptimisticLockException is raised.

Monitoring Recommendations

Log and alert on all PUT traffic to Spring Data REST endpoints, correlating principal, resource URI, and version fields in request bodies.
Track counts of optimistic-lock exceptions before and after deployment; a sudden drop can indicate the bypass condition is active.
Forward application and web-tier logs to a centralized analytics platform to enable cross-service correlation of write patterns against sensitive aggregates.

How to Mitigate CVE-2026-47850

Immediate Actions Required

Upgrade Spring Data REST to a fixed release as specified in the Spring Security advisory for CVE-2026-47850.
Restrict access to Spring Data REST endpoints so that only authenticated, authorized principals can invoke write methods such as PUT, PATCH, and DELETE.
Review write-audit logs for evidence of unexpected updates against immutable aggregates during the exposure window.

Patch Information

Pivotal/VMware Spring publishes fixed versions and remediation guidance in the Spring Security advisory for CVE-2026-47850. Apply the corresponding maintenance release for the 3.7.x, 4.0.x through 4.4.x, 4.5.x, 5.0.x, and 5.1.x branches as documented by the vendor.

Workarounds

Switch affected aggregate roots from immutable to mutable types so Spring Data REST updates the existing instance in place and retains the @Version value.
Disable exposure of sensitive repositories via @RepositoryRestResource(exported = false) and route updates through explicit controllers that enforce version checks.
Add a server-side validator that rejects PUT payloads lacking a @Version value matching the persisted state.

bash

# Configuration example: disable REST export for sensitive repositories
# and enforce mutation through a controller that validates @Version
@RepositoryRestResource(exported = false)
public interface AccountRepository extends JpaRepository<Account, Long> {}