MCP server Web Bluetooth security — GATT characteristic injection, BLE device fingerprinting, pairing persistence

GATT characteristic write injection from tool output

The Web Bluetooth API exposes the GATT (Generic Attribute Profile) layer of paired BLE devices. GATT characteristics are typed data endpoints that control device behavior — a smart lock's lock/unlock state, a smart bulb's color and brightness, a medical pump's flow rate, an industrial relay's on/off state. An MCP tool that provides GATT write values from its response controls physical device behavior if the PWA passes tool output directly to characteristic.writeValue().

// DANGEROUS: MCP tool controls what gets written to a Bluetooth GATT characteristic
async function applyToolConfig(device, toolResult) {
  const server = await device.gatt.connect();
  const service = await server.getPrimaryService(toolResult.serviceUUID);  // attacker-controlled
  const characteristic = await service.getCharacteristic(toolResult.charUUID);  // attacker-controlled

  // Write tool result data to the device:
  const data = new Uint8Array(toolResult.payload);  // attacker-controlled bytes
  await characteristic.writeValue(data);
  // Effect: attacker writes arbitrary bytes to arbitrary GATT characteristics
  // on a physical device paired to the user's browser.
  // Smart lock: [0x01] unlocks. Medical device: attacker-controlled flow rate.
}

// CORRECT: UUIDs and payloads hardcoded; tool output only selects from an allowlist
const ALLOWED_CHARACTERISTICS = new Map([
  ['brightness', { service: '0000180a-...', char: '00002a00-...', maxVal: 255 }],
  ['color',      { service: '0000180a-...', char: '00002a01-...', maxVal: [255,255,255] }],
]);

async function applyToolConfig(device, toolResult) {
  const spec = ALLOWED_CHARACTERISTICS.get(toolResult.property);
  if (!spec) throw new Error(`Unknown property: ${toolResult.property}`);

  // Validate value against known range
  const value = parseInt(toolResult.value);
  if (isNaN(value) || value < 0 || value > spec.maxVal) {
    throw new Error(`Value out of range for ${toolResult.property}`);
  }

  const server = await device.gatt.connect();
  const service = await server.getPrimaryService(spec.service);  // hardcoded
  const characteristic = await service.getCharacteristic(spec.char);  // hardcoded
  await characteristic.writeValue(new Uint8Array([value]));
}

BLE device scanning as proximity-based fingerprinting

The Web Bluetooth device picker shows the user a list of nearby BLE devices. Before the picker opens, the API internally scans for devices — and the scan results (device names, manufacturer data, service UUIDs, signal strength) are highly environment-specific. Two requests to navigator.bluetooth.requestDevice() from the same physical location return the same device list. This creates a stable location fingerprint based on the user's BLE environment — their home devices, office equipment, medical devices, and fitness trackers within ~10 meters.

// The Web Bluetooth API restricts direct scan result access for privacy.
// BUT: the device picker selection itself reveals which devices are nearby.

// ATTACK: force multiple requestDevice() prompts with different filters
// to enumerate nearby devices by type:

// First prompt: ask for heart rate monitors
// User cancels or accepts — either way, the picker was shown
// Observation: whether the user has a heart rate monitor visible

// This is mitigated by the API requiring user interaction and consent,
// but an MCP tool that repeatedly requests Bluetooth access for "functionality"
// forces repeated exposure of the scan list.

// STRONGER ATTACK: navigator.bluetooth.getDevices()
// Returns previously paired devices — no picker, no user gesture required
// (permissions already granted from prior pairing)

const pairedDevices = await navigator.bluetooth.getDevices();
// Returns: [BluetoothDevice { name: "AirPods Pro", id: "..." }, ...]
// Device names and model identifiers are stable hardware fingerprints

const fingerprint = pairedDevices.map(d => ({
  name: d.name,        // "John's AirPods Pro", "Garmin Forerunner 945"
  id: d.id,            // Stable browser-local UUID (reproducible)
}));

// Result: the user's full paired device list — wearables, medical devices,
// peripherals, home automation — without any user gesture.

// DEFENSE: never call navigator.bluetooth.getDevices() in MCP tool handlers
// Only call requestDevice() when user explicitly initiates Bluetooth pairing
// Permissions-Policy: bluetooth=() blocks Bluetooth API in iframes

Pairing persistence across sessions without re-prompting

Once a user grants Web Bluetooth access to a device, the browser remembers the pairing. Subsequent calls to navigator.bluetooth.getDevices() or device.gatt.connect() on a previously paired device succeed without re-prompting — even after browser restart, even after navigating away and back. An MCP tool installed after initial pairing inherits all paired device access without the user ever seeing a Bluetooth permission prompt for the new tool's actions.

// Pairing persistence: connect to a previously paired device without prompt
const devices = await navigator.bluetooth.getDevices();
const smartLock = devices.find(d => d.name === 'FrontDoorLock');

if (smartLock) {
  // No permission prompt — pairing from previous session is still valid
  const server = await smartLock.gatt.connect();
  // ... GATT access fully available to MCP tool code

  // An MCP tool that gained execution can use ALL paired devices
  // not just the one the user intended to use with this tool
}

// DEFENSE: revoke device permissions after each tool session
device.forget();  // Removes the persistent pairing — re-prompt required next time

// Or: use watchAdvertisements() with AbortController to limit scan duration
const abortController = new AbortController();
device.watchAdvertisements({ signal: abortController.signal });
// Abort scanning after tool session ends:
mcpToolSession.on('end', () => abortController.abort());

Web Bluetooth security — risk comparison

SkillAudit findings for Web Bluetooth usage