CVE-2026-100548: OpenClaw before 2026.8.1 Credential Exposure via Embedding Fallback
OpenClaw (npm package 'openclaw') versions >= 2026.3.28 and < 2026.8.1 contain a credential exposure issue in memory embedding failover. When remote embedding fallback is configured and the primary embedding provider fails, the request can be sent to a different fallback provider while still reusing the primary provider's configured API key, causing that credential to be transmitted as a bearer token to an unintended vendor. The practical impact depends on the configured providers, whether failover occurs, and the privileges attached to the primary provider key. The issue is fixed in 2026.8.1; as a workaround, disable cross-provider embedding fallback or configure each provider with separate, narrowly scoped credentials.
Affected Software
Remediation
Recommended actions to resolve this vulnerability, in priority order.
- Upgrade
Upgrade
npm/openclawto a version that resolves this vulnerability.Fixed in 2026.8.1 - Configuration
Disable cross-provider embedding fallback.
OpenClaw embedding failover cross-provider embedding fallback = disabled - Configuration
Configure each embedding provider with separate, narrowly scoped credentials.
OpenClaw embedding providers provider credentials = separate, narrowly scoped credentials per provider
Event History
Frequently Asked Questions
Which deployments are exposed to this issue?
Deployments using OpenClaw versions 2026.3.28 through versions earlier than 2026.8.1 are affected only when remote embedding fallback is configured. Exposure requires the primary embedding provider to fail and a fallback provider to be used.
What must happen for a credential to be disclosed?
A primary embedding-provider failure must trigger failover to a different provider. The fallback request may then carry the primary provider's configured API key as a bearer token to that unintended provider.
How can exposure be reduced if upgrading is not immediately possible?
Disable cross-provider embedding fallback. Alternatively, configure every provider with separate credentials that are narrowly scoped.
What determines the impact if a key is sent to a fallback provider?
Impact depends on which providers are configured, whether failover occurs, and the privileges granted to the primary provider's API key.