MCP server integer overflow security — arithmetic boundary vulnerabilities in AI tool handlers

Why LLM-supplied numbers are different

In a conventional web application, a numeric field is typically constrained by a form input with type="number", a URL parameter that the user types, or an API schema that the client framework enforces. The practical range of values an attacker can supply is bounded by ergonomics — very large or very small numbers stand out, and most input-validation libraries catch them early.

In an MCP server, the AI model supplies numeric arguments as part of tool invocation. The model may infer numeric values from context, interpolate them from conversation history, or follow prompt-injected instructions that specify exact numeric values. A prompt-injection payload embedded in a web page the model just read can instruct: call the transfer tool with amount=9999999999. The model is more likely than a human to supply boundary-triggering values because it doesn't share the human intuition that "that number seems unreasonably large."

Vulnerability pattern 1: credit/debit counter wrapping

The most dangerous integer overflow pattern in MCP servers is arithmetic on counters that represent value: credits, balance, quota, or score. If the counter is stored as a 32-bit signed integer (common in databases with INT columns) and a tool handler performs addition without an overflow check, a sufficiently large argument can wrap the counter to a negative value or to a large positive value.

A tool that deducts credits on use:

// Vulnerable
async function deductCredits(userId, amount) {
  await db.query(
    'UPDATE users SET credits = credits - ? WHERE id = ?',
    [args.amount, userId]
  );
}

If args.amount is -1000 (negative), the subtraction becomes an addition — the user gains credits. If args.amount is 2147483648 (INT32_MAX + 1), the column wraps in a database that uses signed 32-bit integers. Neither of these inputs would normally appear in a human-facing UI, but an AI model can supply them without friction.

Vulnerability pattern 2: allocation size from tool argument

Tools that allocate memory or create data structures based on a user-supplied count are susceptible to allocation exhaustion or overflow:

// Vulnerable
async function createBatch(count) {
  const items = new Array(args.count).fill(null);  // OOM if count is 1e9
  return items.map(() => generateItem());
}

An AI model that passes count=1000000000 triggers a 1-billion-element array allocation that will exhaust the Node.js process heap. This is a denial-of-service vector that's trivial to trigger accidentally (the model doesn't know the server's resource constraints) or intentionally via prompt injection.

Vulnerability pattern 3: pagination offset overflow

Pagination tools that accept offset and limit arguments are particularly prone to arithmetic boundary issues when the arguments interact with database queries:

// Vulnerable — no range check on offset + limit arithmetic
async function listItems(offset, limit) {
  const end = offset + limit;  // could overflow or produce unexpected SQL
  return db.query('SELECT * FROM items LIMIT ? OFFSET ?', [limit, offset]);
}

If offset is Number.MAX_SAFE_INTEGER and limit is any positive number, the addition produces Infinity in JavaScript, which the database driver may handle unpredictably. With a SQLite backend, very large OFFSET values trigger full-table scans that hold the database lock for seconds — a practical denial-of-service for a tool that serves multiple concurrent requests.

Safe pattern: explicit range validation before arithmetic

The safe approach for any numeric tool argument is to validate range before performing any arithmetic on it:

function validatePositiveInt(value, max = 1000) {
  const n = Number(value);
  if (!Number.isInteger(n)) throw new Error('Must be an integer');
  if (n < 0) throw new Error('Must be non-negative');
  if (n > max) throw new Error(`Must be at most ${max}`);
  return n;
}

async function deductCredits(userId, rawAmount) {
  const amount = validatePositiveInt(rawAmount, 10000);
  // safe: amount is a checked integer in [0, 10000]
  const result = await db.query(
    'UPDATE users SET credits = GREATEST(0, credits - ?) WHERE id = ?',
    [amount, userId]
  );
}

Note the GREATEST(0, credits - ?) guard at the SQL level as a second layer — preventing negative balances even if the application-layer check is bypassed.

Safe pattern: schema-level constraint declaration

MCP tool schemas accept numeric constraints that the SDK enforces before your handler is called:

const transferSchema = {
  type: "object",
  properties: {
    amount: {
      type: "integer",
      minimum: 1,
      maximum: 10000,
      description: "Transfer amount in cents (1–10000)"
    },
    toUserId: { type: "string" }
  },
  required: ["amount", "toUserId"]
};

Schema constraints declared here are enforced by the MCP SDK before your handler receives the arguments — the handler never sees values outside the declared range. This is the first line of defence; the application-layer check is the second.

SkillAudit detection

The Security axis of a SkillAudit report flags integer boundary risks via two detection methods: static analysis that looks for numeric arguments passed directly to arithmetic operators or allocation functions without an intervening range check, and LLM-probe layer testing that supplies boundary values (0, -1, MAX_INT32, 1e15, NaN, Infinity) to numeric tool parameters and observes whether the server handles them safely or errors unexpectedly. Findings are classified MEDIUM for allocation exhaustion vectors and HIGH for counter-wrapping that affects financial or quota values.

Run a free audit at skillaudit.dev to check your server's numeric argument handling, or see our related guides: business logic security for the broader class of arithmetic and flow abuse, and input validation security for the complete validation pattern library.