Filtered by vendor Jhipster Subscriptions
Filtered by product Generator-jhipster Subscriptions

Search

Switch to Advanced Search (Beta)
Total 2 CVE
CVE Vendors Products Updated CVSS v3.1
CVE-2025-43712 1 Jhipster 1 Generator-jhipster 2025-07-28 2.9 Low
JHipster before v.8.9.0 allows privilege escalation via a modified authorities parameter. Upon registering in the JHipster portal and logging in as a standard user, the authorities parameter in the response from the api/account endpoint contains the value ROLE_USER. By manipulating the authorities parameter and changing its value to ROLE_ADMIN, the privilege is successfully escalated to an Admin level. This allowed the access to all admin-related functionalities in the application. NOTE: this is disputed by the Supplier because there is no privilege escalation in the context of the JHipster backend (the report only demonstrates that, after using JHipster to generate an application, one can make a non-functional admin screen visible in the front end of that application).
CVE-2022-24815 1 Jhipster 1 Generator-jhipster 2025-04-22 8.1 High
JHipster is a development platform to quickly generate, develop, & deploy modern web applications & microservice architectures. SQL Injection vulnerability in entities for applications generated with the option "reactive with Spring WebFlux" enabled and an SQL database using r2dbc. Applications created without "reactive with Spring WebFlux" and applications with NoSQL databases are not affected. Users who have generated a microservice Gateway using the affected version may be impacted as Gateways are reactive by default. Currently, SQL injection is possible in the findAllBy(Pageable pageable, Criteria criteria) method of an entity repository class generated in these applications as the where clause using Criteria for queries are not sanitized and user input is passed on as it is by the criteria. This issue has been patched in v7.8.1. Users unable to upgrade should be careful when combining criterias and conditions as the root of the issue lies in the `EntityManager.java` class when creating the where clause via `Conditions.just(criteria.toString())`. `just` accepts the literal string provided. Criteria's `toString` method returns a plain string and this combination is vulnerable to sql injection as the string is not sanitized and will contain whatever used passed as input using any plain SQL.