Threat Intelligence Database

# SQL Injection in the `sort` Parameter of JHipster-Generated Reactive (WebFlux + R2DBC) Applications - **Product**: jhipster/generator-jhipster (npm package `generator-jhipster`) - **Affected versions**: v7.0.0 through v9.2.0 - **Component**: generated reactive-application code, template `EntityManager_reactive.java.ejs` - **Report date**: 2026-08-29 --- ## 1. Summary Every reactive (Spring WebFlux + Spring Data R2DBC + SQL) application generated by `generator-jhipster` contains an SQL injection in the paginated entity list endpoints (`GET /api/<entity>?sort=...`). The `sort` request parameter is taken verbatim from the user and concatenated into the SQL `ORDER BY` clause without quoting or validation. Because the generated query has no bound parameters, the R2DBC drivers execute it via the **simple query protocol**, so `;`-separated extra statements are run against the database. A single authenticated low-privileged user (including an account obtained through the default self-registration flow) can therefore **execute arbitrary SQL**: read any table (including `jhi_user` password hashes), modify or delete data, and drop tables (full C/I/A impact). Independently reproduced end-to-end on the default dev database (H2) and the default production database (PostgreSQL 16). The JPA (non-reactive) path is **not** affected: Spring Data JPA validates sort property names against the entity metamodel. NoSQL backends are out of scope of this root cause. ## 2. Root Cause The generator template `generators/spring-boot/generators/data-relational/templates/src/main/java/_package_/repository/EntityManager_reactive.java.ejs` (lines 240–253) writes `createOrderByFields(...)`, which renders the user-supplied sort property directly as an unquoted `SqlIdentifier`: ```java private static Collection<? extends OrderByField> createOrderByFields(Table table, Sort sortToUse) { List<OrderByField> fields = new ArrayList<>(); for (Sort.Order order : sortToUse) { String propertyName = order.getProperty(); // attacker controlled (?sort=...) OrderByField orderByField = !propertyName.contains(".") ? OrderByField.from(table.column(propertyName).as(EntityManager.ALIAS_PREFIX + propertyName)) : createOrderByField(propertyName); fields.add(order.isAscending() ? orderByField.asc() : orderByField.desc()); } return fields; } ``` The generated app configures `SqlRenderer.create(factory.createRenderContext())` with the default naming strategy, so unquoted identifiers are rendered **verbatim**. With `?sort=id;DROP TABLE product;--` the alias renders into: ```sql SELECT e.id AS e_id, e.name AS e_name, e.price AS e_price FROM product e ORDER BY e_id;DROP TABLE product;-- ASC LIMIT 20 OFFSET 0 ``` ## 3. Verification A real application was generated from this repository (`git clone` of the submitted source, v9.2.0), built with Spring Boot 4.1.1, and run against both H2 and PostgreSQL 16. | Step | H2 (dev default) | PostgreSQL 16 (prod default) | | ------------------------------------------------------------------------------------------------ | --------------------------------------------------------------------------------------- | -------------------------------------------------- | | Error probe `sort=name%27` | 500; SQL echoed with raw `'` in `ORDER BY e_name'` | 500; r2dbc-postgresql parse error echoing full SQL | | Exfiltrate admin hash via `;UPDATE product SET name=(SELECT password_hash FROM jhi_user ...);--` | HTTP 200; `name` becomes `$2a$10$gSAhZrxMllrbgj/kkK9UceBPpChGWJA7SYIb1Mqo.n5aNLq1/oRrC` | HTTP 200; same hash read back | | `;DROP TABLE product;--` | HTTP 200; table gone, subsequent list → 500 | HTTP 200; table gone, subsequent list → 500 | All payloads executed with a token carrying only `ROLE_USER`. **No other vulnerability or privileged account is required.** ## 4. Impact CWE-89 SQL Injection. Confidentiality (arbitrary read, incl. `jhi_user` password hashes), Integrity (arbitrary writes), Availability (table drops). The affected code is produced by default for `reactive: true` + SQL database + paginated entity (the default for monoliths and microservices). Applications must be regenerated after a fix. ## 5. Fix Recommendation In `EntityManager.createOrderByFields`, validate each sort property against the entity's persistent metamodel (allow only known column names) or render it as a quoted `SqlIdentifier`; never concatenate raw property strings into SQL. Ship the fix in the generator and advise affected applications to re

## Summary Applications generated by generator-jhipster v9.2.0 can persist user-controlled Blob ContentType values and later use those values as the MIME type for client-side Blob objects. The shared generated `openFile` helper creates an object URL from the Blob and opens it in a new window. For Blob-bearing entities writable by normal authenticated users, this creates a stored XSS chain: attacker-controlled Blob content and MIME type are stored through the generated REST API, returned to privileged users, and opened as a same-origin Blob document from the generated Angular/React/Vue UI. Exploitability should be confirmed against the generated app’s CSP and target browsers. ## Details The root cause is a trust-boundary failure across generated server and client code. The generated entity REST resource accepts request bodies for entity creation and update. Unless an entity-specific authority is configured, the template omits method-level `@PreAuthorize`, leaving the endpoint available to any authenticated user under the global `/api/**` security rule. The generated DTO/domain/mapper flow stores the companion `<field>ContentType` property as a plain `String` and persists it with the entity Blob data. The relevant templates include `generators/spring-boot/templates/src/main/java/_package_/_entityPackage_/service/dto/_dtoClass_.java.ejs:96-122` and `generators/java/generators/domain/templates/src/main/java/_package_/_entityPackage_/domain/_persistClass_.java.jhi.ejs:124-140`. The generated code does not restrict MIME types, reject active document formats, or validate that the declared content type matches the uploaded bytes. The dangerous sink is `openFile` in `generators/client/generators/common/templates/src/main/webapp/app/shared/jhipster/data-utils.ts.ejs:49-64`. It uses the returned `contentType` as the Blob type, creates an object URL, and calls `globalThis.open(fileURL)`. Generated Angular, React, and Vue entity pages pass server-returned Blob data and ContentType into this helper, allowing active HTML or SVG content to be opened as a document under the application origin depending on CSP and browser behavior. Core vulnerable code path: ```typescript // generators/client/generators/common/templates/src/main/webapp/app/shared/jhipster/data-utils.ts.ejs:49-64 export const openFile = (data: string, contentType: string | null | undefined): void => { contentType ??= ''; const byteCharacters = atob(data); const byteNumbers = new Array(byteCharacters.length); for (let i = 0; i < byteCharacters.length; i++) { byteNumbers[i] = byteCharacters.codePointAt(i); } const byteArray = new Uint8Array(byteNumbers); const blob = new Blob([byteArray], { type: contentType, }); const fileURL = globalThis.URL.createObjectURL(blob); const win = globalThis.open(fileURL); if (win) { win.onload = () => URL.revokeObjectURL(fileURL); ``` The shared client sink trusts the incoming contentType, builds a Blob with that type, and opens it through a generated object URL. Active MIME types can therefore become executable documents when opened, depending on CSP and browser behavior. ## POC Preconditions: the target application is generated by generator-jhipster v9.2.0; it includes an entity with a Blob, AnyBlob, or ImageBlob field; the entity has no entityAuthority restriction or the attacker has write permission; the attacker has a normal account and a higher-privileged victim can view the entity detail or list page. Reproduction: (1) Generate an application with a Blob-bearing entity, for example a Document entity with a payload AnyBlob field. (2) Authenticate as a normal user and send POST /api/documents with Authorization: Bearer <attacker-token> and Content-Type: application/json. The request body contains a Base64-encoded active document in the payload field and a payloadContentType value such as text/html. (3) Confirm that the API returns HTTP 201 and that GET /api/documents/{id} returns the same payload and payloadContentType. (4) Have a privileged user open the generated entity detail or list page and click the Blob field’s Open link. Expected result: the browser opens a blob:<target-origin>/... document; where CSP and browser behavior permit script execution, the document can read Web Storage tokens or call same-origin APIs such as /api/account and privileged /api/admin/** endpoints as the victim. ## Impact A normal authenticated user can persist active content that a privileged user may open from the generated UI. Successful exploitation can result in stored cross-site scripting, JWT/localStorage/sessionStorage theft, sensitive API data disclosure, and privileged actions under the victim’s session. Default CSP may reduce exploitability, so deployments with relaxed CSP or browser behavior that allows script execution in opened Blob documents are at highest risk.