NextScan hardcoded JWT key lets unauthenticated attackers seize admin console

What happened

A write-up published on dev.to details CVE-2026-126797, a critical vulnerability in NextScan, a security scanning project whose ns-admin component manages users, scan tasks and stored vulnerability results. Versions 1.1.0 through 1.2.0 ship with a hardcoded JWT signing key, meaning the secret is effectively public and shared across every deployment. According to the post, VulnCheck has assigned the issue a CVSS v4.0 score of 9.3, and exploitation requires no privileges and no user interaction.

How the attack works

Because the signing key is not secret, anyone who obtains it can craft a token that passes verification. The write-up explains that an unauthenticated attacker can sign an HS256 token, present it via the X-Access-Token header, and claim the publicly known super-administrator role ID. No password is involved. In this design, the token signature check is the only authentication boundary, so a token that verifies is treated as authentic — even though the person presenting it never logged in.

Why scanner consoles are a target

The dev.to post argues that internal security tools often receive less scrutiny than internet-facing applications, yet ns-admin concentrates exactly what an attacker wants: a map of weaknesses across the environment, the ability to launch network requests, and stored scan history. Whoever controls the console can modify users, change scan scope, and edit stored results. That makes it a valuable foothold for an attacker who already has any route into the internal network — and a potential source of false assurance if findings or scan schedules are silently altered.

Affected versions and fix status

The affected range is 1.1.0 through 1.2.0. At the time of publication, the upstream issue referenced in the post (issue 48) did not identify a fixed release, so operators should not assume that 1.2.0 is safe. The author recommends checking the upstream issue and the VulnCheck advisory for a corrected build. The Docker deployment and upstream source can help verify where the key and role handling live, though the key itself should not be copied into tickets or chat.

Interim mitigation

The post lays out several interim measures for operators:

• Place ns-admin behind authentication at a reverse proxy or identity-aware access layer and restrict it to administrator networks. It should not be exposed through a public NAT rule.
• Review whether other services trust scan results originating from the console, since compromised findings can propagate.
• If the team can patch the 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 patch is not a vendor fix, so document it and revisit it when upstream ships one.
• Review access logs for successful administrator requests without a preceding login, token issuance anomalies, and changes to users or scan schedules. If the console was reachable by untrusted users, stored vulnerability results may warrant an independent comparison.

For verification after patching or mitigation, the post suggests attempting to use a token signed with a test key and confirming it is rejected, while testing ordinary administrator login separately. The effective key source should be recorded without printing the key's value.

Why it matters

The vulnerability illustrates a recurring JWT failure mode: a valid signature only proves a token was signed with the key, not that its holder ever authenticated. When every installation shares the same hardcoded key, even that proof collapses. The broader lesson, as the write-up frames it, is about deployment identity — a scanner should not ship with one signing secret for all installations, and an internal tool should not be treated as trusted simply because it sits off the public internet. Tools that inventory an organisation's weaknesses are high-value targets in their own right, and per-deployment secrets should be the baseline for anything that mints bearer tokens.