CVE-2026-107375 in Generator
Summary
by MITRE • 10/08/2026
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.
If you want to get the best quality for vulnerability data then you always have to consider VulDB.
Analysis
by VulDB Data Team • 10/08/2026
JHipster serves as a prominent development platform designed to accelerate the creation of modern web applications and microservice architectures by generating boilerplate code based on user-selected technologies. A critical security vulnerability was identified within versions ranging from 7.0.0 through 9.4.0, specifically affecting reactive application stacks that utilize Spring WebFlux, Spring Data R2DBC, and a SQL database backend. The core of the issue lies in how these generated applications handle input parameters for sorting data on paginated entity-list endpoints. When an authenticated user submits a sort request parameter to control the ordering of results, this value is passed directly into the createOrderByFields method located within the EntityManager reactive template file. This architectural decision fails to implement any form of validation or sanitization before the parameter is utilized in database operations.
The technical flaw manifests as an SQL injection vulnerability due to improper neutralization of special elements used in SQL commands. The generated code renders these user-supplied properties directly into the SQL ORDER BY clause without applying necessary quoting mechanisms or validating that the input consists solely of allowed column names. In standard SQL, the ORDER BY clause is typically less susceptible to traditional data-exfiltration injection vectors because it expects column identifiers rather than string literals. However, this specific implementation interacts with the R2DBC simple query protocol, which possesses a distinct characteristic: it allows the execution of multiple statements separated by semicolons within a single request. This capability transforms what might otherwise be a minor input validation issue into a severe injection vulnerability, as an attacker can terminate the intended ORDER BY statement and append arbitrary SQL commands to the same query string.
The operational impact of this vulnerability is significant for any application relying on the affected reactive stack configuration. An authenticated user with access to paginated entity-list endpoints can exploit this flaw to perform unauthorized actions against the underlying database. By injecting malicious payloads, an attacker can read sensitive data from tables that should not be accessible through normal API interactions, modify existing records to alter business logic or steal information, delete critical data leading to denial of service or integrity loss, and even drop entire tables which would cause catastrophic application failure. It is important to note that this root cause does not affect non-reactive JPA applications or those utilizing NoSQL backends, as the vulnerability is specific to the interaction between Spring WebFlux, R2DBC, and SQL databases within the reactive programming model.
This vulnerability aligns with CWE-89 Improper Neutralization of Special Elements used in an SQL Command, commonly known as SQL Injection, specifically involving secondary injection via semicolon-separated statements. From a tactical perspective, it maps to ATT&CK technique T1059 Command and Scripting Interpreter through the use of database command syntax to execute arbitrary instructions, falling under the broader category of Database commands (T1213). The exploitation requires authentication, placing it within the scope of authenticated attacks where an adversary leverages valid credentials to escalate privileges or access restricted resources.
Mitigation strategies must prioritize upgrading the JHipster generator and application dependencies to version 9.4.0 or later, which contains the official fix for this issue. For organizations unable to upgrade immediately, defensive coding practices should be implemented within custom repository layers if applicable. Developers must ensure that any input used in SQL ORDER BY clauses is strictly validated against a whitelist of known safe column names rather than relying on simple string escaping. Additionally, configuring the database connection pool or driver settings to disable multi-statement execution can prevent the semicolon-based injection vector from succeeding, although this may impact other legitimate use cases requiring batch operations. Regular security audits and static analysis tools configured to detect SQL injection patterns in generated code are also recommended to catch similar issues early in the development lifecycle.