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 (0)