The bug a security tool must never have

Description and use

A concurrency bug in mcp-pin caused lost approvals during simultaneous pinning, enabling silent tool changes. Fixes added atomic writes, log locking, and stricter state checks.

Problem

mcp-pin reported success for 100 concurrent pinning operations while only 12 pins were actually persisted, causing lost approvals and silent acceptance of changed tools.

Outcome

The bug caused silent loss of approvals, enabling undetected tool changes. The fix introduced per-server files, atomic writes, log locking, comprehensive error handling, and client request queuing, eliminating lost updates and ensuring reliable pinning.

Workflow

• Run 100 concurrent pinning requests to different servers
• Each process reads pins.json, adds its entry, writes back
• All processes report success
• Only 12 pins persist, log hash chain breaks

Evidence

I ran one hundred pins at the same time, for one hundred different servers. Every single one reported success.

Source

pins.json had 12 keys.

Source

The log takes a lock. Appending to the log means taking an exclusive lock, reading the tail, appending, fsyncing, and unlocking.

Source

The record comes first. The first pin used to write the pin file and then the log entry. If the append failed, you had a trusted pin with no public record of it.

Source