How Hardcoded Credentials Happen in Node.js Express Routes and How to Fix Them

Introduction

In routes/bing-routes.js, we discovered a critical hardcoded credentials vulnerability at line 125 that exposed a WordPress application password directly in the source code. The vulnerable code used a common but dangerous pattern:

const wpPass = process.env.WORDPRESS_APP_PASS || 'V2W3 GbQC Sbgj eeX7 9klH GHLS';

This single line created a significant security risk—if the WORDPRESS_APP_PASS environment variable wasn't set, the code would fall back to using a real, working WordPress credential. Anyone with read access to this repository could extract the password V2W3 GbQC Sbgj eeX7 9klH GHLS and use it to authenticate as the admin user against the WordPress API at 3dput.com.

For developers building integrations with external services, this pattern represents a common trap: what seems like a helpful fallback for development actually creates a production security hole.

The Vulnerability Explained

The vulnerability existed in the registerBingRoutes function, which handles IndexNow URL submission to Bing through a WordPress plugin. Here's the vulnerable code block:

// Use the WordPress IndexNow plugin which handles key file management
const wpApiBase = process.env.WORDPRESS_API_URL || 'https://3dput.com/wp-json';
const wpUser = process.env.WORDPRESS_USER || 'admin';
const wpPass = process.env.WORDPRESS_APP_PASS || 'V2W3 GbQC Sbgj eeX7 9klH GHLS';
const wpAuth = Buffer.from(`${wpUser}:${wpPass}`).toString('base64');

Why This Is Dangerous

The fallback pattern process.env.VAR || 'default' is common in Node.js applications, but it becomes a critical vulnerability when the default value is a real credential. This code:

1. Exposes credentials in version control: The password is visible to anyone who can read the repository—including public repositories, leaked backups, or insider threats
2. Creates a working attack vector: The credential isn't a placeholder; it's a real WordPress application password that grants API access
3. Enables silent exploitation: An attacker can use these credentials without triggering any alerts in the application itself

Attack Scenario

An attacker who gains read access to this codebase—whether through a public GitHub repository, a leaked backup, or compromised developer credentials—can:

1. Extract the hardcoded credential: V2W3 GbQC Sbgj eeX7 9klH GHLS
2. Identify the target WordPress installation: https://3dput.com/wp-json
3. Authenticate as the admin user using the WordPress REST API
4. Perform any actions the admin user is authorized for, potentially including:
   - Creating/modifying posts
   - Installing plugins
   - Accessing sensitive data
   - Escalating privileges further

The Base64-encoded authentication header would be:

Authorization: Basic YWRtaW46VjJXMyBHYlFDIFNiZ2ogZWVYNyA5a2xIIEdITFM=

The Fix

The fix removes all hardcoded fallback values and implements proper validation to ensure credentials are configured via environment variables before the route handler proceeds.

Before (Vulnerable)

const wpApiBase = process.env.WORDPRESS_API_URL || 'https://3dput.com/wp-json';
const wpUser = process.env.WORDPRESS_USER || 'admin';
const wpPass = process.env.WORDPRESS_APP_PASS || 'V2W3 GbQC Sbgj eeX7 9klH GHLS';
const wpAuth = Buffer.from(`${wpUser}:${wpPass}`).toString('base64');

After (Fixed)

const wpApiBase = process.env.WORDPRESS_API_URL || 'https://3dput.com/wp-json';
const wpUser = process.env.WORDPRESS_USER;
const wpPass = process.env.WORDPRESS_APP_PASS;
if (!wpUser || !wpPass) {
  return sendJSON(res, 503, { error: 'WordPress credentials not configured' });
}
const wpAuth = Buffer.from(`${wpUser}:${wpPass}`).toString('base64');

Key Changes

1. Removed hardcoded fallbacks: Both wpUser and wpPass now read directly from environment variables without fallback values
2. Added validation check: The code now explicitly checks if credentials are configured before proceeding
3. Fail-safe error handling: If credentials aren't configured, the endpoint returns a 503 Service Unavailable status with a clear error message
4. No credential leakage in errors: The error message doesn't reveal any information about expected credentials or their format

This approach follows the "fail closed" security principle—if the system isn't properly configured, it refuses to operate rather than falling back to potentially insecure defaults.

Key Takeaways

• The || 'fallback' pattern is dangerous for credentials: What works for URLs or ports becomes a critical vulnerability for passwords and API keys
• The credential V2W3 GbQC Sbgj eeX7 9klH GHLS was a real WordPress application password: This wasn't a placeholder—it was an exploitable credential
• Fail-safe validation prevents silent security failures: Returning a 503 error when credentials aren't configured is safer than proceeding with defaults
• Environment variable validation belongs at startup: Catching missing configuration early prevents runtime security issues
• This vulnerability affects downstream consumers: As a Node.js library, any application using this package inherits the security risk

How Orbis AppSec Detected This

• Source: Hardcoded string literal 'V2W3 GbQC Sbgj eeX7 9klH GHLS' in source code
• Sink: Buffer.from(\${wpUser}:${wpPass}`).toString('base64')used for HTTP Basic Authentication inroutes/bing-routes.js:126`
• Missing control: No validation that credentials come exclusively from secure configuration; fallback to hardcoded values when environment variables are unset
• CWE: CWE-798 (Use of Hard-coded Credentials)
• Fix: Removed hardcoded fallback values and added validation to return 503 error if environment variables are not configured

Orbis AppSec automatically detected this vulnerability and opened a pull request with the fix. Try Orbis AppSec on your repositories to find and fix issues like this automatically.

Conclusion

Hardcoded credentials remain one of the most common and dangerous vulnerabilities in modern applications. The pattern of using environment variables with fallback defaults—while convenient for development—creates serious security risks when real credentials are used as those defaults.

This fix demonstrates the importance of explicit validation over implicit fallbacks. By requiring environment variables to be set and failing safely when they're not, we eliminate the risk of credential exposure while maintaining clear operational requirements.

For developers working on similar integrations, remember: if a credential is in your source code, it's already compromised. Always treat credentials as external configuration that must be explicitly provided, never as values that can be embedded in code.