GHSA-47Q7-97XP-M272: Cleartext Credential Exposure via Configuration Persistence in OpenClaw

The OpenClaw personal AI assistant supports a security best practice known as configuration interpolation, allowing users to reference environment variables in their openclaw.json file using the syntax ${VAR_NAME}. This ensures that sensitive secrets, such as LLM provider API keys (OpenAI, Anthropic) or bot tokens, remain in memory or environment files and are never written to static configuration storage.

However, a regression in the configuration I/O logic breaks this security model. When the application performs operations that require reading, modifying, and saving the configuration—specifically during automated updates, interactive configuration (openclaw configure), or self-healing routines (openclaw doctor --fix)—it fails to distinguish between the resolved runtime value and the original configuration source.

Consequently, the application overwrites the user's secure configuration file with the resolved in-memory state. A placeholder like ${OPENAI_API_KEY}, which is safe to check into version control, is replaced by the actual alphanumeric secret key sk-proj-..., which is strictly confidential. This transformation happens silently, often without the user's knowledge, until the file is inspected or inadvertently committed to a public repository.

The vulnerability resides in the configuration serialization pipeline located in src/config/config-io.ts. The root cause is a lack of separation between the canonical configuration (what is stored on disk) and the effective configuration (what is used in memory).

When OpenClaw initializes, it invokes a loader that parses the JSON file and immediately passes it through a resolution function, resolveConfigEnvVars. This function recursively walks the object tree and substitutes any string matching the pattern ${...} with the corresponding value from process.env. The resulting object is used by the application for all logic.

The critical flaw occurs in the writeConfigFile function. This function accepts the current configuration object state to save changes to disk. Because the application only maintains the resolved state in memory without keeping a reference to the original raw state or a map of interpolated fields, JSON.stringify serializes the actual secret values. The serialization logic assumes that the current value of a field is the desired persistent value, ignoring the fact that the value originated from an ephemeral environment source.

The following pseudo-code illustrates the logic flow responsible for the vulnerability. The application loads the config, interpolates it immediately, and then writes that interpolated version back to disk during updates.

Vulnerable Logic (src/config/config-io.ts)

// LOAD: Reads JSON and immediately destroys the reference to "${VAR}"
function loadConfig() {
  const raw = fs.readFileSync('openclaw.json', 'utf8');
  const config = JSON.parse(raw);
  // Vulnerability: Original formatting is lost here
  return resolveEnvVars(config);
}
 
// SAVE: Writes the resolved values (secrets) to disk
function saveConfig(updatedConfig) {
  // Vulnerability: Writes "sk-12345..." instead of "${API_KEY}"
  const output = JSON.stringify(updatedConfig, null, 2);
  fs.writeFileSync('openclaw.json', output);
}

Patched Logic (Conceptual)

The fix, introduced in PR #4900, implements a mechanism to preserve the original interpolation syntax. It likely involves tracking which fields contained variables or performing a reverse-lookup against the original raw configuration before saving.

function saveConfig(updatedConfig, originalRawConfig) {
  const outputConfig = clone(updatedConfig);
  
  // FIX: Restore ${VAR} references for fields that haven't changed logically
  for (const key of Object.keys(originalRawConfig)) {
    if (isInterpolated(originalRawConfig[key])) {
       // Revert the resolved value back to the placeholder
       outputConfig[key] = originalRawConfig[key];
    }
  }
  
  fs.writeFileSync('openclaw.json', JSON.stringify(outputConfig, null, 2));
}

Exploitation of this vulnerability is trivial and often accidental, triggered by standard maintenance commands. An attacker with local access could trigger this to persist ephemeral secrets, or a user could trigger it unknowingly.

Reproduction Steps:

1. Setup: Create an openclaw.json file utilizing environment variable interpolation for a sensitive field.

   {
     "llm": {
       "provider": "anthropic",
       "apiKey": "${ANTHROPIC_API_KEY}"
     }
   }

2. Environment: Export the corresponding secret in the current shell.

   export ANTHROPIC_API_KEY="sk-ant-api03-sensitive-secret-value"

3. Trigger: Execute a command that modifies configuration. The doctor command with the --fix flag is a reliable trigger as it attempts to normalize the configuration structure.

   openclaw doctor --fix

4. Verification: Inspect the file content. The placeholder is gone, replaced by the plaintext secret.

   cat openclaw.json
   # Output: "apiKey": "sk-ant-api03-sensitive-secret-value"

The primary impact of this vulnerability is the Unintentional Exposure of Sensitive Information (CWE-200) and Cleartext Storage of Sensitive Information (CWE-312). While the vulnerability requires local execution to trigger, the downstream effects can be severe in DevOps and collaborative environments.

• Version Control Leakage: Configuration files are frequently checked into Git repositories. If a developer runs a local update and then commits the changes (git commit -am "update config"), they may unknowingly push live production credentials to a shared or public repository.
• Persistence of Ephemeral Secrets: Security best practices dictate that secrets should exist only in memory or restricted environment files. This vulnerability violates that principle by writing secrets to the filesystem, where they are vulnerable to path traversal attacks, insecure backups, or unauthorized local read access.
• Silent Failure: The modification happens silently. There is no error message indicating that interpolation has been stripped, meaning the exposure may persist undetected for long periods.

Users must upgrade OpenClaw immediately to prevent further exposure. If you have run any maintenance commands on affected versions, your secrets may already be exposed on disk.

Immediate Steps:

1. Upgrade: Update OpenClaw to version v2026.2.7 or later. This version includes the fix from PR #4900 which correctly handles environment variable preservation.
2. Audit: Run grep -r "sk-" openclaw.json or manually inspect your configuration file to verify no cleartext secrets are present.
3. Rotate: If you discover cleartext secrets in your configuration file, assume they are compromised. Revoke the API keys immediately and generate new ones.
4. Sanitize: Revert the configuration file to use ${VAR} syntax manually.

Long-term Hardening: Ensure that openclaw.json is added to your .gitignore file if it contains any specific local configuration, or strictly use separate environment files (e.g., .env) that are never tracked.