CVE-2025-8974 is a low severity (CVSS 3.7) hard-coded credential flaw in linlinjava litemall up to 1.8.0. The record says the secret used by the JSON Web Token handler in JwtHelper.java is fixed in the source. I could not confirm a fixed version, so set your own secret and check the project.
The weakness classes are CWE-259, use of a hard-coded password, and CWE-798, use of hard-coded credentials.
What's affected
linlinjava litemall, up to and including 1.8.0, per the record. The affected file is litemall-wx-api/src/main/java/org/linlinjava/litemall/wx/util/JwtHelper.java, in the component that handles JSON Web Tokens for the mini program API. The record names the SECRET value and the X-Litemall-Token header.
The record scores it 3.7 (LOW) with the vector CVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:U/C:N/I:L/A:N. In plain terms: reachable over the network, high attack complexity, no privileges and no user interaction, no confidentiality or availability impact and low integrity impact. The record adds that the attack complexity is rather high and that exploitation is known to be difficult, while also saying the exploit has been disclosed to the public.
The public issue title, which I read on 18 October 2026, is "Hardcoded JWT Secret Vulnerability in Litemall (up to v1.8.0) (CWE-798)". It agrees with the record on product, file and version range. I could not read the issue body. The record names no fixed version.
How to check if you're exposed
Look at the source or the build you deploy.
grep -n "SECRET" litemall-wx-api/src/main/java/org/linlinjava/litemall/wx/util/JwtHelper.java
If the secret is a string literal in that file, and you have not replaced it, your tokens are signed with a value that anyone with the source can read. If you run a packaged build, find the version and compare it with the range above. Also check whether you or your team changed the file to read the secret from configuration.
The free in-browser dependency scan at gold.safeguard.sh/scan is built for libraries, so it will not read a constant inside application source, and a code level review is the right tool for this one.
What to do now
- Check whether JwtHelper.java holds a literal secret in your deployment.
- Move the secret into configuration or a secret store, and make it long, random and unique per environment.
- Restart the service so it signs with the new secret. This invalidates tokens signed with the old one, so users will need to sign in again.
- Search other modules, including the admin API, for similar constants.
- Check the project's releases and issue 568 for an upstream change. I could not confirm one.
- Add a check to code review that blocks credentials committed as string literals.
Why it matters
A JSON Web Token is only as trustworthy as the secret that signs it. If the secret is in a public source repository, anyone who has read it can in principle produce tokens the server accepts. That is why hard-coded secrets are a distinct weakness class and not a configuration nicety.
The score is low here because the record rates the attack complexity high and the impact as limited to integrity. That is a fair reading of the formal vector, but it describes the vulnerability in the abstract. In your deployment, what matters is what a forged token can do, and that depends on what the API trusts a token to prove. Review that before you decide this can wait.
The KEV flag in the record is false, and I found no advisory saying this is exploited in the wild.
Quick check
Why is a hard-coded secret rated low?
The vector sets high attack complexity and only a low integrity impact. That is the formal rating, not a statement about your deployment. If a forged token could reach sensitive actions in your setup, the real risk is higher.
Will changing the secret log my users out?
Yes. Tokens signed with the old secret stop validating once the service uses the new one, so users sign in again. That is the intended effect, because it also removes any token made with the old, known value.
Sources
- Gold entry for CVE-2025-8974
- Public issue 568 on GitHub, title read only
- CWE-259 and CWE-798
Last reviewed: 18 October 2026.
