Intelligence
criticalVulnerabilityActive

Hardcoded JWT Secret in go-base Boilerplate Enables Token Forgery and Authentication Bypass

Go REST API boilerplate ships with hardcoded JWT secret 'random' in both template and code defaults, allowing attackers to forge valid authentication tokens and bypass access controls entirely.

S
Sebastion

CVE References

Affected

github.com/dhax/go-base

Vulnerability Analysis

1. Root Cause & Impact

This is a CWE-798 (Hardcoded Credentials) vulnerability compounded by failed mitigation. The JWT signing secret defaults to the literal string "random" across multiple code paths: the template dev.env file, a Viper configuration fallback in cmd/serve.go, and the JWT tokenizer in auth/jwt/tokenauth.go. Because HS256 (HMAC-SHA256) is symmetric, any attacker who knows or can guess the signing secret can generate valid, trusted JWT tokens indistinguishable from legitimately issued ones. The impact is complete authentication bypass: an attacker can issue tokens with arbitrary claims (user ID, roles, permissions) and access any resource protected by JWT validation.

2. PoC Significance & Preconditions

This vulnerability is trivial to exploit: the secret is discoverable through public repository inspection, environment file leakage, or default deployment artifacts. The PoC demonstrates that the weak mitigation (checking only the literal string "random" before auto-generating a key) fails because:

  • Developers copying the boilerplate often skip or misconfigure the environment setup
  • The code-level fallback ensures the weak secret persists even if dev.env is deleted
  • Non-persistent auto-generated keys are only valid for the current process lifetime, offering no real security

No special preconditions exist; any deployment using this boilerplate with default configuration is vulnerable. The 1,685 GitHub stars suggest widespread adoption risk.

3. Detection Guidance

Configuration Indicators:

  • Grep for AUTH_JWT_SECRET=random in .env files or commit history
  • Search for viper.SetDefault("auth_jwt_secret", "random") in codebase
  • Check deployed container images and configuration management systems for hardcoded "random" values

Runtime Indicators:

  • Monitor JWT token issuance logs for patterns (all tokens from same user/timestamp clusters)
  • Detect JWT validation failures followed by successful authentication (token refresh exploitation)
  • Alert on authentication tokens with impossible claims (e.g., admin role for service accounts)
  • Cross-reference token issuance times against application logs; forged tokens will lack corresponding authentication events

Log Signatures:

  • Search security logs for JWT decode/validation anomalies
  • Look for permission escalation patterns in access logs immediately post-authentication

4. Mitigation Steps

Immediate Actions:

  1. Patch: Update github.com/dhax/go-base to a version where AUTH_JWT_SECRET defaults to a cryptographically random value (minimum 256 bits) or is marked required with no fallback
  2. Audit: Search all deployments, repositories, and backups for instances of AUTH_JWT_SECRET=random or related hardcoded secrets
  3. Rotate: Generate new JWT secrets for all affected deployments; invalidate all existing tokens and force re-authentication
  4. Configuration: Implement mandatory environment variable validation—fail fast if AUTH_JWT_SECRET is unset or equals "random"

Long-term Controls:

  • Use asymmetric JWT signing (RS256/ES256) with public/private key pairs; secrets are easier to manage than symmetric keys in distributed systems
  • Store JWT secrets in a secrets manager (HashiCorp Vault, AWS Secrets Manager) rather than .env files
  • Implement strict pre-commit hooks to block commits containing hardcoded credentials or boilerplate-unsafe defaults
  • Add automated secret scanning to CI/CD pipelines

5. Risk Assessment

Likelihood of Exploitation: Very high. The boilerplate nature and public repository make the vulnerability trivially discoverable. Developers often use boilerplates as-is without security hardening, especially in early-stage projects or learning environments. The 1,685 stars suggest active use in production systems.

Threat Actor Interest: Critical. Unauthenticated token forgery is a high-value attack for:

  • Credential stuffing and account takeover campaigns
  • Lateral movement within organizations using the boilerplate
  • Privilege escalation (forge admin tokens)
  • Data exfiltration (bypass authorization checks)

Wild Exploitation: Expect active exploitation targeting publicly-known instances of this boilerplate. Automated scanning of GitHub Actions logs, Docker registries, and cloud metadata endpoints will rapidly identify vulnerable deployments. This vulnerability is attractive for both opportunistic and targeted attacks because it requires zero zero-days and enables complete application compromise.