Security review of your installed MCP package (com.coplaydev.unity-mcp@f335e11a660c, v9.4.0) found these issues.
Critical: local HTTP can be exposed unauthenticated on 0.0.0.0
0.0.0.0 is treated as valid “local” in UI/validation: McpConnectionSection.cs (line 454), ServerCommandBuilder.cs (line 143).
Local mode explicitly strips API-key headers: ConfigJsonBuilder.cs (line 90).
Local server launch uses configured URL directly: ServerCommandBuilder.cs (line 60).
Risk: if bound on 0.0.0.0, anyone on LAN can hit MCP tools.
High: remote mode allows plaintext http:// / ws://
Missing scheme defaults to http://: HttpEndpointUtility.cs (line 161).
WebSocket uses ws unless base is https: WebSocketTransportClient.cs (line 733).
Risk: API key and command traffic can be intercepted.
High: API key is stored in plaintext prefs/config
Saved in EditorPrefs: McpConnectionSection.cs (line 815), key name EditorPrefKeys.cs (line 64).
Injected into client config JSON headers: ConfigJsonBuilder.cs (line 80).
Risk: local credential theft by other local processes/users.
Medium: least-privilege controls appear broken for built-in tools
Built-ins default enabled: ToolDiscoveryService.cs (line 227).
Logic can re-enable built-ins even when AutoRegister=false: ToolDiscoveryService.cs (line 232).
Risk: harder to keep dangerous tools disabled.
Medium: duplicate tool names can override existing handlers
Duplicate names overwrite prior registrations: CommandRegistry.cs (line 125), CommandRegistry.cs (line 169).
Risk: a malicious/accidental assembly can shadow a trusted tool.
Medium: supply-chain pinning is weak in manifest
Package tracks #main: manifest.json (line 4).
Lock file currently pins hash (286d0c...): packages-lock.json (line 17).
Risk: future resolves can drift if lock regenerates.
What official MCP security guidance says (and where you currently diverge):
Authorization is optional but strongly recommended for sensitive/admin operations.
Secure token storage + HTTPS requirements are explicit.
Local MCP servers are a known high-risk area (command execution/data exfiltration).
SSRF/URL validation and HTTPS-only production behavior are recommended.
I infer from your code that #1 and #2 are your biggest practical risks today.
Sources:
MCP Security Best Practices: https://modelcontextprotocol.io/docs/tutorials/security/security_best_practices
MCP Authorization (spec): https://modelcontextprotocol.io/specification/2025-03-26/basic/authorization
MCP Authorization tutorial: https://modelcontextprotocol.io/docs/tutorials/security/authorization
NVD CVE-2025-49596 (MCP Inspector): https://nvd.nist.gov/vuln/detail/CVE-2025-49596
NVD CVE-2025-6514 (mcp-remote): https://nvd.nist.gov/vuln/detail/CVE-2025-6514
Security review of your installed MCP package (com.coplaydev.unity-mcp@f335e11a660c, v9.4.0) found these issues.
Critical: local HTTP can be exposed unauthenticated on 0.0.0.0
0.0.0.0 is treated as valid “local” in UI/validation: McpConnectionSection.cs (line 454), ServerCommandBuilder.cs (line 143).
Local mode explicitly strips API-key headers: ConfigJsonBuilder.cs (line 90).
Local server launch uses configured URL directly: ServerCommandBuilder.cs (line 60).
Risk: if bound on 0.0.0.0, anyone on LAN can hit MCP tools.
High: remote mode allows plaintext http:// / ws://
Missing scheme defaults to http://: HttpEndpointUtility.cs (line 161).
WebSocket uses ws unless base is https: WebSocketTransportClient.cs (line 733).
Risk: API key and command traffic can be intercepted.
High: API key is stored in plaintext prefs/config
Saved in EditorPrefs: McpConnectionSection.cs (line 815), key name EditorPrefKeys.cs (line 64).
Injected into client config JSON headers: ConfigJsonBuilder.cs (line 80).
Risk: local credential theft by other local processes/users.
Medium: least-privilege controls appear broken for built-in tools
Built-ins default enabled: ToolDiscoveryService.cs (line 227).
Logic can re-enable built-ins even when AutoRegister=false: ToolDiscoveryService.cs (line 232).
Risk: harder to keep dangerous tools disabled.
Medium: duplicate tool names can override existing handlers
Duplicate names overwrite prior registrations: CommandRegistry.cs (line 125), CommandRegistry.cs (line 169).
Risk: a malicious/accidental assembly can shadow a trusted tool.
Medium: supply-chain pinning is weak in manifest
Package tracks #main: manifest.json (line 4).
Lock file currently pins hash (286d0c...): packages-lock.json (line 17).
Risk: future resolves can drift if lock regenerates.
What official MCP security guidance says (and where you currently diverge):
Authorization is optional but strongly recommended for sensitive/admin operations.
Secure token storage + HTTPS requirements are explicit.
Local MCP servers are a known high-risk area (command execution/data exfiltration).
SSRF/URL validation and HTTPS-only production behavior are recommended.
I infer from your code that #1 and #2 are your biggest practical risks today.
Sources:
MCP Security Best Practices: https://modelcontextprotocol.io/docs/tutorials/security/security_best_practices
MCP Authorization (spec): https://modelcontextprotocol.io/specification/2025-03-26/basic/authorization
MCP Authorization tutorial: https://modelcontextprotocol.io/docs/tutorials/security/authorization
NVD CVE-2025-49596 (MCP Inspector): https://nvd.nist.gov/vuln/detail/CVE-2025-49596
NVD CVE-2025-6514 (mcp-remote): https://nvd.nist.gov/vuln/detail/CVE-2025-6514