A critical authentication bypass in Kubero lets unauthenticated attackers forge administrator login tokens, security researchers have warned, after the flaw was published on Monday, 9 November 2026.

The vulnerability, tracked as CVE-2026-125370, affects Kubero versions 3.0.0 through 3.1.1. It carries a critical severity rating of 9.3, and a fix is available, according to the vulnerability listing published on 9 November.

How the flaw works

According to the US National Vulnerability Database (NVD), Kubero contains a hardcoded fallback signing secret for its JSON Web Tokens (JWTs), the signed tokens used to prove who a user is after they log in. The fallback is used when the JWT_SECRET setting has not been set.

Because the fallback secret is the same in every installation that leaves the setting blank, an unauthenticated remote attacker can use it to sign their own tokens. Those forged tokens can carry any role, user group and permission claims the attacker chooses, including administrator rights.

The problem is made worse by how Kubero checks the tokens. Its JwtStrategy.validate() code trusts the claims inside a token without checking them against the database, so a forged token is accepted as genuine. With it, an attacker can take control of pipelines, applications, users and API tokens managed through Kubero.

Why hardcoded secrets are dangerous

The flaw is classed as CWE-321, the use of a hard-coded cryptographic key. A signing secret only works if it is secret, and a value baked into the software is secret from nobody: anyone who can read the code, or a copy of it, knows the key.

That turns a configuration mistake into a full compromise. An administrator who installs Kubero, never sets JWT_SECRET, and assumes the system is safe because logins are required has in fact left the front door open to anyone who knows the fallback value.

The same pattern has caused serious breaches elsewhere. Hardcoded and default credentials remain one of the most common ways attackers gain initial access, precisely because they are easy to overlook and easy to exploit at scale once they are public.

What Kubero users should do

Anyone running Kubero should check whether JWT_SECRET is set to a long, random, unique value, and upgrade to the patched release. Deployments that have been running without the setting should treat their tokens as compromised: rotate the secret, revoke existing API tokens, and review logs for unexpected administrator activity.

Administrators should also restrict network access to the Kubero dashboard so it is not reachable from the open internet, and audit which accounts hold administrator roles. A forged token is only useful if the attacker can reach the service, so limiting exposure reduces the risk while patches are applied.

The flaw was assigned by VulnCheck, acting as the CVE numbering authority, and published in the NVD on 9 November 2026. No exploitation in the wild had been reported in the sources reviewed at the time of writing, but the simplicity of the attack means administrators should not wait to act.