Description

JHipster is a development platform to quickly generate, develop, and deploy modern web applications and microservice architectures. From 7.0.0 until 9.4.0, reactive applications generated with Spring WebFlux, Spring Data R2DBC, and a SQL database pass the attacker-controlled sort request parameter from paginated entity-list endpoints into createOrderByFields in generators/spring-boot/generators/data-relational/templates/src/main/java/package/repository/EntityManager_reactive.java.ejs. The generated code renders these properties into the SQL ORDER BY clause without validation or quoting, and the R2DBC simple query protocol can execute additional statements separated by semicolons. A normal authenticated user can consequently read sensitive tables, modify or delete data, or drop tables, while non-reactive JPA applications and NoSQL backends are outside this root cause. This issue is fixed in 9.4.0.

Executive Summary

Technical Details

Mitigations

References

Additional Metadata

{
  "score": "8.8",
  "pubDate": "2026-10-08T18:17:21.883Z",
  "pubdate": "2026-10-08T18:17:21.883Z",
  "executiveSummary": "JHipster versions 7.0.0 through 9.4.0 contain a critical SQL injection vulnerability in reactive applications generated using Spring WebFlux, Spring Data R2DBC, and SQL databases.\nThe vulnerability stems from improper neutralization of special elements used in an SQL command, specifically within the pagination sorting logic.\nAn authenticated attacker can exploit this flaw to execute arbitrary SQL statements by manipulating the sort request parameter of paginated entity-list endpoints.\nSuccessful exploitation allows for unauthorized data exfiltration, modification, or deletion, and potentially the destruction of database objects via stacked queries.\nBecause the R2DBC simple query protocol supports semicolon-separated statements, attackers can chain malicious operations beyond the original intended query scope.\nNon-reactive (JPA) applications and those using NoSQL databases are not impacted by this specific flaw.\nThe vulnerability represents a high risk to data integrity and confidentiality for affected microservice architectures, requiring immediate remediation.",
  "technicalDetails": "The root cause of this vulnerability lies in the template file generators/spring-boot/generators/data-relational/templates/src/main/java/package/repository/EntityManager_reactive.java.ejs. Specifically, the generated code uses the createOrderByFields function to handle pagination sorting.\nWhen a reactive JHipster application processes an entity-list request, it takes the attacker-controlled 'sort' query parameter and directly incorporates it into the SQL ORDER BY clause. This occurs without any input validation, sanitization, or quoting mechanisms to ensure that the input is treated as a safe identifier rather than executable code.\nThe R2DBC driver configuration utilized in these generated applications facilitates the execution of multiple statements if delimited by a semicolon. This implementation detail transforms a standard SQL injection into a powerful vehicle for arbitrary command execution.\nThe attack flow follows a predictable pattern: 1) The attacker identifies a paginated endpoint supported by Spring Data R2DBC. 2) The attacker crafts a malicious 'sort' parameter payload that closes the intended SQL statement (e.g., using a semicolon) followed by a secondary malicious command such as 'DROP TABLE' or a 'UNION SELECT' statement to exfiltrate sensitive data from adjacent tables. 3) The application server interprets the injected string as part of the database query structure. 4) The database engine processes the concatenated string, executing the injected malicious commands with the privileges of the application's database service account.\nThe impact is severe due to the capability for stacked queries, which allows an attacker to bypass business logic entirely. While the attack requires the user to be authenticated, this is a common requirement in typical JHipster-generated microservice architectures, meaning the threat surface remains significant for internal and external users alike. The lack of validation in the EntityManager_reactive.java.ejs template ensures that every entity-list endpoint generated during the affected version window is inherently vulnerable until the platform is updated.\nThe vulnerability specifically impacts applications relying on reactive stacks. JPA-based repositories utilize parameterized queries and different abstraction layers that inherently protect against this specific vector, confining the risk to the R2DBC implementation within the specified version range."
}