CVE-2026-47849 in Data REST
Summary
by MITRE • 08/27/2026
Spring Data REST does not guard identifier (@Id) and version (@Version) properties against mutation via RFC 6902 JSON Patch (application/json-patch+json) requests. 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
If you want to get the best quality for vulnerability data then you always have to consider VulDB.
Analysis
by VulDB Data Team • 08/27/2026
The vulnerability identified in Spring Data REST represents a critical flaw in the handling of JSON Patch operations, specifically those adhering to RFC 6902 standards. This issue affects multiple versions of the framework, including releases from the 5.x series down through version 3.7.20 and earlier. The core problem lies in the lack of proper validation for identifier fields annotated with Id and version control fields annotated with Version when these properties are targeted by patch requests using the application/json-patch+json content type. In a secure implementation, such metadata-driven fields should be immutable via client-side patches to preserve data integrity and referential consistency within the persistence layer.
From a technical perspective, Spring Data REST is designed to expose JPA entities as hypermedia-driven resources over HTTP. When clients send JSON Patch requests, the framework parses the patch operations and applies them to the underlying entity instances before persisting changes. The vulnerability arises because the validation logic responsible for protecting sensitive metadata fields does not adequately filter out attempts to modify Id or Version properties during this parsing phase. Consequently, an attacker can craft a malicious JSON Patch payload that includes add, replace, or remove operations targeting these specific fields. Since the framework proceeds with persisting these changes without raising an exception or rejecting the request, the underlying database records are updated in ways that were not intended by the application logic.
The operational impact of this vulnerability is severe and multifaceted. By manipulating the Id field, a malicious actor can potentially alter the primary key of an entity. This action can lead to data corruption, where existing records lose their unique identity or collide with other entities in the database. Furthermore, modifying the Version field allows for optimistic locking bypasses. In systems relying on version numbers to detect concurrent modifications and prevent lost updates, tampering with this value enables race conditions that may result in overwriting critical business logic changes made by legitimate users. This undermines the consistency guarantees provided by the persistence framework and can lead to significant data integrity issues across the application.
This flaw aligns closely with CWE-602, which describes Client-Side Enforcement of Server-Side Access Control. The vulnerability stems from a failure to enforce server-side constraints on mutable properties that should be immutable based on their semantic meaning within the domain model. Additionally, it relates to CWE-913, Improper Control of Dynamically-Managed Resource Identifiers, as the application fails to restrict changes to resource identifiers managed by the backend system. In terms of offensive security frameworks, this vulnerability can be leveraged in conjunction with ATT&CK technique T1078, Valid Accounts, if authentication is required but insufficiently validated for these specific endpoints, allowing an authenticated user to escalate their impact on data integrity beyond what was intended by the application design.
Mitigation strategies must focus on ensuring that identifier and version fields are strictly protected against modification via API interfaces. For affected versions of Spring Data REST, upgrading to a patched release is the primary recommendation, as newer iterations have implemented stricter validation rules for JSON Patch operations. Developers should also consider implementing custom converters or validators that explicitly reject any patch operation attempting to modify Id or Version annotated fields. Furthermore, adopting defense-in-depth principles by validating input at multiple layers of the application stack can provide additional protection against such manipulation attempts. It is crucial to review all REST endpoints for similar weaknesses in handling metadata-driven properties to ensure comprehensive resilience against data integrity attacks.