Reverse shell risk

What mcp-scan saw

The AST scanner matched the joined command against two shapes: nc or netcat followed by an -e, -c, or --exec flag, or nc/netcat followed by a dotted-quad IP and then a port number. A bare nc argument with no connection intent does not fire, which was a deliberate narrowing in the source.

Why it fires

netcat with an exec flag hands a shell to whoever is listening on the other end, and netcat with an IP and port is the client half of that. Either shape in an MCP server config means the server can open an outbound connection that a firewall reads as normal egress, then serve a shell over it. The finding carries no fixRecommendation in the source because there is no configuration that makes this acceptable.

When this is a false positive

• \bnc\b matches --nc as a flag name because the hyphen is a word boundary. A server with a --nc flag and any later -c or -e flag satisfies the first shape.
• The second shape needs a real dotted quad, so a version string does not trigger it, but an argument holding a documented example address plus a port does.
• A netcat-based health check that connects to a known internal service on a fixed IP and port matches the second shape exactly, even though nothing is exec'd.

How to fix it

1. Read the joined command in the finding text and locate the nc or netcat token with its flags.
2. If you did not put it there, stop the server, remove the entry, and treat every credential in its env block as compromised.
3. If it is a health check, replace it with a plain TCP connect from the server's own language runtime rather than shelling out to netcat.
4. If -c or -e belongs to a different program in the same command line, reorder or rename the flags so they do not follow an nc token.
5. Re-scan and confirm the finding is gone before restarting the server.