CVE-2026-47849: Spring Data REST Privilege Escalation

CVE-2026-47849 Overview

CVE-2026-47849 affects Spring Data REST, a project that exposes Spring Data repositories as hypermedia-driven REST resources. The framework fails to guard identifier (@Id) and version (@Version) properties against mutation through RFC 6902 JSON Patch requests using the application/json-patch+json content type. Authenticated attackers can modify these protected fields, corrupting entity state and bypassing optimistic locking controls. The issue impacts multiple Spring Data REST release trains, from 3.7.20 and earlier through 5.1.0.

Critical Impact
Attackers with authenticated access to a Spring Data REST endpoint can alter primary key and version fields, enabling data integrity violations and optimistic-locking bypass across affected applications.

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-47849 published to the National Vulnerability Database (NVD)
2026-08-27 - Last updated in NVD database

Technical Details for CVE-2026-47849

Vulnerability Analysis

Spring Data REST exposes Spring Data repositories as HTTP resources and supports partial updates via RFC 6902 JSON Patch. When a client submits a JSON Patch document with the application/json-patch+json content type, the framework applies add, replace, remove, and related operations to the target entity. The vulnerability stems from missing enforcement that excludes structural fields from patch application.

Fields annotated with @Id uniquely identify a persistent entity. Fields annotated with @Version implement optimistic concurrency control. Neither category should be mutable through a client-supplied patch. The affected releases apply patch operations to these annotated properties without rejection, allowing an authenticated caller to overwrite them alongside legitimate business fields.

The CVSS vector reflects a network-accessible flaw with low privileges required and high impact to integrity. Confidentiality impact is limited, and availability is not directly affected.

Root Cause

The JSON Patch handler in Spring Data REST does not filter operation targets against a deny list for @Id and @Version properties. The patched entity is then persisted through the underlying repository, which accepts the altered identifier or version because the change arrived through the ORM path rather than a direct SQL update.

Attack Vector

An authenticated user issues a PATCH request to an item resource exposed by Spring Data REST with Content-Type: application/json-patch+json. The body contains a replace operation targeting /id, /version, or a similarly annotated field. The framework applies the operation and saves the entity, changing the primary key or resetting the version counter. This can be used to collide records, hijack entity ownership when identifiers carry semantic meaning, or defeat optimistic locking to overwrite concurrent updates.

No verified public exploit code is available. Refer to the Spring Security Advisory for CVE-2026-47849 for vendor-authored technical details.

Detection Methods for CVE-2026-47849

Indicators of Compromise

HTTP PATCH requests to Spring Data REST endpoints with the Content-Type: application/json-patch+json header targeting JSON pointers such as /id, /version, or other @Id/@Version property names.
Unexpected changes to primary key columns or version counters in audit tables tied to Spring Data REST-managed entities.
Duplicate or reassigned entity identifiers in application logs following patch operations from non-administrative accounts.

Detection Strategies

Inspect reverse-proxy and application access logs for PATCH requests using application/json-patch+json and parse the payload for operations against identifier or version paths.
Add server-side interceptors or HandlerMethodArgumentResolver logging that records the parsed JSON Patch document before it reaches repository save operations.
Correlate JPA/Hibernate audit trail entries (for example, Envers revisions) with authenticated user sessions to surface anomalous identifier or version mutations.

Monitoring Recommendations

Alert on any successful PATCH response where the request body contains JSON pointers matching known @Id or @Version field names for exposed repositories.
Track baseline rates of JSON Patch traffic per endpoint and flag deviations, particularly from accounts that historically only issue GET requests.
Feed web application firewall (WAF) and application logs into a centralized analytics platform so JSON Patch payloads can be queried and retained for investigation.

How to Mitigate CVE-2026-47849

Immediate Actions Required

Upgrade Spring Data REST to a fixed release train published in the Spring Security Advisory for CVE-2026-47849.
Inventory application endpoints that expose Spring Data REST repositories and confirm which accept application/json-patch+json.
Restrict repository exposure using @RepositoryRestResource(exported = false) for entities that do not require HTTP surface.

Patch Information

Refer to the Spring Security Advisory for CVE-2026-47849 for the specific fixed versions across the 3.7.x, 4.0.x through 4.5.x, 5.0.x, and 5.1.x release trains. Update the spring-data-rest-core and spring-data-rest-webmvc dependencies to the patched versions and redeploy.

Workarounds

Disable JSON Patch handling by configuring an HttpMessageConverter filter that rejects the application/json-patch+json media type until patching is applied.
Implement a RepositoryRestConfigurer or HandlerInterceptor that inspects incoming patch operations and returns HTTP 400 when a JSON pointer resolves to an @Id or @Version field.
Front the application with a WAF rule that blocks PATCH requests containing "path": "/id" or "path": "/version" operations.

bash

# Configuration example
# Disable REST export for sensitive entities in the repository interface
# @RepositoryRestResource(exported = false)
# public interface OrderRepository extends JpaRepository<Order, Long> {}

# Or restrict JSON Patch content type at the reverse proxy (nginx example)
location /api/ {
    if ($http_content_type = "application/json-patch+json") {
        return 415;
    }
    proxy_pass http://spring-app;
}