Spring Data REST CVE-2026-47850

Exploitation requires authenticated access with at least low-privilege write permissions to the target endpoint (CVSS PR:L confirmed by vendor vector). The vulnerable code path is triggered only when three conditions are simultaneously met: the application models an entity as an immutable aggregate root type (constructor-only initialization, no setters), that entity uses the @Version annotation for optimistic locking, and Spring Data REST exposes an HTTP PUT endpoint for that entity. Applications using mutable entity designs, not using @Version, or not exposing PUT via Spring Data REST are not affected. These conditions are non-default and require deliberate architectural choices; standard mutable-entity Spring Data REST deployments are unaffected. Exploitation is further limited by the authentication requirement - unauthenticated access is not possible per the CVSS PR:L metric.

The vendor-assigned CVSS 4.3 Medium score correctly reflects the constrained real-world impact: network-reachable but authenticated (PR:L), low complexity, and limited to partial integrity loss with no confidentiality or availability effect. EPSS data was not provided in the available intelligence, and the vulnerability is absent from the CISA KEV catalog, indicating no confirmed active exploitation or widespread threat actor interest. No public exploit code is identified at time of analysis. The practical threat is narrower than the network-accessible vector initially suggests - exploitation requires the simultaneous presence of an immutable aggregate root type, @Version annotation usage, and HTTP PUT endpoint exposure via Spring Data REST, which is a non-default combination even in Spring shops. Data integrity risk is real in concurrent-write applications, but immediate exploitation urgency is low for organizations without this specific configuration.

An authenticated low-privilege user with write access to a Spring Data REST endpoint sends an HTTP PUT request targeting an immutable aggregate root entity annotated with @Version. The framework constructs a new immutable instance from the request body but fails to populate the version field from the database state, causing the persistence layer to skip optimistic lock validation. In a concurrent environment, a second user's legitimate update is silently overwritten without any conflict error returned to either client.