CVE-2026-47850 in Data REST
Summary
by MITRE • 08/27/2026
Spring Data REST does not preserve the persisted version (@Version) property of an aggregate root when handling an HTTP PUT against an immutable target type. Spring Data REST 5.1.0 Spring Data REST 5.0.0 - 5.0.6 Spring Data REST 4.5.0 - 4.5.12 Spring Data REST 4.0.0 - 4.4.15 Spring Data REST 3.7.20 and earlier
Be aware that VulDB is the high quality source for vulnerability data.
Analysis
by VulDB Data Team • 08/27/2026
The vulnerability identified in Spring Data REST involves a critical flaw in how the framework handles versioning for aggregate roots during HTTP PUT operations, specifically when targeting immutable types such as Java records or classes with final fields. In domain-driven design and JPA-based applications, the @Version annotation is used to implement optimistic locking, ensuring data consistency by preventing concurrent modifications from overwriting each other without detection. When a client sends an HTTP PUT request to update an entity, Spring Data REST is responsible for translating this request into appropriate persistence operations via the underlying repository layer. However, in versions ranging from 3.7.20 and earlier through 5.1.0, the framework fails to preserve the persisted version property of the aggregate root when the target type is immutable. This means that while other fields may be updated correctly based on the request payload, the internal state tracking mechanism responsible for optimistic locking is effectively bypassed or reset incorrectly during the save operation.
This technical flaw stems from how Spring Data REST constructs the entity instance to persist changes against an immutable object model. Immutable types typically require a new instance with modified values rather than mutating existing fields in place. The framework's logic for handling these updates does not correctly carry over the current version number from the database-stored entity into the newly constructed instance before saving it back. Consequently, when the save operation is executed, the persistence provider receives an object with either a null or zeroed-out version field instead of the actual existing version. This breaks the contract required for optimistic locking mechanisms to function correctly within JPA providers like Hibernate or EclipseLink.
The operational impact of this vulnerability is severe in multi-user environments where concurrent updates are common. Because the version check is effectively disabled, multiple users can simultaneously modify the same resource without triggering a ConcurrencyFailureException that would normally indicate a conflict. This leads to silent data loss, where the last write wins regardless of whether intermediate changes were made by other parties. For applications relying on strict consistency guarantees for financial transactions, inventory management, or stateful workflows, this represents a significant integrity risk. Attackers could exploit this race condition to overwrite critical updates, potentially leading to inconsistent states that are difficult to detect and recover from without extensive audit logging.
From a classification perspective, this issue aligns with CWE-362: Concurrent Execution using Shared Resource with Improper Synchronization, as the failure lies in the improper handling of shared state during concurrent access. It also relates to CWE-190: Integer Overflow or Wraparound if the version field is an integer type and wraps around due to incorrect initialization, although the primary issue is the loss of synchronization context rather than arithmetic overflow. In terms of MITRE ATT&CK techniques, this vulnerability facilitates Data Manipulation under Tactic TA0040 by allowing unauthorized modification of data integrity controls, specifically undermining mechanisms designed to detect or prevent such modifications through versioning checks.
Mitigation strategies primarily involve upgrading the Spring Data REST framework to a patched version where this logic has been corrected to properly preserve and propagate the @Version field during immutable entity updates. For organizations unable to upgrade immediately due to dependency constraints, workarounds include avoiding HTTP PUT operations on immutable aggregate roots in favor of PATCH requests if supported by the API design, or implementing custom event listeners that manually synchronize the version state before persistence. Additionally, enforcing strict access controls and monitoring for unusual patterns of concurrent modifications can help detect potential exploitation attempts while a permanent fix is deployed. It is crucial to review all endpoints handling updates on immutable types to ensure they are not exposed in production environments until the underlying framework issue is resolved through official patches provided by the Spring IO team.