Egress bypass attempt

What mcp-scan saw

The network-egress scanner lowercased the entire serialized server config and required three substrings to be present together: child_process, either exec or spawn, and either curl or wget. All three are matched anywhere in the JSON, with no proximity requirement.

Why it fires

Network policy in a Node process is usually enforced in-process, by patching fetch or by an agent that only sees the runtime's own sockets. Shelling out to curl leaves that boundary entirely: the request is made by a separate process the policy never sees. That is why this is graded above a plain unknown endpoint.

When this is a false positive

• The three substrings need no proximity. A server description that documents a child_process helper in one sentence and mentions curl in an unrelated example satisfies all three.
• An HTTP-client MCP server whose whole purpose is wrapping curl matches by design, since its description names both the mechanism and the tool.
• 'exec' is matched as a bare substring of the whole JSON, so it also matches inside words like execute, execution, and executable, which appear in most tool descriptions.

How to fix it

1. Read the raw config and find where each of the three substrings actually appears. They can be in three unrelated places.
2. If a tool really does shell out to curl, replace it with the runtime's own HTTP client so your egress policy applies to it.
3. If curl is required, pin the destination host inside the server code rather than accepting it as a tool argument.
4. If the substrings are incidental documentation, reword the description to drop the mechanism names.
5. Add the intended hosts to allowedDomains in .mcp-scan.json. That does not clear this specific rule, which is substring-based, but it clears the endpoint findings that usually accompany it.