Summary
JHipster-generated reactive applications may pass an attacker-controlled sort parameter into a SQL ORDER BY clause without validation or quoting. An authenticated user could abuse this behavior to execute additional SQL statements, potentially reading, modifying, or deleting database data when the application uses Spring WebFlux, Spring Data R2DBC, and a SQL backend.
JHipster-generated reactive applications may pass an attacker-controlled sort parameter into a SQL ORDER BY clause without validation or quoting. An authenticated user could abuse this behavior to execute additional SQL statements, potentially reading, modifying, or deleting database data when the application uses Spring WebFlux, Spring Data R2DBC, and a SQL backend.
Affected context
The issue occurs in JHipster-generated reactive applications that combine Spring WebFlux, Spring Data R2DBC, and a SQL database. It affects paginated entity-list endpoints where the sort request parameter reaches generated repository code and is incorporated into an ORDER BY clause without validation or quoting. The described root cause does not apply to non-reactive JPA applications or NoSQL backends.
The issue occurs in JHipster-generated reactive applications that combine Spring WebFlux, Spring Data R2DBC, and a SQL database. It affects paginated entity-list endpoints where the sort request parameter reaches generated repository code and is incorporated into an ORDER BY clause without validation or quoting. The described root cause does not apply to non-reactive JPA applications or NoSQL backends.
Exploit preconditions
- Attack surface: Authenticated paginated entity-list endpoints
- Required access: A normal authenticated application account capable of submitting sort parameters
- Trigger point: Processing a request containing a crafted sort value
- Why exploitation is possible: Generated repository code places attacker-controlled properties into SQL syntax, while the R2DBC simple query protocol may permit additional semicolon-separated statements
- Attack surface: Authenticated paginated entity-list endpoints
- Required access: A normal authenticated application account capable of submitting sort parameters
- Trigger point: Processing a request containing a crafted sort value
- Why exploitation is possible: Generated repository code places attacker-controlled properties into SQL syntax, while the R2DBC simple query protocol may permit additional semicolon-separated statements
Why this happens
The vulnerability results from treating a request-controlled sort property as trusted SQL syntax. The generated reactive repository code passes the value into an ORDER BY clause without restricting it to an approved set of fields or safely representing it as an identifier. This is a form of CWE-89: SQL Injection, because untrusted input can alter the intended structure or execution of a database query.
The vulnerability results from treating a request-controlled sort property as trusted SQL syntax. The generated reactive repository code passes the value into an ORDER BY clause without restricting it to an approved set of fields or safely representing it as an identifier. This is a form of CWE-89: SQL Injection, because untrusted input can alter the intended structure or execution of a database query.
Potential impact
- An attacker may read sensitive database records
- An attacker could modify or delete application data
- Database tables may be dropped or otherwise damaged
- Application integrity and availability can be compromised
- Exposed database privileges could increase the scope of unauthorized actions
- An attacker may read sensitive database records
- An attacker could modify or delete application data
- Database tables may be dropped or otherwise damaged
- Application integrity and availability can be compromised
- Exposed database privileges could increase the scope of unauthorized actions
General mitigation guidance
Mitigation generally focuses on ensuring that request parameters cannot become executable SQL syntax.
Common defensive patterns include:
- Restricting sort fields to a small, explicit allowlist of known entity properties
- Mapping external sort names to trusted database identifiers
- Using framework query-building mechanisms that preserve separation between data values and SQL structure
- Rejecting unexpected, empty, or structurally invalid sort expressions
- Limiting database accounts to the minimum read and write permissions required
- Applying transaction, statement, and network controls that reduce the effect of unauthorized queries
- Treating generated repository code as security-sensitive and reviewing templates before deployment
Mitigation generally focuses on ensuring that request parameters cannot become executable SQL syntax.
Common defensive patterns include:
- Restricting sort fields to a small, explicit allowlist of known entity properties
- Mapping external sort names to trusted database identifiers
- Using framework query-building mechanisms that preserve separation between data values and SQL structure
- Rejecting unexpected, empty, or structurally invalid sort expressions
- Limiting database accounts to the minimum read and write permissions required
- Applying transaction, statement, and network controls that reduce the effect of unauthorized queries
- Treating generated repository code as security-sensitive and reviewing templates before deployment
How teams detect issues like this
Organizations can identify this class of issue through:
- Static analysis rules for request parameters concatenated into SQL or query fragments
- Code review checks for dynamic
ORDER BY, filter, and pagination expressions - Tests that submit unexpected sort names and verify that only approved fields are accepted
- Runtime monitoring for unusual database statements, metadata access, destructive operations, or semicolon-separated queries
- Policy enforcement requiring allowlisted query identifiers and least-privilege database roles
- Automated code review tools that flag unsanitized request data reaching database APIs
Organizations can identify this class of issue through:
- Static analysis rules for request parameters concatenated into SQL or query fragments
- Code review checks for dynamic
ORDER BY, filter, and pagination expressions - Tests that submit unexpected sort names and verify that only approved fields are accepted
- Runtime monitoring for unusual database statements, metadata access, destructive operations, or semicolon-separated queries
- Policy enforcement requiring allowlisted query identifiers and least-privilege database roles
- Automated code review tools that flag unsanitized request data reaching database APIs
