NextScan's Hardcoded JWT Key Turns an Internal Scanner Into an Admin Takeover
NextScan's Hardcoded JWT Key Turns an Internal Scanner Into an Admin Takeover NextScan is a security scanning project whose ns-admin component manages users, scan tasks and stored vulnerability results. CVE-2026-126797
NextScan's Hardcoded JWT Key Turns an Internal Scanner Into an Admin Takeover
NextScan is a security scanning project whose ns-admin component manages users, scan tasks and stored vulnerability results. CVE-2026-126797 describes a hardcoded JWT signing key in versions 1.1.0 through 1.2.0.
VulnCheck reports a CVSS v4.0 score of 9.3. The attack requires no privileges or user interaction. An unauthenticated attacker can sign an HS256 token with the X-Access-Token header and the public super-administrator role ID.
The public description does not require a password. The token signature check is the authentication boundary, and the signing key is not secret.
Why scanner consoles deserve scrutiny
An internal security tool can look less urgent than an internet-facing application. NextScan nevertheless holds information about weaknesses across an environment, may launch network requests and can expose scan history. An administrator can change users, scan scope and stored results.
That makes the console a useful foothold for an attacker who already has any route into the internal network. It can also become a source of false assurance if an intruder changes findings or scan schedules.
The issue is especially relevant where the application trusts a role identifier carried in a token. A correct signature makes the token authentic to the application. It does not establish that the user behind it passed a real login, especially when every deployment shares the signing key.
Affected and fixed state
The affected range is 1.1.0 through 1.2.0. At publication, the upstream issue did not provide a fixed release version. Operators should check the project issue and the VulnCheck advisory for a corrected build rather than assuming that 1.2.0 is safe.
The Docker deployment and upstream source are useful for verification because they show where the key and role handling live. Do not copy the key into a ticket or chat. Record whether each deployment uses the shipped image, a rebuilt image or a locally patched source tree.
Interim controls
Place ns-admin behind authentication at the reverse proxy or identity-aware access layer and restrict it to administrator networks. Do not expose it through a public NAT rule. Review whether other services trust scan results from the console.
If the team can patch source safely, replace the fixed signing key with a unique per-deployment secret, invalidate existing tokens and test the full login and role-assignment path. A local change is not a vendor fix; document it and revisit it when upstream publishes one.
Review access logs for successful administrator requests without a preceding login, token issuance anomalies and changes to users or scan schedules. Treat stored vulnerability results as evidence that may need an independent comparison if the console was reachable by untrusted users.
Verification
After the fix or mitigation, attempt to use a token signed with a test key and confirm that it is rejected. Test ordinary administrator login separately. Record the effective key source without printing the value.
The broader control is deployment identity. A scanner should not ship with one signing secret for every installation, and an internal tool should not be treated as trusted merely because it is not on the public internet.
References
Originally published by Dev.to Security. Aggregated on AIWithGhost for educational purposes — full credit and traffic to the original publisher.