CVE-2025-31119 Overview
CVE-2025-31119 is an unsafe reflection vulnerability [CWE-470] in generator-jhipster-entity-audit, a JHipster module that adds entity auditing and audit log pages to generated applications. The flaw affects deployments where Javers is selected as the Entity Audit Framework. Versions prior to 5.9.1 accept attacker-influenced class names through REST endpoints and resolve them via reflection without validation. An attacker who can place malicious classes on the classpath and reach the audit REST interface can trigger remote code execution. The maintainers fixed the issue in version 5.9.1.
Critical Impact
Authenticated attackers with access to the Javers audit REST endpoints can achieve remote code execution by abusing unsafe reflection in the JaversEntityAuditResource controller.
Affected Products
- generator-jhipster-entity-audit versions prior to 5.9.1
- JHipster-generated applications using the Javers Entity Audit Framework
- Spring Boot services exposing the Javers audit REST endpoints
Discovery Timeline
- 2025-04-03 - CVE-2025-31119 published to the National Vulnerability Database
- 2026-06-17 - Last updated in NVD database
Technical Details for CVE-2025-31119
Vulnerability Analysis
The vulnerability lives in the Javers audit REST resource template generated by the JHipster module. The handler accepts a class name parameter from the HTTP request and uses Java reflection to load and instantiate the corresponding class. Because the input is not constrained to an allow-list of audited entity classes, any class reachable on the classpath becomes a candidate for instantiation.
Attackers who can place a crafted class onto the runtime classpath, for example through a dependency confusion attack, a writable plugin directory, or a chained file write primitive, can drive the reflective call to invoke arbitrary code during class loading or instantiation. The vulnerability is classified under CWE-470: Use of Externally-Controlled Input to Select Classes or Code, commonly known as unsafe reflection.
The attack requires both authenticated access to the protected REST interface and the ability to influence classpath contents. These prerequisites limit broad exploitation but remain realistic in multi-tenant build pipelines and applications that load classes from configurable directories.
Root Cause
The root cause is the absence of input validation around the reflective class lookup in JaversEntityAuditResource. The template passes a request-supplied identifier directly into Class.forName-style resolution, treating any reachable class as a valid audit target. Without an allow-list or type-bounded check, reflection becomes a code execution primitive.
Attack Vector
Exploitation requires network access to the application, valid high-privilege credentials, and user interaction in some flows. The attacker first stages a malicious class so the Java Virtual Machine can resolve it. They then call the vulnerable audit endpoint with the fully qualified class name. The application reflects on the supplied name, instantiates the class, and executes attacker-controlled logic in the static initializer or constructor. See the GitHub PoC template for the exact sink and the GitHub Security Advisory GHSA-7rmp-3g9f-cvq8 for the maintainer write-up.
Detection Methods for CVE-2025-31119
Indicators of Compromise
- Unexpected requests to Javers audit REST endpoints containing fully qualified Java class names as parameters.
- Application logs showing ClassNotFoundException, NoClassDefFoundError, or successful class loads for classes outside the audited entity packages.
- New or modified .class or .jar files in directories included on the application classpath.
- Outbound network connections initiated by the Java process immediately after audit endpoint requests.
Detection Strategies
- Inspect HTTP access logs for calls to Javers audit endpoints carrying class-name-like parameters and correlate with the authenticated user identity.
- Enable Spring Boot reflection and classloader logging to surface dynamic Class.forName resolutions outside the application's expected packages.
- Run static analysis on deployed builds to confirm whether generator-jhipster-entity-audit is below version 5.9.1 and whether the Javers backend is selected.
Monitoring Recommendations
- Forward web access logs and JVM logs to a centralized analytics platform and alert on reflective class loads originating from REST controllers.
- Monitor file integrity on classpath directories, plugin folders, and shared libraries used by the Spring Boot application.
- Track process-level child executions of the Java runtime to catch shell or scripting interpreters spawned post-exploitation.
How to Mitigate CVE-2025-31119
Immediate Actions Required
- Upgrade generator-jhipster-entity-audit to version 5.9.1 or later and regenerate or patch the JaversEntityAuditResource class in existing projects.
- Restrict access to the Javers audit REST endpoints to a minimal set of administrative roles and remove anonymous or low-privilege access.
- Audit classpath directories and build artifacts for unauthorized classes or JAR files.
Patch Information
The maintainers fixed CVE-2025-31119 in generator-jhipster-entity-audit version 5.9.1. The patch constrains the reflective lookup to known audited entities and removes the externally controlled class resolution. Review the GitHub Security Advisory GHSA-7rmp-3g9f-cvq8 for the specific code changes and upgrade guidance.
Workarounds
- If immediate upgrade is not possible, disable the Javers audit REST endpoints via Spring Security rules until the module can be updated.
- Add an allow-list filter in the controller that rejects any class name not belonging to the application's audited entity packages.
- Harden deployment so classpath directories are read-only to the application user and writable only by trusted release tooling.
# Example Spring Security configuration to block the vulnerable endpoint
# until generator-jhipster-entity-audit is upgraded to 5.9.1
http
.authorizeHttpRequests(auth -> auth
.requestMatchers("/api/javers/**").denyAll()
.anyRequest().authenticated()
);
Disclaimer: This content was generated using AI. While we strive for accuracy, please verify critical information with official sources.

