On this page (7 sections)
A critical flaw has been published for AJ-Report, a reporting tool. According to the GitHub Advisory Database entry, versions through 1.7.1 sign share tokens with a hard-coded JWT secret. The advisory says this allows attackers to forge valid Share-Tokens offline, and that a forged token can be used to reach an endpoint that leads to unauthenticated remote code execution.
If you run AJ-Report anywhere that is reachable from a network you do not fully control, treat this as urgent. The sources do not yet name a fixed version, so the practical steps today are limiting exposure and watching the project for a patch.
What happened
The flaw was published on October 31, 2026 through the National Vulnerability Database and mirrored in the GitHub Advisory Database. The NVD text repeats the same description, so it is not independent confirmation. The description says AJ-Report through 1.7.1 signs share tokens with a hard-coded JWT secret.
According to the advisory, that design lets attackers forge valid Share-Tokens offline, meaning they can create a token without interacting with your server first, then present it to an instance. The advisory references the JwtUtil.java file in the V1.7.1 source, which is where the token handling lives. A VulnCheck advisory is also referenced; its contents were not part of the research available for this article.
How the weakness works
JWTs are only trustworthy if the signing key stays secret. When a key is hard-coded into the software, it is no longer something an administrator controls or can easily change, and anyone who learns the value can sign tokens that the application will accept. This is the weakness class CWE-321.
Per the advisory, the chain has two steps:
- A forged Share-Token is accepted as valid because it carries a correct signature.
- A token with reportCode set to 'dataSet' grants access to the testTransform endpoint, which passes scripts to GroovyClassLoader. That runs the supplied script on the server.
The CVSS v4 metrics in the advisory describe network attack vector, low complexity, no privileges and no user interaction, with high impact on confidentiality, integrity and availability of the vulnerable system. In plain terms, a remote stranger could run code on the server with no account.
Who is affected
Any deployment of AJ-Report at version 1.7.1 or earlier. The advisory says "through 1.7.1" and lists affected versions as unknown, so the lowest affected version is not known; assume older releases are affected too. Exposure is highest when the application is published directly to the internet, for example on a public dashboard or reporting subdomain. Internal-only instances are lower risk but still exposed to anyone who can reach them, including a compromised internal host.
Code execution on a reporting server can matter beyond the server itself. Reporting tools commonly hold connection details for the data sources they report on, so it is sensible to assume those credentials could be at risk if an instance is compromised. The research does not describe what AJ-Report stores, so check your own configuration.
How to check your exposure
Start by finding out whether you run AJ-Report and which version. Check your deployment records, container image tags or the version shown in the application or its build files. If you run it in Docker, this read-only command lists running containers with their images and published ports so you can look for AJ-Report and its tag:
docker ps --format '{{.Names}}\t{{.Image}}\t{{.Ports}}'Then check whether the application is reachable from outside. From a machine outside your network, see whether the port or hostname answers. The ports column above shows whether the service is published on all interfaces. If you keep nginx access logs, this read-only search looks for requests mentioning the testTransform path named in the advisory. Adjust the log path to your setup and look for any matching lines:
grep -i 'testTransform' /var/log/nginx/access.log*Hits are not proof of compromise, since the endpoint name is only what the advisory describes, but unexpected requests from unfamiliar addresses deserve a closer look.
What to do now
No patched version is listed in the sources, so the priority is to cut off access and prepare to upgrade as soon as the maintainers publish a fix. Watch the project repository and the issue tracker entry for updates.
0 of 7 done
Detection and monitoring
Signs worth watching for on a host running AJ-Report: unexpected child processes spawned by the Java process, outbound connections to unfamiliar addresses, new files in the application or temp directories, and unusual spikes of requests carrying Share-Token values from addresses that are not your users.
If you suspect a breach, follow the steps in Website hacked: what to do and isolate the host first. For ongoing visibility of what your public hosts expose, Webforta Scan can run read-only checks on sites you verify, and Webforta Monitor tracks uptime, certificate and DNS changes. Neither will tell you whether this specific flaw is present.
What is still unknown
- No fixed version is named in the available sources.
- No source reports in-the-wild exploitation, and the CVE is not in CISA KEV as of the research.
- Only one independent source covers the flaw; the NVD entry repeats the same description.
- The GitHub entry is marked unreviewed, and the lowest affected version is not given.
We will not guess at a patch version. Check the maintainers' channels for the current state before acting on any version number you see elsewhere.
Sources
This article is based on the public sources below. Details can change as vendors and researchers publish more; check the original advisories before acting on version numbers.