openclaw - 💡(How to fix) Fix Security: skill SecretRef API keys still leak into exec child environments [1 comments, 2 participants]

Summary

Security regression / unresolved leak: SecretRef-managed secrets configured under skills.entries.<skill>.apiKey are still exported into child process environments spawned via the exec tool.

This is the same security class as #56441, but the closure conclusion in https://github.com/openclaw/openclaw/issues/56441#issuecomment-4320040318 is incorrect/incomplete: provider config-backed SecretRefs may no longer reproduce that exact path, but skill entry secrets still leak into process.env / spawned child envs.

Confirmed on OpenClaw 2026.5.4.

Impact

Any agent-spawned command can read secrets that were configured only for specific skills/tools.

That means unrelated binaries/scripts invoked via exec can receive API keys intended for narrow skill use only, e.g. Whisper/OpenAI or Google Places keys. A compromised dependency, CLI, shell script, package postinstall, or tool invoked by an agent can read and exfiltrate these secrets from its environment.

This defeats the expected isolation of SecretRef/file-backed secrets and makes skill-scoped secrets effectively process-wide.

This bug likely exists since March, which is especially bad for a security-sensitive secret handling issue.

Reproduction

Configure skill secrets using file-backed SecretRefs, for example:

{
  "entries": {
    "openai-whisper-api": {
      "apiKey": {
        "source": "file",
        "provider": "secretsfile",
        "id": "/openai/whisperApiKey"
      }
    },
    "goplaces": {
      "apiKey": {
        "source": "file",
        "provider": "secretsfile",
        "id": "/google/placesApiKey"
      }
    }
  }
}

Then from an agent session run any env-inspection command via exec, for example:

env > tmp/env

Inspect tmp/env.

Expected: skill-scoped SecretRef values must not be present in the generic child process environment.

Actual: resolved skill secrets are present in the spawned command environment.

Why #56441 was not actually resolved

#56441 was closed as "not reproducible" on current main after checking the provider config-backed path:

• provider SecretRefs resolving into runtime snapshot
• provider markers projected back into models.json
• model auth reading runtime/config state instead of requiring env export
• exec inheriting only sanitized process.env

That analysis does not cover this reproduction path.

The leaking secrets here are skill entry secrets, not models.providers.<id>.apiKey provider secrets. The closure comment therefore proves only that one provider-auth path may have been fixed; it does not prove that SecretRef-managed secrets are generally kept out of spawned child process environments.

The current behavior shows they are not.

Security expectation

Secrets configured for a skill entry should be injected only into the specific skill/tool execution path that requires them, and stripped from all generic exec child process environments.

At minimum, sanitizeHostExecEnv / the exec spawn path should denylist resolved SecretRef-derived env vars for skills, not only provider-level env vars or other known dangerous names.

A stronger fix would avoid exporting resolved SecretRef values into process-wide environment variables at all.

Environment

• OpenClaw version: 2026.5.4
• Secret source: file provider (secretsfile)
• Affected config area: skills.entries.<skill>.apiKey
• Confirmed affected skills: openai-whisper-api, goplaces
• Related issue: #56441