@AI-SDK/HARNESS-OPENCODE · GHSA-4mqq-99j3-3hmv · AI agents & MCP
FIX → 1.0.135 · 1.0.137 · 1.0.133 · 1.0.71
When an AI SDK Harness session is resumed with a credential environment variable that was not in the saved session, that credential is passed into the sandbox in raw form instead of as a placeholder. Code or agent activity inside the sandbox can then read and exfiltrate the credential, such as a model-provider API key, source-control token or OAuth token.
first public Sep 28, 2026 · 1 source
Could this affect your app?
Free first check from your website. Connect your repo for the full answer.
Applications that use an affected AI SDK Harness adapter with credential brokering on a network sandbox that supports request transformations, and that resume sessions from previously saved lifecycle state. Exposure requires a credential variable that was absent from the saved session, for example after changing providers or authentication modes. Fresh sessions and credential rotations that keep the same variable names were not affected in the tested scenarios.
Not affected if fresh-sessions-only, no-session-resume, same-credential-names
Who cares agents, ai-sdk, npm, sandbox
A vulnerability in AI SDK Harness credential brokering can expose host credentials to sandboxed code when an existing session is resumed with a newly introduced credential environment variable.
Credential brokering normally supplies non-secret placeholders to the sandbox and substitutes real credentials outside the sandbox boundary for approved outbound requests. Affected adapters reuse the credential-placeholder map saved with the previous session without ensuring that it covers the current authentication environment. As a result, newly introduced credentials can be passed into the sandbox without being replaced by placeholders.
An attacker who can execute code or influence agent activity inside an affected resumed sandbox may read and exfiltrate exposed credentials without escaping the sandbox.
Depending on the adapter and authentication configuration, exposed credentials may include model-provider API keys, source-control tokens, or OAuth tokens. Subsequent access depends on the permissions and scopes granted to those credentials and may include access to private data, unauthorized changes, or paid API usage.
Exploitation requires all of the following:
For example, changing providers or authentication modes between session creation and resume can introduce a new credential variable.
Fresh sessions and credential rotations that retain the same credential variable names were not affected in the tested scenarios.
Check it with your coding agent
It reads this page and tells you if your code is affected.
Are you affected?
Ask from here. InfraStack checks the affected versions against your stack and answers in your inbox.
InfraStack checks the affected versions against your stack and answers in Slack, with the evidence and the fix.
@ai-sdk/harness* package in your lockfile against the fixed versions listed in the sources.Upgrade to 1.0.135 · 1.0.137 · 1.0.133 · 1.0.71
@ai-sdk/harness-opencode to 1.0.135 or later@ai-sdk/harness-claude-code to 1.0.137 or later@ai-sdk/harness-codex to 1.0.135 or later@ai-sdk/harness-deepagents and @ai-sdk/harness to 1.0.133 or later@ai-sdk/harness-acp to 1.0.71 or laterA fix is proposed in https://github.com/vercel/ai/pull/21599.
The fix reconciles the sandbox credential environment with the current authentication environment on every start and resume. It preserves placeholders for matching credential names, generates placeholders for newly introduced credentials, and removes entries for credentials no longer present.
Until patched versions are available, create a fresh session and sandbox whenever the credential variable names change. Do not reuse saved lifecycle state across those transitions.
If an affected session may have exposed credentials to untrusted sandbox activity, revoke or rotate those credentials and review their usage.
Reported by 0x4ym3n through HackerOne.