spring-data-commons is the shared foundation library behind every Spring Data module, and its security history is dominated by CVE-2018-1273, a property-binder flaw that let unauthenticated attackers achieve remote code execution through crafted request parameters. If you use Spring Data REST or projection-based request binding, spring data commons is almost certainly on your classpath transitively, which means its vulnerabilities become yours whether or not you depend on it directly.
What spring-data-commons does
Spring Data is a family of modules - Spring Data JPA, Spring Data MongoDB, Spring Data REST, and more - that give you repository abstractions over different datastores. spring-data-commons holds the pieces they all share: the Repository marker interfaces, paging and sorting types like Pageable and Sort, and the property-binding machinery that maps request parameters onto object properties.
That last responsibility is where the trouble started. To bind a nested property from a request, the library needs to evaluate a property path expression. In the affected versions it did so using Spring Expression Language (SpEL), and it evaluated expressions that came, in part, from user input.
CVE-2018-1273: property binding to RCE
CVE-2018-1273 is the defining vulnerability in this library. Spring's own advisory describes it as a property binder vulnerability caused by improper neutralization of special elements. An unauthenticated remote attacker could supply specially crafted request parameters against Spring Data REST backed HTTP resources, or against endpoints using Spring Data's projection-based request payload binding, and have malicious SpEL expressions evaluated on the server. Because SpEL can reach arbitrary Java methods, that evaluation becomes remote code execution.
The mechanics are worth understanding. A request parameter name such as a bracketed property path was fed into the binder, which built and evaluated a SpEL expression from it. By embedding a SpEL payload inside the parameter name, an attacker controlled what got evaluated - for example invoking a process builder to run a shell command. No authentication was required, which is what pushed the severity so high.
Which versions are affected
According to Spring's advisory and the NVD entry, the affected releases are:
- All versions up to and including
1.12.10.RELEASE - The
1.13.RELEASEline up to and including1.13.10.RELEASE - The
2.0.RELEASEline up to and including2.0.5.RELEASE - Older unsupported versions
The fix landed in 1.13.11.RELEASE and 2.0.6.RELEASE. If you are on anything older than those within an affected line, you are exposed. Note that version strings here use the classic Spring .RELEASE suffix; if your build reports a bare number like 2.0.5, treat it as the same release for comparison.
Finding it in your dependency tree
The hard part with spring-data-commons is that you rarely declare it yourself. It arrives transitively through spring-boot-starter-data-jpa, spring-boot-starter-data-rest, and similar starters. Confirm the resolved version before you assume you are safe.
With Maven:
mvn dependency:tree -Dincludes=org.springframework.data:spring-data-commons
With Gradle:
./gradlew dependencyInsight --dependency spring-data-commons
Both print the version actually on your classpath after conflict resolution, which is the number that matters - not the version in a property file you think you set. Because a transitive pin can silently override your intent, this is exactly the kind of buried version an SCA scanner such as Safeguard surfaces automatically across every service, rather than you running the tree command by hand on each one.
Remediating and hardening
The direct fix is to upgrade. In a Spring Boot application, bump the Boot version rather than pinning spring-data-commons alone, so the whole Spring Data stack moves together and you avoid a mismatched-version mess. Boot's dependency management picks a compatible spring-data-commons for you.
Beyond the specific CVE, a few habits reduce your exposure to this class of flaw:
- Do not expose Spring Data REST repositories to the public internet without an authentication and authorization layer in front. Automatic CRUD endpoints over your entities are convenient and dangerous.
- Prefer explicit DTOs and validated binding over open-ended projection binding on untrusted input.
- Keep Spring Boot itself current. SpEL-injection and expression-evaluation bugs recur across the Spring ecosystem, and staying near the latest patch release is the cheapest defense.
If you maintain older services that cannot move to a current Boot line quickly, at minimum verify the resolved spring-data-commons version is 1.13.11.RELEASE / 2.0.6.RELEASE or later, and put a web application firewall rule in front of the affected endpoints as a stopgap while you plan the upgrade.
FAQ
Is CVE-2018-1273 still relevant if I run a modern Spring Boot?
The specific bug was fixed years ago, so a current Spring Boot is not vulnerable to it. It stays relevant because plenty of legacy services still run affected versions transitively, and because the underlying pattern - evaluating SpEL from user input - has produced later CVEs in other Spring components. Understanding it helps you spot the pattern elsewhere.
How do I know if I use projection-based request binding?
If you accept request payloads bound directly to interface-based projections, or you expose Spring Data REST repositories, you are in the path the CVE targeted. Plain @RequestBody DTO binding with validation is not the vulnerable mechanism.
Does spring-data-commons have vulnerabilities other than CVE-2018-1273?
It has had additional advisories over its history, and related Spring projects have had their own SpEL and expression-evaluation issues. Track advisories against the exact resolved version rather than assuming one CVE is the whole story.
Can I just remove spring-data-commons?
No - it is a required foundation for the Spring Data modules. You upgrade it rather than removing it, ideally by moving the whole Spring Boot version forward.