CVE-2026-81101: Airtable MCP CLI before 0.2.5 Credential Disclosure via Unvalidated Configured Endpoint
The configure command accepted any endpoint URL and stored it beside the user's access token. ConfigureCommand.execute in src/cli.ts persisted the value given to its endpoint option into the user profile without passing it through createSafeUrl in src/config.ts, the helper that already restricted the environment-variable form of the same setting to the vendor's own hosts over HTTPS. Because the connect path in src/mcp.ts attaches the stored token as a bearer credential on every request to the configured endpoint, a user who was persuaded to run configure with an endpoint of the attacker's choosing sent their personal access token to that destination on each subsequent invocation. Version 0.2.5 applies the same helper to the option.
Affected Software
Remediation
Recommended actions to resolve this vulnerability, in priority order.
- Upgrade
Upgrade
Airtable MCP CLIto a version that resolves this vulnerability.Fixed in 0.2.5 - Configuration
Ensure ConfigureCommand.execute (src/cli.ts) persists the configured endpoint value only after applying the same createSafeUrl helper used for the environment-variable form (src/config.ts), so tokens are only sent to vendor-approved HTTPS hosts.
Airtable MCP CLI (configuration / endpoint URL storage) endpoint option handling (use createSafeUrl for persisted endpoint) = Use createSafeUrl when persisting the endpoint option to the user profile
Event History
Frequently Asked Questions
Who is exposed to credential disclosure?
Users of Airtable MCP CLI before 0.2.5 are exposed if they run the configure command with an attacker-controlled endpoint. The attacker must persuade the user to perform that configuration step; no existing authentication or privileges are required.
What credential is disclosed and when is it sent?
The CLI sends the user's personal access token as a bearer credential to the configured endpoint. After a malicious endpoint has been saved, the token is sent on each subsequent connect-path invocation.
Are default configurations affected?
The issue affects the endpoint supplied through the configure command option. The environment-variable form already used URL validation that restricted endpoints to the vendor's HTTPS hosts.
What can be done before upgrading?
Avoid running configure with untrusted endpoint values and verify that the endpoint stored in the user profile is an approved HTTPS vendor host. If a suspicious endpoint was configured, replace it with an approved endpoint and treat the associated personal access token as potentially exposed.