Bleichenbacher Attack in Express with Bearer Tokens

A Bleichenbacher attack is a cryptographic padding oracle attack first described in 1998 against PKCS#1 v1.5–style RSA encryption. In the context of an Express API using Bearer tokens, the vulnerability arises when token validation or error handling behaves as an oracle: it distinguishes between a padding error and other failures (e.g., signature mismatch, malformed token) and returns different responses or status codes. An attacker can exploit these timing or behavioral differences to gradually decrypt or forge a Bearer token without knowing the secret or private key.

In Express, this often maps to endpoints that validate JWTs or custom encrypted tokens. If the server returns 401 with a message like “invalid padding” for some invalid tokens and “invalid signature” for others, or if it takes measurably longer to process certain malformed ciphertexts, it leaks information. For example, an endpoint that uses node-rsa or a low-level RSA operation with PKCS#1 v1.5 padding and does not use constant-time verification can be probed via many crafted Bearer tokens to recover the plaintext or forge a valid token.

Consider an Express route that extracts a Bearer token and attempts decryption before verifying integrity:

const jwt = require('jsonwebtoken');
const app = require('express')();

app.get('/profile', (req, res) => {
  const auth = req.headers.authorization;
  if (!auth || !auth.startsWith('Bearer ')) {
    return res.status(401).json({ error: 'missing_token' });
  }
  const token = auth.split(' ')[1];
  try {
    // Vulnerable if verification leaks padding vs other errors
    const decoded = jwt.verify(token, 'my-secret-key');
    res.json({ profile: decoded.sub });
  } catch (err) {
    // Different error messages can act as an oracle
    if (err.name === 'JsonWebTokenError') {
      res.status(401).json({ error: 'invalid_token' });
    } else if (err.name === 'TokenExpiredError') {
      res.status(401).json({ error: 'token_expired' });
    } else {
      res.status(401).json({ error: 'invalid_token' });
    }
  }
});

If the error handling distinguishes causes, an attacker can send many tokens and observe responses and timing to infer validity or eventually decrypt. Even if the JWT library itself uses constant-time checks, surrounding logic or non-cryptographic checks elsewhere can reintroduce the oracle condition.

Moreover, if the Bearer token is not a JWT but a custom encrypted blob where padding errors are surfaced to the client, the same class of attack applies. Express APIs that accept Bearer tokens in headers, cookies, or query parameters are all potential targets if validation leaks information.

Remediation focuses on making token validation non-oracular and avoiding cryptographic operations that are susceptible to Bleichenbacher-style attacks. For JWTs, prefer algorithms that do not rely on reversible RSA decryption (e.g., use HS256 with a strong secret or RS256 with proper libraries), and ensure errors are handled uniformly. Avoid returning implementation details in responses, and use constant-time comparison where relevant.

Example of a safer Express route that validates Bearer tokens with uniform error handling:

const jwt = require('jsonwebtoken');
const app = require('express')();

function sendUnauthorized(res) {
  // Always return the same status and shape; no detail leaks
  return res.status(401).json({ error: 'unauthorized' });
}

app.get('/profile', (req, res) => {
  const auth = req.headers.authorization;
  if (!auth || !auth.startsWith('Bearer ')) {
    return sendUnauthorized(res);
  }
  const token = auth.split(' ')[1];
  try {
    // Use strong secret/key and avoid algorithms that require padding decryption
    const decoded = jwt.verify(token, process.env.JWT_SECRET, { algorithms: ['HS256'] });
    res.json({ profile: decoded.sub });
  } catch (err) {
    // Uniform error path to prevent oracle behavior
    return sendUnauthorized(res);
  }
});

If you must work with asymmetric keys, use libraries that implement RS256/ES256 correctly and avoid PKCS#1 v1.5 padding where possible; prefer RS256 with PSS padding. Also, enforce strict token structure checks before attempting cryptographic validation to reduce unnecessary processing that may introduce timing variance.

For custom encrypted Bearer tokens, do not expose padding or decryption errors. Instead, perform decryption and then validate integrity in a single constant-time step, or use an authenticated encryption mode (e.g., AES-GCM) that does not require padding. Ensure that any failure results in the same generic response and similar processing time.

Finally, apply defense in depth: rate-limit authentication endpoints, rotate secrets regularly, and audit dependencies for known vulnerabilities (e.g., older jsonwebtoken versions with parser confusion issues). These measures reduce the practical impact of any residual oracle conditions.