On this page (7 sections)
A critical authentication bypass has been published for ape-volo-admin. According to the GitHub Advisory Database entry, versions before 3.6.1 use a JWT signing key that is hardcoded in appsettings.json, which lets an unauthenticated attacker forge administrator tokens.
If you run ape-volo-admin, or you build on a copy of it, treat this as urgent. The fix is in release 3.6.1, and because the weakness is a fixed signing key, replacing the key you have been running matters as much as upgrading.
What happened
The advisory text states that ape-volo-admin before 3.6.1 contains an authentication bypass. The application signs its JSON Web Tokens with a key hardcoded in appsettings.json. Because that key sits in the application's configuration file, anyone who learns it can produce tokens the server will accept.
The advisory says attackers can sign tokens offline, setting the jti claim to the seeded administrator id, and gain full API control over users, roles, permissions and data. The CVSS v4 metrics on the advisory describe network access, low complexity, no privileges and no user interaction, with high impact on confidentiality, integrity and availability of the vulnerable system.
The record was published on November 2, 2026. The GitHub entry is marked unreviewed, and the NVD page repeats the same description, so this is effectively one description from a single source. The advisory also links to the project issue, the fix commit, the V3.6.1 release, a researcher write-up and a VulnCheck advisory. We have not reproduced the contents of those pages here.
Why a hardcoded signing key is so dangerous
A JWT is only trustworthy because the server alone can produce a valid signature. If the signing key is known to someone else, the signature proves nothing. An attacker does not need to guess a password, steal a session or touch the login page. They create a token that claims to be the administrator and the API accepts it.
As general reasoning rather than a finding from the advisory: a secret that ships inside a config file may be identical in every copy of the application that was not changed. If that is the case here, learning the key once could affect many deployments. Upgrading the code fixes the application going forward, but a key that was used in production before the fix is safest treated as compromised.
Who is exposed
- Deployments of ape-volo-admin older than 3.6.1, particularly where the API is reachable from the internet or a shared network.
- Installations still running with the JWT signing key from appsettings.json, even if you edited other settings.
- Teams that copied the project as a starting template or forked it, since the same configuration may live in your own repository.
- Deployments that use the seeded administrator id. The advisory says the forged token sets the jti claim to that id; the research does not say how 3.6.1 changes this, so do not assume a deployment is safe because you renamed or changed the account.
The research does not say how the fixed release handles the key, so read the 3.6.1 release notes and fix commit before assuming a plain upgrade also protects a key you have already been using. Do not assume a deployment is safe just because the admin panel sits behind an obscure URL, since the weakness is in the API token check.
How to check your exposure
Start by finding out which version you run and where the signing key is configured. The command below is a read-only search for appsettings files. Run it on the server from the application directory and note which files it lists.
find . -name 'appsettings*.json' -type fOpen the files you find and look at the JWT settings. The advisory references the V3.5.2 appsettings.json as the place the key is configured. The research does not show that file's contents, so use it as a reference to compare against. If your key looks like a value you never set yourself, assume it may be known to others and replace it.
Then review your logs for signs of misuse. The research gives no indicators of compromise, so look for behavior rather than signatures:
- Administrative API calls from IP addresses you do not recognize.
- Admin actions with no matching login event, since a forged token skips the login step.
- New or changed users, roles and permissions that nobody on your team made.
- Unexpected bulk reads or exports of data.
What to do now
0 of 7 done
If you find evidence that someone used a forged token, follow an incident process: preserve logs, rotate every credential the application could reach, and see our guide on what to do when a website is hacked.
Monitoring afterwards
Keep the admin API off the open internet where you can, and alert on admin-level actions from new locations. A web application firewall can add a layer in front of an admin interface, as explained in What is a WAF?, but it does not replace patching or rotating the key. To see what your public site exposes to outsiders, you can run a read-only Webforta scan on a site you have verified.
Hardcoded signing keys are a pattern worth auditing for in your own projects, including any forks or templates you maintain.
What we do not know yet
- No exploitation in the wild is reported in the sources reviewed, but that is an absence of reporting, not proof of safety.
- The GitHub advisory lists affected and patched versions as unknown, and the entry is unreviewed. The 3.6.1 fix version comes from the CVE description.
- The research does not say how 3.6.1 changes key handling or whether rotating the key invalidates previously issued tokens.
- Only this one advisory description (repeated by NVD) is available, so details may be refined as the project and researchers publish more.
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.