Kubero 3.0.0 through 3.1.1 Authentication Bypass via Hardcoded JWT Secret
Affects Kubero 3.0.0 through 3.1.1 deployments that leave JWT_SECRET unset, so the hardcoded fallback signing secret is used. No vendor rating is given and no fixed version is listed.
Written by anthropic/claude-haiku-5.5 from the sources below. Verify against them.
- Exploited
- No known exploitation
- Fix
- No fix listed
- Who is exposed
- Not reported
Do first: Workaround: Set JWT_SECRET to an operator-supplied, deployment-specific random secret
- Last modified
- A 0-100 score for how much a CVE matters across the industry: exploitation, exposure, how widely the software is used, severity and whether a fix exists.What do these mean? →
- 31/100 · provisional
- How many real-world setups can hit the bug, from the vendor's advisory and CISA data. It does not know your setup.What do these mean? →
- Unclear
- Whether working attack code is public (Exploit-DB, Metasploit, Nuclei or GitHub). Public code makes attacks easier.What do these mean? →
- None on Exploit-DB, Metasploit or GitHub
Summary
Kubero versions 3.0.0 through 3.1.1 are affected by an authentication bypass that lets an unauthenticated attacker on the network take full administrative control by forging a JWT. The flaw occurs when JWT_SECRET is unset, because the software falls back to a hardcoded signing secret that attackers can use to create tokens with arbitrary roles and permissions, which the application accepts without checking the database.
Read the original description
Kubero 3.0.0 through 3.1.1 contains an authentication bypass vulnerability that allows unauthenticated remote attackers to forge administrative JWTs by using a hardcoded fallback signing secret when JWT_SECRET is unset. Attackers can sign tokens with arbitrary role, userGroups and permissions claims, which JwtStrategy.validate() trusts without a database lookup, to take control of pipelines, applications, users and API tokens.
cve.now Index
- Exploitation?/40Unknown. No CISA SSVC exploitation rating yet
- Exposure17/25No login or user action needed, reachable over the network without a login · Unknown: Advisories don't say whether default setups are affected
- Reach?/20Unknown. No tracked technology or package matched
- Severity9.3/10CVSS 9.3
- No patch5/5No patch listed yet
What would change the score
- Would score about 76 if added to CISA KEV
- Would score about 71 if CISA's SSVC rates exploitation active
- Would score about 36 if advisories confirm default setups are exposed
What to do
Workaround: Set JWT_SECRET to an operator-supplied, deployment-specific random secret
Timeline
- CVE published
- First seen by cve.now
- Posted on X by cve.now
Affected versions
- kubero-dev kubero
From 3.0.0 · through 3.1.1
Evidence 4
- Report
- Repository
- Repository
- Link
Corrections
None so far.
Something wrong on this page? Report an error. Every fix is listed here.
Questions about CVE-2026-125370
Is CVE-2026-125370 being exploited?
It is not in CISA's Known Exploited Vulnerabilities catalog, and CISA's SSVC assessment does not mark exploitation as active. That does not mean it has not been attacked: vendors and researchers can report attacks before CISA lists them. No public exploit code is tracked.Source: cve.now feed data
What does this mean?
Kubero signs its login tokens with a fallback secret that is written into the code when JWT_SECRET is not set. Anyone who knows that secret can forge administrator tokens and take control of pipelines, applications, users and API tokens.Source: vulncheck.com, github.com
Which versions are affected by CVE-2026-125370?
kubero: from 3.0.0 through 3.1.1.Source: cve.now feed data
Am I affected, and how do I check?
Versions 3.0.0 through 3.1.1 are in range. The setup at issue is a deployment that does not set JWT_SECRET to a deployment-specific secret; check the JWT_SECRET setting in the deployment configuration to see whether it is set.Source: vulncheck.com, github.com
How do I fix CVE-2026-125370?
No fixed version is listed in the checked facts, so there is no confirmed upgrade target. Set JWT_SECRET to an operator-supplied, deployment-specific random secret.Source: vulncheck.com, github.com
What if there's no patch?
Set JWT_SECRET to an operator-supplied, deployment-specific random secret before starting the authentication module. This removes the hardcoded fallback that the bug depends on.Source: vulncheck.com, github.com