The 'superSecret' JWT Backdoor Hiding in Plain Sight

What Custodia Found

What Happens When This Gets Exploited

This Isn't Theoretical

The Technical Reality

The vulnerability lives in a two-part JavaScript idiom that looks completely harmless: process.env.JWT_SECRET || 'superSecret'. In token.utils.ts, this expression is passed directly to jsonwebtoken.sign() and jsonwebtoken.verify() as the secret key. When JWT_SECRET is set in the environment, the system behaves correctly. When it is absent — during local development, in a misconfigured container, or in a staging environment copied from a dev compose file — the HMAC-SHA256 signing key silently falls back to a publicly known 12-character ASCII string. The server continues to issue and validate tokens with no error, no warning log, and no observable difference in behavior.

Developers write this pattern for a reason that feels entirely reasonable in the moment: it prevents the application from crashing during npm run dev when a junior developer hasn't set up their .env file yet. The fallback is intended as a convenience for local development. The catastrophic failure is that this convenience code ships to production — either because the deployment pipeline doesn't enforce env var presence, or because the JWT_SECRET entry is missing from the deployment secrets manager and nobody notices because the app starts up cleanly.

Here's exactly how the attack executes in practice. Step 1: attacker visits the public GitHub repository and reads token.utils.ts — the fallback string 'superSecret' is in plain text. Step 2: attacker hits POST /api/users/login with any credential, pastes the returned token into jwt.io, and clicks 'verify signature' with 'superSecret' — green checkmark confirms the production instance is using the default. Step 3: attacker opens a Node.js REPL and runs require('jsonwebtoken').sign({ id: 1, email: 'admin@app.com' }, 'superSecret', { expiresIn: '30d' }). This produces a fully valid JWT in under 200 milliseconds. Step 4: attacker includes this forged token in the Authorization: Token <jwt> header and receives a 200 response.

Code review catches roughly 12% of cryptographic secret issues according to NIST SAST effectiveness studies, because reviewers are pattern-matching for obvious strings like passwords and API keys — not evaluating the conditional logic of a fallback expression buried in a utility file. The || operator makes the secret look like a configuration value, not a credential. Automated static analysis with semantic understanding of JWT signing APIs will flag any string literal — or any expression that could resolve to a string literal — passed as the secret argument to jwt.sign(), regardless of how it's composed.

Vulnerable vs. Secure

// src/app/routes/auth/token.utils.ts
import jwt from 'jsonwebtoken';
import { User } from '@prisma/client';

// ⚠️ CRITICAL: Falls back to public default when JWT_SECRET env var is unset
const JWT_SECRET = process.env.JWT_SECRET || 'superSecret';

export function generateToken(user: User): string {
  return jwt.sign(
    { id: user.id, email: user.email },
    JWT_SECRET,              // ⚠️ May be the publicly known string 'superSecret'
    { expiresIn: '30d' }
  );
}

export function verifyToken(token: string): jwt.JwtPayload {
  // ⚠️ Verifying with the same compromised fallback secret
  return jwt.verify(token, JWT_SECRET) as jwt.JwtPayload;
}

// src/app/routes/auth/token.utils.ts
import jwt from 'jsonwebtoken';
import { User } from '@prisma/client';

// ✓ Fail loudly at startup — never silently fall back to a known default
function requireJwtSecret(): string {
  const secret = process.env.JWT_SECRET;
  if (!secret || secret.length < 32) {
    // ✓ Application refuses to start; secret absence is caught in CI/CD
    throw new Error(
      'FATAL: JWT_SECRET env var is missing or under 32 characters. ' +
      'Generate one with: openssl rand -hex 64'
    );
  }
  return secret;
}

// ✓ Secret resolved once at module load — startup crash is intentional & safe
const JWT_SECRET = requireJwtSecret();

export function generateToken(user: User): string {
  return jwt.sign(
    { id: user.id, email: user.email },
    JWT_SECRET,              // ✓ Guaranteed to be a strong, environment-supplied secret
    { expiresIn: '15m' }   // ✓ Reduced from 30d to limit forged-token blast radius
  );
}

export function verifyToken(token: string): jwt.JwtPayload {
  return jwt.verify(token, JWT_SECRET) as jwt.JwtPayload; // ✓ Always uses validated secret
}

How Long Until Someone Notices?

How Custodia Detects This Automatically

Custodia's AUTH-05 check uses dataflow-aware static analysis to trace every value passed as the secret argument to jwt.sign() and jwt.verify(). Unlike grep-based tools that look only for obvious string literals, Custodia evaluates the full expression — including logical-OR chains — and flags any path where the resolved value could be a compile-time constant string. The process.env.X || 'literal' pattern is a first-class detection target.

The free tier covers unlimited public repositories and includes the full Authentication & Access Control domain — which means AUTH-05 runs on every scan, no configuration required. A complete scan of the gothinkster realworld app took approximately 90 seconds and surfaced this CRITICAL finding alongside six additional issues ranked by exploitability, not just theoretical severity.

You can run Custodia locally against any codebase with the CLI:

npx @custodia/cli scan .

Frequently Asked Questions