Windows-MCP HTTP modes exposed PowerShell behind a weak control plane
Before version 0.7.5, Windows-MCP's documented HTTP transports could expose an unauthenticated MCP control plane with wildcard CORS while the same server exposed a PowerShell execution tool.
Windows-MCP SSE and Streamable HTTP transport modes before 0.7.5. The default stdio transport was not affected by the advisory.
First seen
May 14, 2026
Case kind
vulnerability
AI role
AGAINST AI
Claims
4
Reconstruction
Windows-MCP is designed to give agents direct control over Windows features, including PowerShell. The May 2026 advisory found that the HTTP transport modes combined that authority with weak transport assumptions: wildcard CORS, no authentication on the MCP control plane and no Host validation against DNS rebinding.
This created a direct path from an untrusted browser origin or network client to privileged agent tools. The PowerShell tool made the impact concrete because caller-controlled commands execute under the Windows account running the server.
Version 0.7.5 changed the defaults: wildcard CORS was removed, trusted origins became explicit and host validation was added. The case is useful because the dangerous primitive was intentional; the vulnerability was the missing boundary around it.
Mechanism & boundary
01
Expose Windows-MCP over HTTP
The operator starts SSE or Streamable HTTP transport.
Boundary: local or network service / MCP transport
02
Reach control plane from an untrusted origin
Wildcard CORS and missing authentication allow requests to reach privileged tools.
Boundary: browser or client / MCP control plane
03
Invoke PowerShell tool
A caller supplies a command to the exposed tool.
Boundary: MCP request / PowerShell
04
Execute under server user
The command runs with the privileges of the Windows account hosting Windows-MCP.
Boundary: tool / operating system
Timeline
May 14, 2026
Maintainer publishes security advisory
report
GHSA-vrxg-gm77-7q5g describes the HTTP transport issue.
May 14, 2026
Version 0.7.5 ships the security patch
mitigation
The release changes CORS defaults and adds host validation.
Claims & evidence
reported findingsupported
The maintainer advisory reports that Windows-MCP HTTP transports before 0.7.5 exposed the MCP control plane without authentication and used wildcard CORS.
MCP servers should be reviewed as privileged service endpoints, not treated as harmless glue. A tool that intentionally provides shell, filesystem or UI control requires transport authentication, origin constraints, host validation and deployment guidance that matches the authority of the tool set.
Controls & mitigations
Upgrade Windows-MCP to 0.7.5 or later.
Prefer stdio where remote HTTP transport is unnecessary.
Require authentication for privileged MCP endpoints.
Use explicit trusted origins rather than wildcard CORS.
Validate Host headers and defend local services against DNS rebinding.
What remains unknown
The cited advisory does not establish exploitation in the wild.
Exposure varies with transport mode, bind address and surrounding network controls.
DiggingBeagle. “Windows-MCP HTTP modes exposed PowerShell behind a weak control plane.” First seen May 14, 2026. https://diggingbeagle.com/cases/windows-mcp-http-modes-exposed-powershell-behind-a-weak-control-plane/
DiggingBeagle is a non profit research project documenting AI security incidents, agent failures, vulnerabilities and AI-assisted operations. A case keeps its claims beside the sources that support, contest or limit them. Later updates stay visible, so a reader can see when the account changed.
We publish case reconstructions, dated reporting and analysis across records. Each has a different evidentiary role. About the project and our methodology explain how the work is reviewed.