How API Key Leakage in Error Messages Gets You Pwned

Introduction

Most developers know they shouldn't hardcode API keys in source code. Most developers use .env files. Most developers think that's enough.

It isn't.

There's a subtler, far more common attack surface that rarely gets discussed: your API key leaking through error messages at runtime. This is exactly what was happening in gemini-eval.mjs, and it's the kind of vulnerability that can go undetected for months while your credentials quietly flow into log files, CI/CD pipelines, and monitoring dashboards.

This post breaks down the vulnerability, the fix, and the broader lessons every developer working with third-party APIs should internalize.

The Vulnerability Explained

What Was Happening?

The gemini-eval.mjs script integrates with Google's Generative AI API. Like most API integrations, it loads a secret key from an environment variable:

const apiKey = process.env.GEMINI_API_KEY;

This part is fine. The problem was in the error handling block:

// BEFORE — Vulnerable code
} catch (err) {
  console.error('❌  Gemini API error:', err.message);
  if (err.message?.includes('API_KEY')) {
    console.error('    Check your GEMINI_API_KEY in .env');
  } else if (err.message?.includes('quota') || err.message?.includes('rate')) {
    console.error('    You may have hit the free-tier rate limit. Wait 60s and retry.');
  }
  process.exit(1);
}

See the issue? err.message is logged raw and unfiltered.

When an API call fails — especially with authentication errors — many API providers include context in the error message to help developers debug. That context can include the key that was used in the request. A response like:

Invalid API key: AIzaSyD3x...your-actual-key...Qf8

...gets printed verbatim to stdout/stderr.

Why This Is Classified as Critical

The severity isn't just about one error message on one developer's laptop. Consider the full blast radius:

1. CI/CD Pipeline Logs
Most teams run scripts like this in automated pipelines. GitHub Actions, GitLab CI, Jenkins, CircleCI — they all capture stdout/stderr. If your pipeline is set to verbose output, or if an API error triggers during a run, that key is now sitting in your build logs. Many of these systems retain logs for 90+ days by default.

2. Log Aggregation Systems
If your team ships logs to Datadog, Splunk, Elastic, or similar platforms, error messages flow there automatically. Now your API key is indexed, searchable, and potentially accessible to anyone with read access to your logging infrastructure.

3. Terminal History and Screen Recordings
Developers running this locally may have terminal sessions recorded, or their shell history synced. A single failed API call during a demo or pair programming session exposes the key.

4. Error Monitoring Tools
Tools like Sentry capture exception messages and their context. An unhandled error containing your API key gets shipped to a third-party service.

5. Shared Screens and Screenshots
It sounds trivial, but "I'll just share my screen to debug this" has leaked more secrets than most people realize.

The Real-World Attack Scenario

Here's how this plays out in practice:

1. Developer runs gemini-eval.mjs in a GitHub Actions workflow
2. The Gemini API returns a quota error that includes the key in its message body
3. The error is logged to the Actions console: ❌ Gemini API error: Quota exceeded for key AIzaSy...
4. The workflow log is public (common for open-source repos) or accessible to a contractor
5. Attacker extracts the key, uses it to make API calls billed to the victim's account
6. Victim discovers the breach weeks later via an unexpected Google Cloud invoice

This is not a theoretical attack. API key theft via log scraping is one of the most common credential compromise vectors documented by cloud providers.

The Fix

What Changed

The fix is elegant and minimal. Instead of logging err.message directly, the error message is first sanitized by replacing any occurrence of the actual API key with the string [REDACTED]:

// AFTER — Fixed code
} catch (err) {
  const sanitizedMsg = (err.message || '').split(apiKey).join('[REDACTED]');
  console.error('❌  Gemini API error:', sanitizedMsg);
  if (sanitizedMsg.includes('API_KEY')) {
    console.error('    Check your GEMINI_API_KEY in .env');
  } else if (sanitizedMsg.includes('quota') || sanitizedMsg.includes('rate')) {
    console.error('    You may have hit the free-tier rate limit. Wait 60s and retry.');
  }
  process.exit(1);
}

How It Works

The redaction pattern (err.message || '').split(apiKey).join('[REDACTED]') is a deliberate choice:

• .split(apiKey).join('[REDACTED]') — This is a safe string replacement idiom in JavaScript. Unlike String.prototype.replace() with a string argument (which only replaces the first occurrence), splitting on the key and rejoining replaces all occurrences of the key in the message.

• (err.message || '') — The nullish fallback prevents a crash if err.message is undefined, which can happen with certain error types.

• Consistent use of sanitizedMsg — The fix also updates all subsequent references from err.message to sanitizedMsg, ensuring the sanitized version is used throughout the catch block. This is important: a partial fix that redacts the console.error but leaves err.message in a conditional check would still be safe here, but using the sanitized version consistently is a better habit.

The Second Fix: Regex Injection Prevention

The PR also addresses a second, related issue in the extract function:

// BEFORE — Vulnerable to ReDoS
const extract = (key) => {
  const m = block.match(new RegExp(`${key}:\\s*(.+)`));
  return m ? m[1].trim() : 'unknown';
};

// AFTER — Safe string parsing
const extract = (key) => {
  const prefix = `${key}:`;
  const lines = block.split('\n');
  for (const line of lines) {
    const trimmed = line.trimStart();
    if (trimmed.startsWith(prefix)) {
      return trimmed.slice(prefix.length).trim();
    }
  }
  return 'unknown';
};

The original code constructed a RegExp from the key parameter. If key contained regex special characters, this could cause unexpected behavior or, in a worst case, a ReDoS (Regular Expression Denial of Service) attack. The replacement uses straightforward string operations — splitting on newlines and checking for a prefix — which is both safer and more readable.

Conclusion

This vulnerability is a reminder that secrets don't only leak through obvious channels. You can do everything right — use .env files, never commit credentials, use environment variables in CI — and still expose your API key through a single unguarded console.error call.

The fix here is small: three lines changed. But the thinking behind it matters more than the lines themselves. The developer who wrote the fix internalized a principle: treat your secret values as radioactive. Before any string leaves your process — whether to a log file, a monitoring service, or a terminal — ask yourself: could my secret be in here?

A few key takeaways to carry forward:

• Error messages from external APIs can contain your credentials. Always sanitize before logging.
• CI/CD logs are a primary attack surface for credential theft. Treat them as semi-public.
• Defense in depth applies to secrets. Code-level sanitization + CI masking + secret scanning is better than any one alone.
• Small fixes matter. Three lines of code eliminated a critical exposure vector. Security doesn't always require a massive refactor.

Write the sanitization code. Add the secret scanner. Rotate the keys. The attacker scraping your build logs is counting on you to skip these steps.

This vulnerability was identified and fixed by OrbisAI Security. Automated security scanning catches issues like this before they reach production.