Custom MCP SSRF check blocks Docker-internal hostnames — intended use in Docker setups?

[wggrre]

Feature Description

Description

Using a Custom MCP server reachable via a Docker Compose service name (e.g. mcp-server:8000) fails with:

Error: Invalid MCP Server Config: Error: isDeniedIP: Error: Access to this host is denied by policy.

Root cause (traced in source, v3.1.2):

• packages/components/nodes/tools/MCP/core.ts calls checkDenyList(this.serverParams.url) before connecting.
• checkDenyList (packages/components/src/httpSecurity.ts) resolves the hostname via DNS and checks it against a hardcoded DEFAULT_DENY_LIST, which includes 172.16.0.0/12 — Docker's default bridge network range.
• Any Docker Compose service name resolves into that range, so the MCP connection is always rejected.
• The only toggle is HTTP_SECURITY_CHECK=false, which disables the entire deny list (including 127.0.0.1, 169.254.169.254, etc.) for all HTTP-based tool calls, not just this one MCP server.

Questions:

1. Is blocking Docker-internal hostnames for Custom MCP intended behavior?
2. If yes — is there a supported way to reach a same-network MCP server without disabling HTTP_SECURITY_CHECK globally?
3. If no — could an allow-list option be added (e.g. MCP_ALLOW_LIST / an allow-list counterpart to HTTP_DENY_LIST) to permit specific internal hosts instead of an all-or-nothing switch?

Why it matters: Many self-hosted setups run Flowise and MCP servers as sibling containers specifically to avoid exposing the MCP server externally. Currently the only workaround is disabling SSRF protection entirely, or routing through a reverse proxy just to get a non-private DNS result.

Feature Category

Security

Problem Statement

No response

Proposed Solution

No response

Mockups or References

No response

Additional Context

Environment:

• Flowise 3.1.2
• Docker Compose
• self-hosted MCP server on the same Docker network.

[laraib-W]

Hi, I'd like to work on this.