Security Concern: iMCP Server Exposed to Entire Local Network via Bonjour

[dwulfing]

I've discovered that iMCP exposes its server to the entire local network rather than being restricted to localhost connections only. This creates a significant security vulnerability as sensitive personal data (Messages, Contacts, Calendar, Location, etc.) could potentially be accessed by other devices on the same network.

Current Behavior

According to the documentation and my testing:

• The app and CLI communicate using Bonjour (mDNS) for automatic discovery
• Both advertise a service with type _mcp._tcp on domain local
• This makes the service discoverable and accessible from any device on the same local network
• Any computer on the same network can connect to the iMCP server running on another machine

Security Implications

This implementation poses several security risks:

1. Unauthorized Access: Any device on the local network can discover and potentially connect to the iMCP service
2. Data Exposure: Since iMCP has access to highly sensitive data (iMessages, contacts, calendar events, location), this could lead to unauthorized data access
3. Man-in-the-Middle Attacks: Bonjour's multicast nature makes it susceptible to MITM attacks
4. No Authentication: There appears to be no authentication mechanism between the CLI and the app

This is particularly concerning in:

• Shared networks (offices, co-working spaces, cafes)
• Home networks with guests
• Any environment where not all devices are trusted

Steps to Reproduce

1. Install iMCP on Computer A
2. Start the iMCP server
3. From Computer B on the same network, scan for _mcp._tcp services
4. Computer B can discover and connect to Computer A's iMCP service

Expected Behavior

The server should only be accessible via localhost (127.0.0.1) to ensure that only local processes can connect to it.

Suggested Solutions

1. Localhost-only binding: Bind the server to 127.0.0.1 instead of all network interfaces
2. Authentication: Implement token-based authentication between CLI and app
3. Encryption: Use TLS/SSL for all communications
4. Optional network exposure: If network access is needed for legitimate use cases, make it opt-in with clear security warnings
5. Access control: Implement a whitelist of allowed client connections

Environment

• macOS version: 15.5 (24F74)
• iMCP version: 1.3.0

Additional Context

While Bonjour is convenient for zero-configuration networking, Apple's own security documentation warns about its risks: "In a hostile environment other mechanisms must be used to ensure the cooperation of participants or to distinguish untrusted Multicast DNS messages" (Apple Support #101889).

Given the sensitive nature of the data iMCP accesses, I believe this should be addressed with high priority.

[mattt]

@dwulfing Thanks for reaching out.

I can confirm that the way iMCP currently advertises with Bonjour (NWListener.Service(type: "…", domain: "local.")) does indeed expose the service to other hosts on the same subnet.

In terms of security implications, for an attacker to gain access to user data through iMCP, the following would need to occur:

1. The attacker joins the same LAN as the host running iMCP
2. The attacker attempts to connect to iMCP over _mcp._tcp
3. The user clicks "Allow" in the connection request prompt

That third step prevents unauthorized access (see discussion in #46).

I do agree that scoping to the loopback device would be an improvement, so I'm looking into options for that now.

[mattt]

Hi @dwulfing. Sorry this took so long. As of 1.5.4, iMCP only accepts connections over loopback, so other devices on your network can't reach it anymore (#242). The CLI has connected over 127.0.0.1 since 1.5.1, which is what made this possible. Bonjour still advertises the service, but its port only answers on the Mac running iMCP. Thanks for reporting this, and for the detailed write-up.