On April 3, 2026, Microsoft disclosed CVE-2026-32211, a critical authentication flaw in the Azure MCP Server. CVSS score: 9.1. The vulnerability allows unauthorized access to sensitive data because the server is missing authentication mechanisms entirely.
No patch is available yet. Microsoft has published mitigation guidance but the fix is pending.
If your AI agents use Azure DevOps through MCP, this applies to you.
What the vulnerability is
The Azure MCP Server (@azure-devops/mcp on npm) exposes tools for interacting with Azure DevOps: work items, repos, pipelines, pull requests. CVE-2026-32211 is an information disclosure flaw where the server lacks proper authentication, allowing an attacker to access sensitive data without valid credentials. That could include configuration details, API keys, authentication tokens, and project data.
This is not a subtle bug. It is a missing authentication layer on a server that handles enterprise development infrastructure.
What our monitoring already showed
We have been monitoring @azure-devops/mcp since March 31 as part of our MCP ecosystem coverage. Before the CVE was disclosed, our scanner had already flagged two issues:
1. Install script with registry modification. The package has a preinstall script that runs npm config set registry https://registry.npmjs.org/. This overrides any custom registry configuration on the installing machine. While not malicious on its own, install scripts that modify npm configuration are a documented supply chain attack vector (see the axios compromise from the same week).
2. No provenance attestations. The package is published by a personal npm account (antonatms), not through GitHub Actions trusted publishing. There are no provenance attestations linking the published package to a verified build. This means there is no verifiable chain from the source repository to the published artifact.
Our verdict API returns warn for this package with a score of 75/100 and risk level MODERATE.
Why this matters for the MCP ecosystem
The MCP specification currently makes authentication optional. The official docs note that "the MCP SDK does not include built-in authentication mechanisms." That design choice puts the responsibility on each MCP server implementation. When an implementation skips authentication, as the Azure MCP Server did, the result is a CVSS 9.1 vulnerability.
This is not unique to Microsoft. The OWASP MCP Top 10 draft lists "Insufficient Authentication and Authorization" (MCP07) as a top risk for exactly this reason. Many MCP servers are published without authentication, running with whatever permissions the host environment grants.
For teams deploying MCP servers in production, the question is not just "does this package have malware in it" but "does this server implement the security controls it should?"
What you should do
If you use @azure-devops/mcp:- Restrict network access to the MCP server endpoint using firewall rules
- Place a reverse proxy with authentication in front of the server
- Review access logs for unauthorised requests
- Monitor Microsoft's security update guide for the official patch
- Consider whether the server needs to be running until the patch is available
For any MCP server:
- Check whether the server implements authentication
- Review what tools the server exposes and whether the permission surface matches what you actually need
- Monitor your MCP dependencies for changes. Version bumps, new dependencies, and configuration changes all affect your security posture.
How we track this
AgentScore monitors 60+ MCP packages continuously and provides:
-
Verdict API:
GET /api/verdict?npm=@azure-devops/mcpreturns allow/warn/block with reasons, publisher posture, and tool surface -
Exposure API:
GET /api/exposure?npm=@azure-devops/mcpshows which other monitored packages depend on the affected package - Continuous monitoring: changes to package versions, dependencies, and risk levels are detected automatically
We flagged this package before the CVE was disclosed because the security signals were already visible: install script modifying registry config, no provenance, personal publisher account. These are the kinds of pre-incident indicators that continuous monitoring catches.
Scan any MCP package for free at agentscores.xyz. For continuous monitoring or a detailed security review, get in touch.
AgentScore is the trust and policy layer for the MCP ecosystem. We scan, monitor, and assess MCP packages so registries, clients, and teams can make informed decisions.
Top comments (2)
This is a good breakdown. The CVSS 9.1 score makes sense given that missing auth on an MCP server is basically an open door to your entire DevOps pipeline.
What concerns me most is the discovery side of this. Right now there's no standardized way for agents to verify that an MCP server they're connecting to has even basic auth in place before exchanging data. The spec itself doesn't mandate authentication at the transport layer, so every implementation rolls its own or skips it entirely, like this Azure case.
I've been thinking about how discovery registries could help here. If servers had to declare their auth mechanisms as part of registration metadata, agents could at least filter out unverified endpoints before connecting. Not a complete fix obviously, but it would catch the 'no auth at all' class of bugs at discovery time rather than after data is already exposed.
The discovery registry point is spot on. The official MCP Registry deliberately leaves trust and security assessment to downstream services, so right now there is nothing between "server exists on the registry" and "agent connects to it."
We have been working on exactly this kind of pre-connect check. Our registry overlay takes a server or package name and returns a trust assessment before any connection happens.
The spec not mandating transport-layer auth is the root issue. Until that changes, making auth declaration part of registration metadata is probably the best defence. The OWASP MCP Top 10 lists insufficient auth as MCP07, and this Azure CVE is exactly the outcome they predicted.