Windows-MCP Unauthenticated HTTP Transport PowerShell RCE - GHSA-vrxg-gm77-7q5g
What happened
GHSA-vrxg-gm77-7q5g (CVE-2026-48989) is a high-severity unauthenticated remote code execution vulnerability in Windows-MCP, an MCP server that exposes Windows automation - including a high-privilege PowerShell tool - to AI agents. It affects versions prior to v0.7.5. In the server's SSE and Streamable HTTP transport modes, Windows-MCP binds a local port (default 8000) and processes incoming requests to manage an MCP session, but the FastMCP instance is created without any authentication provider. Any client that can open a TCP connection to the bound port can initialize a session and invoke the PowerShell tool, running arbitrary commands as the user that started the server.
The exposure is widened by a permissive Cross-Origin Resource Sharing policy: the server's middleware allows requests from any origin. With wildcard CORS in place, a victim's browser can be used to issue cross-origin requests to the locally bound server - so simply loading a malicious web page yields unauthenticated remote code execution on the host. The root cause is the omission of an authentication requirement on a network-reachable transport that exposes a shell tool. The issue was fixed in v0.7.5, which adds authentication.
Why this is an agentic-endpoint risk
Windows-MCP is exactly the kind of artifact that defines the AI agent layer: an MCP server installed bottom-up on an endpoint to give an agent real capability - here, full PowerShell on Windows. The moment it runs an SSE or HTTP transport, it becomes a network-reachable service that grants a shell, with no token in front of it. That is not a misconfiguration at the edges; it is the protocol's power turned into an unauthenticated foothold. It is a textbook example of why AI agents and MCP servers are the new shadow IT: the riskiest tool on the box is the one no security control was built to inventory.
It also rhymes with a broader pattern. The same shell-exposing design that makes a standard-input MCP server dangerous when an attacker can reach it shows up here over the network - see the sibling advisory on Anthropic MCP stdio transport RCE. The MCP layer concentrates capability; without auth and an allowlist, every transport is a door. This is precisely the surface traditional controls were never designed to see: the network sees encrypted agent traffic, EDR sees a legitimate process, and DLP sees a config file at rest.
How Anomity surfaces and governs it
Anomity treats MCP servers as one of the eight AI artifact types it inventories on every managed endpoint. For each Windows-MCP install it captures the version and the transport configuration, classifies the server by trust signals, and infers the capabilities it grants - including shell access. Finding every instance below v0.7.5, or any server bound to a non-loopback interface, becomes a single query against the fleet rather than a host-by-host hunt.
Inventory tells you where the risk is; runtime governance keeps it from firing. On agents that expose a hook - for example, the PreToolUse event in Claude Code - Anomity evaluates each MCP tool call against your policy and returns allow, deny, or log before the call runs. A PowerShell invocation arriving from an unexpected origin, or against a server flagged as unauthenticated, can be denied at that point - no sandbox, no broken workflow. Every install, configuration change, and decision is recorded in a queryable 90-day audit trail, so you can scope exposure precisely and route deny events to SIEM, Slack, email, or Jira.
What to check across your fleet
- Inventory every endpoint for Windows-MCP and record its version; upgrade anything prior to
v0.7.5tov0.7.5or later. - Identify any Windows-MCP instance running the SSE or Streamable HTTP transport, and confirm whether it binds beyond loopback (default port
8000). - Until patched, bind only to loopback, avoid network transports, and restrict the CORS policy to a trusted set of origins.
- Add a policy gate: MCP servers that expose a shell tool must require transport authentication.
- Review the audit trail for unexpected MCP sessions or PowerShell tool calls during the exposure window.
- Treat any host that ran an unauthenticated, network-bound instance as potentially compromised and rotate reachable credentials.
This advisory is part of our MCP Server Security guide, which covers MCP trust tiers and fleet-wide governance in full. To see which MCP servers are running - and which expose a shell without authentication - across your own endpoints, book a 30-minute demo.
Frequently asked questions
Am I affected by GHSA-vrxg-gm77-7q5g?
You are exposed if any endpoint runs Windows-MCP before v0.7.5 in its SSE or Streamable HTTP transport mode. In those modes the server binds a local port (default 8000) and creates its FastMCP instance with no authentication provider, so any client that can open a TCP connection to that port can start a session and invoke the high-privilege PowerShell tool. Upgrading to v0.7.5, which adds authentication, remediates the flaw. The hard part is knowing where Windows-MCP is installed and how it is configured - that requires a fleet inventory of AI tooling.
What does the vulnerability allow?
An unauthenticated attacker who can reach the bound port can initialize an MCP session and call the exposed PowerShell tool, running arbitrary commands as the user running the server. Because the server also ships a wildcard CORS policy, the attacker does not even need direct network access: a malicious web page open in the victim's browser can issue cross-origin requests to the local server, turning a drive-by visit into remote code execution on the host.
Why is wildcard CORS so dangerous here?
A permissive Access-Control-Allow-Origin policy tells the browser that any web origin may read responses from the local Windows-MCP server. Combined with an unauthenticated transport that exposes a shell tool, it removes the network-reachability requirement entirely. The victim only has to load an attacker-controlled page; their own browser then drives the loopback or LAN-bound MCP server, initializing a session and invoking PowerShell. The fix is to require transport authentication and lock the allowed origins down to a trusted set.
How does Anomity help with GHSA-vrxg-gm77-7q5g?
Anomity inventories MCP servers - including Windows-MCP - across every managed endpoint and surfaces the version and transport in use, so finding every instance below v0.7.5 or bound to a network transport becomes one query. It flags servers that expose a network transport without authentication, and on agents that expose a hook it allows, denies, or logs each MCP tool call before it runs - so a PowerShell invocation from an unexpected origin can be denied. Every install and configuration change lands in a queryable 90-day audit trail.