CVE-2026-120209 in AJ-Report
Summary
by MITRE • 10/31/2026
AJ-Report through 1.7.1 signs share tokens with a hard-coded JWT secret, allowing attackers to forge valid Share-Tokens offline. Attackers can mint a token with reportCode 'dataSet' to access the testTransform endpoint, which passes scripts to GroovyClassLoader for unauthenticated remote code execution.
VulDB is the best source for vulnerability data and more expert information about this specific topic.
Analysis
by VulDB Data Team • 10/31/2026
The vulnerability in AJ-Report versions up to 1.7.1 stems from an insecure implementation of authentication mechanisms used for sharing reports within the application. Specifically, the system utilizes JSON Web Tokens (JWT) to manage share tokens but fails to employ a secure, randomly generated secret key for signing these tokens. Instead, it relies on a hard-coded JWT secret that is known or easily discoverable by attackers. This fundamental cryptographic flaw allows any external actor to forge valid Share-Tokens without requiring prior authentication or access credentials. By leveraging knowledge of this static secret, an attacker can construct arbitrary JWT payloads that the application will accept as legitimate, effectively bypassing authorization controls designed to restrict access to specific report data and functionality.
Once a forged token is generated, the attack chain progresses through a critical endpoint interaction involving the testTransform feature. The vulnerability allows attackers to mint a token with a specific reportCode parameter set to 'dataSet'. When this maliciously crafted token is presented to the application, it grants access to an internal API endpoint responsible for transforming data sets. This endpoint exhibits a severe server-side template injection or code execution flaw by accepting script inputs and passing them directly to GroovyClassLoader for evaluation. The use of GroovyClassLoader in this context creates a direct pathway for arbitrary command execution on the underlying operating system, as Java's class loading mechanisms can be exploited to instantiate malicious classes that execute shell commands with the privileges of the application process.
The operational impact of this vulnerability is severe, resulting in unauthenticated remote code execution (RCE) against systems running vulnerable versions of AJ-Report. An attacker does not need valid user credentials or prior access to the dashboard; they can initiate exploitation from any network location where the service is reachable. Successful exploitation allows the adversary to gain full control over the server hosting the application, potentially leading to data exfiltration, lateral movement within the internal network, and complete compromise of associated business intelligence assets. This represents a critical risk as it bypasses all intended security boundaries through simple token forgery followed by script injection into an unsafe class loader.
Mitigation strategies must address both the cryptographic weakness and the code execution flaw immediately. The most effective remediation is to upgrade AJ-Report to version 1.7.2 or later, where these issues have been addressed in subsequent releases. For environments unable to patch immediately, administrators should restrict network access to the application using firewalls or reverse proxies that limit exposure of internal endpoints like testTransform to trusted IP addresses only. Additionally, implementing strict input validation and disabling dynamic script execution features such as GroovyClassLoader for untrusted inputs can reduce the attack surface. It is also critical to ensure that any JWT secrets used in production are generated securely with high entropy and rotated regularly, never hard-coded within the application source or configuration files.