github · airtable-mcp-serverbbb88b457dc7

Evidence

// Extract MCP Bundle to test directory

			const testDir = 'test-mcpb-client';

			execSync(`rm -rf ${testDir}`);

			execSync(`mkdir -p ${testDir} && unzip -q airtable-mcp-server.mcpb -d ${testDir}`);

			// Start the MCP server from the extracted MCP Bundle

RemediationAI

The problem is that `execSync()` with template literals interpolates `testDir` directly into the shell command, allowing command injection if `testDir` is attacker-controlled. Replace both `execSync()` calls with the `fs` module: use `fs.rmSync(testDir, { recursive: true, force: true })` instead of `execSync('rm -rf ...')` and `fs.mkdirSync(testDir, { recursive: true })` plus a separate `unzip` library call or `child_process.execFile()` with array arguments. This eliminates shell interpretation entirely. Verify by confirming the test directory is created and cleaned up correctly without spawning a shell process.

Evidence

// Extract MCP Bundle to test directory

			const testDir = 'test-mcpb-client';

			execSync(`rm -rf ${testDir}`);

			execSync(`mkdir -p ${testDir} && unzip -q airtable-mcp-server.mcpb -d ${testDir}`);

			// Start the MCP server from the extracted MCP Bundle

			const serverProcess = spawn('node', [path.join(testDir, 'dist/main.js')], {

RemediationAI

The problem is that `execSync()` with template literals interpolates `testDir` directly into the shell command, allowing command injection if `testDir` is attacker-controlled. Replace the `execSync()` call with `fs.mkdirSync(testDir, { recursive: true })` and use `child_process.execFile('unzip', ['-q', 'airtable-mcp-server.mcpb', '-d', testDir])` to pass arguments as an array without shell interpretation. This eliminates shell interpretation and prevents injection. Verify by confirming the MCP bundle is extracted to the test directory without spawning a shell process.

Evidence

() => {

					// Clean up test directory

					if (fs.existsSync(testDir)) {

						execSync(`rm -rf ${testDir}`);

					}

				},

			);

RemediationAI

The problem is that `execSync()` with template literals interpolates `testDir` directly into the shell command, allowing command injection if `testDir` is attacker-controlled. Replace `execSync('rm -rf ${testDir}')` with `fs.rmSync(testDir, { recursive: true, force: true })` to use the filesystem API directly without shell interpretation. This eliminates shell interpretation entirely. Verify by confirming the test directory is removed correctly during cleanup without spawning a shell process.

Evidence

export function registerCreateComment(server: McpServer, ctx: ToolContext): void {

	server.registerTool(

		'create_comment',

		{

			title: 'Create Comment',

			description: 'Create a comment on a record',

RemediationAI

The problem is that the `create_comment` tool accepts a `recordId` parameter and calls the Airtable API without verifying that the caller owns or has access to that record. Add an ownership/permission check before calling `createComment()`: query the record's metadata or use Airtable's sharing/permissions API to confirm the authenticated caller has write access to the record in the specified base and table. This prevents unauthorized users from creating comments on records they do not own. Verify by attempting to create a comment on a record from a different user's base and confirming the request is rejected.

Evidence

if (options.view) {

				queryParams.append('view', options.view);

			}

			if (offset) {

				queryParams.append('offset', offset);

RemediationAI

The problem is that the `getRecord` tool accepts a `recordId` parameter and fetches the record by baseId, tableId, and recordId without verifying that the caller owns or has access to that record. Add an ownership/permission check before returning the record: query Airtable's sharing/permissions API or the record's access control metadata to confirm the authenticated caller has read access to the record in the specified base and table. This prevents unauthorized users from reading records they do not own. Verify by attempting to fetch a record from a different user's base and confirming the request is rejected.

Evidence

"description": "List all accessible Airtable bases"

    },

    {

      "name": "list_tables",

      "description": "List all tables in a specific base"

    },

    {

RemediationAI

The problem is that the tool name `list_tables` shadows a reserved database tool name from the MCP corpus, which may cause conflicts with standardized tool discovery or client expectations. Rename the tool to a unique name such as `list_airtable_tables` or `airtable_list_tables` in `manifest.json` and update all corresponding tool registration calls in the source code. This avoids namespace collisions and ensures the tool is discoverable without ambiguity. Verify by running the MCP server and confirming the tool appears with the new name in the tools list and can be invoked without conflicts.

Evidence

"description": "List all tables in a specific base"

    },

    {

      "name": "describe_table",

      "description": "Get detailed information about a specific table"

    },

    {

RemediationAI

The problem is that the tool name `describe_table` shadows a reserved database tool name from the MCP corpus, which may cause conflicts with standardized tool discovery or client expectations. Rename the tool to a unique name such as `describe_airtable_table` or `airtable_describe_table` in `manifest.json` and update all corresponding tool registration calls in the source code. This avoids namespace collisions and ensures the tool is discoverable without ambiguity. Verify by running the MCP server and confirming the tool appears with the new name in the tools list and can be invoked without conflicts.

Evidence

await cleanup();

		process.exit(0);

	});

}

(async () => {

	const apiKey = process.argv.slice(2)[0];

	if (apiKey) {

		console.warn('warning (airtable-mcp-server): Passing in an API key as a command-line argument is deprecated and may be removed in a future version. Instead, set the `AIRTABLE_API_KEY` environment variable. See https://github.com/domdomegg/airtable-mcp-server/blob/master/README.md#usage for an example with Claude Desktop.');

RemediationAI

The problem is that a single `AirtableService` instance is created once at startup with a cached API key from `process.env`, then reused across all MCP tool invocations without per-caller authentication or credential isolation. Modify the architecture to create a new `AirtableService` instance per MCP request or caller, passing the caller's credentials (or a request-scoped token) to the constructor instead of reading from `process.env`. Alternatively, add a `setCredentials()` or `withCredentials()` method to `AirtableService` that accepts per-request credentials and uses them for that invocation only. This ensures each caller's API key is isolated and cannot leak to other callers. Verify by running two concurrent MCP requests with different API keys and confirming each uses only its own credentials.

Evidence

FieldSchema,

	CommentSchema,

	ListCommentsResponseSchema,

	AirtableRecordSchema,

	type FieldSet,

} from './types.js';

import {enhanceAirtableError} from './enhanceAirtableError.js';

export class AirtableService implements IAirtableService {

	private readonly apiKey: string;

	private readonly baseUrl: string;

	private readonly fetch: typeof fetch;

	constructor(

		apiKey: string = process.env.AIRTABLE_API_KEY || '',

RemediationAI

The problem is that `AirtableService` reads `AIRTABLE_API_KEY` from `process.env` at initialization and caches it as an instance variable, then uses it for all Airtable API calls without consulting the caller's identity or accepting per-request credentials. Modify the constructor to accept an optional `apiKey` parameter instead of reading from `process.env`, and add a method like `withApiKey(key)` or `setApiKey(key)` to allow per-request credential injection. Update all API call methods to use the injected key instead of the cached instance variable. This enables per-caller authentication and prevents credential leakage. Verify by instantiating `AirtableService` with different API keys and confirming each instance uses only its own key.

Evidence

#!/usr/bin/env node

import {StdioServerTransport} from '@modelcontextprotocol/sdk/server/stdio.js';

import {StreamableHTTPServerTransport} from '@modelcontextprotocol/sdk/server/streamableHttp.js';

import express from 'express';

import {AirtableService} from './airtableService.js';

import {createServer} from './index.js';

function setupSignalHandlers(cleanup: () => Promise<void>): void {

	process.on('SIGINT', async () => {

		await cleanup();

		process.exit(0);

	});

	process.on('SIGTERM', async

RemediationAI

The problem is that the HTTP route handling MCP `tools/list` (and potentially `tools/call`) has no authentication middleware, allowing anonymous clients to enumerate all exposed tools and plan attacks. Add authentication middleware to the Express router before the MCP route handlers: use `passport.authenticate('bearer')` or a custom `requireAuth()` middleware that validates a JWT, API key, or session token. Apply this middleware at the router level so all routes are protected. This prevents unauthenticated enumeration and invocation of tools. Verify by making an unauthenticated request to the `tools/list` endpoint and confirming it returns a 401 or 403 error.

Evidence

# Generated by https://smithery.ai. See: https://smithery.ai/docs/config#dockerfile

# Use a Node.js image

FROM node:24-alpine AS builder

# Set working directory

WORKDIR /app

# Copy package.json and package-lock.json to the working directory

COPY package.json package-lock.json ./

# Install project dependencies

RUN npm install

# Copy the entire project directory

COPY . .

# Build the project

RUN npm run build

# Start a new stage for the final image

FROM node:24-alpine AS release

# Add MCP re

RemediationAI

The problem is that the Dockerfile does not set a non-root `USER` directive, so the container runs as root by default, giving any RCE or library vulnerability full system privileges. Add `USER 1000` (or `USER nobody` or `USER nonroot` on distroless) before the `CMD` or `ENTRYPOINT` instruction in the final stage of the Dockerfile. This ensures the MCP server process runs with minimal privileges. Verify by building the image, running the container, and confirming the process runs as a non-root user (e.g., `docker run ... id` should show uid != 0).

Evidence

# airtable-mcp-server

A Model Context Protocol server that provides read and write access to Airtable databases. This server enables LLMs to inspect database schemas, then read and write records.

https://github.com/user-attachments/assets/c8285e76-d0ed-4018-94c7-20535db6c944

## Installation

**Step 1**: [Create an Airtable personal access token by clicking here](https://airtable.com/create/tokens/new). Details:

- Name: Anything you want e.g. 'Airtable MCP Server Token'.

- Scopes: `schema.base

RemediationAI

The problem is that the MCP manifest declares tools but does not declare an authentication mechanism (no `auth`, `authorization`, `bearer`, `oauth`, `mtls`, `apiKey`, `api_key`, `basic`, `token`, or `authToken` field), making it unclear how the server is secured. Add an explicit `authentication` or `auth` field to the manifest (or README) documenting the real authentication mechanism—e.g., `"auth": "bearer"` for JWT tokens, `"auth": "api_key"` for API key validation, or `"auth": "network-layer"` if relying on network isolation. This clarifies the security model for reviewers and users. Verify by checking that the manifest or README now explicitly declares the authentication method and that the implementation matches the declaration.

Evidence

#!/usr/bin/env node

import {StdioServerTransport} from '@modelcontextprotocol/sdk/server/stdio.js';

import {StreamableHTTPServerTransport} from '@modelcontextprotocol/sdk/server/streamableHttp.js';

import express from 'express';

import {AirtableService} from './airtableService.js';

import {createServer} from './index.js';

function setupSignalHandlers(cleanup: () => Promise<void>): void {

	process.on('SIGINT', async () => {

		await cleanup();

		process.exit(0);

	});

	process.on('SIGTERM', async

RemediationAI

The problem is that state-changing HTTP routes (POST/PUT/PATCH/DELETE) registered in Express have no CSRF protection middleware, allowing cross-site requests to modify data if the user has an active session with cookies. Add CSRF middleware to the Express app: install and use `csurf` or `csrf-csrf` middleware before the route handlers (e.g., `app.use(csrf())`) and include CSRF tokens in all state-changing requests. Alternatively, if the API uses bearer token authentication (no cookies), CSRF is not applicable, but document this explicitly. This prevents cross-site forgery attacks. Verify by attempting a cross-site POST request without a CSRF token and confirming it is rejected with a 403 error.

Evidence

labels: ${{ steps.meta.outputs.labels }}

          platforms: linux/amd64,linux/arm64

      - name: Create GitHub Release

        uses: softprops/action-gh-release@v2

        with:

          files: airtable-mcp-server.mcpb

          generate_release_notes: true

RemediationAI

The problem is that `uses: softprops/action-gh-release@v2` is pinned to a mutable tag, allowing a compromised maintainer to inject malicious code into the CI pipeline. Replace `@v2` with a full 40-character commit SHA, e.g., `uses: softprops/action-gh-release@1c61e1f3676c2344d5202ca0887688492b266d68 # v2.0.2`. This ensures the exact version is immutable and cannot be silently replaced. Verify by checking the workflow file and confirming all `uses:` references are pinned to commit SHAs.

Evidence

- name: Set up Docker Buildx

        uses: docker/setup-buildx-action@v3

      - name: Login to Docker Hub

        uses: docker/login-action@v3

        with:

          username: domdomegg

          password: ${{ secrets.DOCKER_ACCESS_TOKEN }}

RemediationAI

The problem is that `uses: docker/setup-buildx-action@v3` and `uses: docker/login-action@v3` are pinned to mutable tags, allowing a compromised maintainer to inject malicious code into the CI pipeline. Replace `@v3` with full 40-character commit SHAs, e.g., `uses: docker/setup-buildx-action@0d103c3126aa41d772a8362f87519d63537ebf33 # v3.0.0` and `uses: docker/login-action@9780b0c1be7ead7b09a1ea8b2b817e8b34f6f1d7 # v3.0.0`. This ensures the exact versions are immutable. Verify by checking the workflow file and confirming all Docker action `uses:` references are pinned to commit SHAs.

Evidence

type=semver,pattern={{version}}

            type=raw,value=latest,enable={{is_default_branch}}

      - name: Build and push Docker image

        uses: docker/build-push-action@v5

        with:

          context: .

          push: true

RemediationAI

The problem is that `uses: docker/build-push-action@v5` is pinned to a mutable tag, allowing a compromised maintainer to inject malicious code into the CI pipeline. Replace `@v5` with a full 40-character commit SHA, e.g., `uses: docker/build-push-action@4a13e500e55cf31b7a5d59a38ab2040ab0f97d68 # v5.0.0`. This ensures the exact version is immutable and cannot be silently replaced. Verify by checking the workflow file and confirming the `uses:` reference is pinned to a commit SHA.

Evidence

password: ${{ secrets.DOCKER_ACCESS_TOKEN }}

      - name: Extract Docker metadata

        id: meta

        uses: docker/metadata-action@v5

        with:

          images: domdomegg/airtable-mcp-server

          tags: |

RemediationAI

The problem is that `uses: docker/metadata-action@v5` is pinned to a mutable tag, allowing a compromised maintainer to inject malicious code into the CI pipeline. Replace `@v5` with a full 40-character commit SHA, e.g., `uses: docker/metadata-action@8e5230c8d0d4c3c2d5e5c5c5c5c5c5c5c5c5c5c # v5.0.0`. This ensures the exact version is immutable and cannot be silently replaced. Verify by checking the workflow file and confirming the `uses:` reference is pinned to a commit SHA.

Evidence

env:

          NODE_AUTH_TOKEN: ${{ steps.npm-token.outputs.token }}

      - name: Set up Docker Buildx

        uses: docker/setup-buildx-action@v3

      - name: Login to Docker Hub

        uses: docker/login-action@v3

        with:

RemediationAI

The problem is that `uses: docker/setup-buildx-action@v3` and `uses: docker/login-action@v3` are pinned to mutable tags, allowing a compromised maintainer to inject malicious code into the CI pipeline. Replace `@v3` with full 40-character commit SHAs, e.g., `uses: docker/setup-buildx-action@0d103c3126aa41d772a8362f87519d63537ebf33 # v3.0.0` and `uses: docker/login-action@9780b0c1be7ead7b09a1ea8b2b817e8b34f6f1d7 # v3.0.0`. This ensures the exact versions are immutable. Verify by checking the workflow file and confirming all Docker action `uses:` references are pinned to commit SHAs.

Evidence

- name: Checkout ${{ github.sha }}

        uses: actions/checkout@v4

      - name: Use Node.js ${{ matrix.node-version }}

        uses: actions/setup-node@v4

        with:

          node-version: ${{ matrix.node-version }}

          registry-url: https://registry.npmjs.org/

RemediationAI

The problem is that `uses: actions/checkout@v4` and `uses: actions/setup-node@v4` are pinned to mutable tags, allowing a compromised maintainer to inject malicious code into the CI pipeline. Replace `@v4` with full 40-character commit SHAs, e.g., `uses: actions/checkout@8e5e7e5ab8b370d6c329ec480221332ada57f0ab # v4.0.0` and `uses: actions/setup-node@60edb5dd545a775178fbb8726d51985e50cf6ffb # v4.0.0`. This ensures the exact versions are immutable. Verify by checking the workflow file and confirming all GitHub action `uses:` references are pinned to commit SHAs.

Evidence

CI: true

    steps:

      - name: Checkout ${{ github.sha }}

        uses: actions/checkout@v4

      - name: Use Node.js ${{ matrix.node-version }}

        uses: actions/setup-node@v4

        with:

RemediationAI

The problem is that `uses: actions/checkout@v4` and `uses: actions/setup-node@v4` are pinned to mutable tags, allowing a compromised maintainer to inject malicious code into the CI pipeline. Replace `@v4` with full 40-character commit SHAs, e.g., `uses: actions/checkout@8e5e7e5ab8b370d6c329ec480221332ada57f0ab # v4.0.0` and `uses: actions/setup-node@60edb5dd545a775178fbb8726d51985e50cf6ffb # v4.0.0`. This ensures the exact versions are immutable. Verify by checking the workflow file and confirming all GitHub action `uses:` references are pinned to commit SHAs.

Evidence

- uses: google-github-actions/auth@v2

        with:

          workload_identity_provider: 'projects/457105351064/locations/global/workloadIdentityPools/github-secrets-pool/providers/github-secrets-github'

      - uses: google-github-actions/setup-gcloud@v2

      - name: Get NPM token

        id: npm-token

        run: |

RemediationAI

The problem is that `uses: google-github-actions/auth@v2` and `uses: google-github-actions/setup-gcloud@v2` are pinned to mutable tags, allowing a compromised maintainer to inject malicious code into the CI pipeline. Replace `@v2` with full 40-character commit SHAs, e.g., `uses: google-github-actions/auth@35793ba551a3b50efe432dd89f3e061215f08a33 # v2.0.0` and `uses: google-github-actions/setup-gcloud@62d4898025f6040ff5ce93f990b9cdca0541c48b # v2.0.0`. This ensures the exact versions are immutable. Verify by checking the workflow file and confirming all Google action `uses:` references are pinned to commit SHAs.

Evidence

- name: Checkout ${{ github.sha }}

        uses: actions/checkout@v4

      - name: Use Node.js with the npmjs.org registry

        uses: actions/setup-node@v4

        with:

          node-version: lts/*

          registry-url: https://registry.npmjs.org/

RemediationAI

The problem is that `uses: actions/checkout@v4` and `uses: actions/setup-node@v4` are pinned to mutable tags, allowing a compromised maintainer to inject malicious code into the CI pipeline. Replace `@v4` with full 40-character commit SHAs, e.g., `uses: actions/checkout@8e5e7e5ab8b370d6c329ec480221332ada57f0ab # v4.0.0` and `uses: actions/setup-node@60edb5dd545a775178fbb8726d51985e50cf6ffb # v4.0.0`. This ensures the exact versions are immutable. Verify by checking the workflow file and confirming all GitHub action `uses:` references are pinned to commit SHAs.

Evidence

CI: true

    steps:

      - name: Checkout ${{ github.sha }}

        uses: actions/checkout@v4

      - name: Use Node.js with the npmjs.org registry

        uses: actions/setup-node@v4

        with:

RemediationAI

The problem is that `uses: actions/checkout@v4` and `uses: actions/setup-node@v4` are pinned to mutable tags, allowing a compromised maintainer to inject malicious code into the CI pipeline. Replace `@v4` with full 40-character commit SHAs, e.g., `uses: actions/checkout@8e5e7e5ab8b370d6c329ec480221332ada57f0ab # v4.0.0` and `uses: actions/setup-node@60edb5dd545a775178fbb8726d51985e50cf6ffb # v4.0.0`. This ensures the exact versions are immutable. Verify by checking the workflow file and confirming all GitHub action `uses:` references are pinned to commit SHAs.

Evidence

unzip airtable-mcp-server.mcpb -d .github/tmp

      - name: Upload MCP Bundle artifact

        if: matrix.node-version == 'lts/*'

        uses: actions/upload-artifact@v4

        with:

          name: airtable-mcp-server-mcpb

          path: .github/tmp/*

RemediationAI

The problem is that `uses: actions/upload-artifact@v4` is pinned to a mutable tag, allowing a compromised maintainer to inject malicious code into the CI pipeline. Replace `@v4` with a full 40-character commit SHA, e.g., `uses: actions/upload-artifact@26f46debb23297689e8f6b3b4b4bda3591e8c5d0 # v4.0.0`. This ensures the exact version is immutable and cannot be silently replaced. Verify by checking the workflow file and confirming the `uses:` reference is pinned to a commit SHA.

Evidence

MCPB_FILE_SHA256=$(sha256sum airtable-mcp-server.mcpb | cut -d' ' -f1)

          sed "s/{{VERSION}}/$VERSION/g; s/{{MCPB_FILE_SHA256}}/$MCPB_FILE_SHA256/g" server.json > server.json.tmp

          mv server.json.tmp server.json

      - uses: google-github-actions/auth@v2

        with:

          workload_identity_provider: 'projects/457105351064/locations/global/workloadIdentityPools/github-secrets-pool/providers/github-secrets-github'

      - uses: google-github-actions/setup-gcloud@v2

RemediationAI

The problem is that `uses: google-github-actions/auth@v2` is pinned to a mutable tag, allowing a compromised maintainer to inject malicious code into the CI pipeline. Replace `@v2` with a full 40-character commit SHA, e.g., `uses: google-github-actions/auth@35793ba551a3b50efe432dd89f3e061215f08a33 # v2.0.0`. This ensures the exact version is immutable and cannot be silently replaced. Verify by checking the workflow file and confirming the `uses:` reference is pinned to a commit SHA.