- A GitHub advisory says reactive JHipster apps with a SQL database carry an SQL injection flaw in their sorted list endpoints. A low-privilege user can exploit it.
- The flawed code is written into each app at build time, so fixing the generator will not repair apps already built.
- Leaders should list which apps used JHipster versions 7.0.0 to 9.2.0 in reactive mode, and plan to rebuild them.
A flaw in a code generator does not stay in one place. It is copied into every application the tool builds. Fixing the generator later does not reach the apps already built. That is the lesson of a new advisory about JHipster.
What the advisory reports
The GitHub Advisory Database published GHSA-r223-96jv-q533 on October 8, 2026. It covers generator-jhipster, the npm package that produces JHipster applications. The advisory says every reactive app with a SQL database contains an SQL injection flaw. Reactive here means the Spring WebFlux and Spring Data R2DBC stack.
The flaw sits in the paginated list endpoints. These look like GET /api/<entity>?sort=... The advisory says the generator produces this code by default. It names monoliths and microservices as the default cases.
How the flaw works
A list page lets users sort results, for example by name or date. The browser sends the chosen column in the sort parameter. The generated code takes that text as sent and pastes it into the ORDER BY part of the database query. It does not quote the text or check it.
A second factor makes this worse. The query is built as one block of plain text. Nothing in it is handed to the database as a separate value. Because of this, the R2DBC drivers use the simple query protocol. That protocol will run several statements if semicolons divide them.
So an attacker can end the sort instruction and add commands of their own. The advisory gives one example: ?sort=id;DROP TABLE product;-- . The double dash tells the database to ignore the rest of the line.
The advisory traces the cause to a template file, EntityManager_reactive.java.ejs. Its createOrderByFields code turns the user's text into an unquoted identifier. The generated app uses the default naming strategy. That strategy prints unquoted identifiers exactly as written.
Who can exploit it
The advisory says one authenticated, low-privilege user is enough. That includes an account made through the default self-registration flow. The researcher ran every payload with a token carrying only ROLE_USER. No other flaw or admin account was needed.
The stated impact covers all three security goals. An attacker could read any table, including jhi_user, which holds password hashes. They could also change or delete data, and drop tables.
The researcher generated a real application from v9.2.0 and built it with Spring Boot 4.1.1. They ran it against H2 and PostgreSQL 16. The advisory calls these the default development and production databases. It lists an H2 run dated August 29, 2026.
Why the generator is the real story
The advisory says the non-reactive JPA path is not affected. Spring Data JPA checks sort names against the entity's known fields. The reactive path skipped that check. So the same product has a safe version and an unsafe one. NoSQL backends fall outside this root cause.
Here is the wider point, and it is our interpretation, not a claim from the advisory. Teams often track risk in the libraries they import. This code is different. The generator wrote it into the team's own project, so the team now owns it. A scanner that only checks library versions may not flag it.
The advisory is direct about the repair path. It says applications must be regenerated after a fix. It advises checking each sort property against the entity's known columns, or rendering it as a quoted identifier. It also says to ship the fix in the generator. The text we reviewed does not say whether a fixed release exists yet.
What leaders should ask their teams
Start with inventory. Which of our applications were built with JHipster? Which used the reactive option with a SQL database? The affected range is v7.0.0 through v9.2.0, so ask which generator version produced each one.
Then ask about exposure. Is self-registration turned on? If so, anyone can get the low-privilege account the advisory describes. As our own suggestion, not the advisory's, ask what the application's database account is allowed to do. A narrower account may limit what a self-registered user could reach through this flaw.
Finally, ask about the fix. Who will watch for a patched generator? Who owns rebuilding each application? How much custom code would a rebuild overwrite? Teams can also search request logs for semicolons in sort parameters. That is our suggestion, not one from the advisory.
A fixed template protects only the next application it builds. The ones already running need someone to rebuild them.
Produced by the WebPulse Newsroom with AI assistance from the original reporting credited below, and checked against that source by our editorial review. How we use AI.
Original reporting: GitHub Advisory Database.
