"The sequence and intent, driven by text that a human never saw," Manifold Security wrote — and in their proof of concept that invisible sentence turned a reviewer’s own AI agent into a key that opened projects the attacker could not access.
Manifold Security's proof of concept
Offensive security firm Manifold Security disclosed a confused-deputy vulnerability this week in Microsoft's Azure DevOps MCP server. Running a local build of v2.7.0, the team showed how a contributor with write access to one project can open a pull request whose visible description hides an HTML comment carrying a payload. When a reviewer asks an AI coding agent to review that PR, the agent — acting with the reviewer’s credentials — follows the hidden instructions, triggers a pipeline in a different project, reads a confidential wiki page the contributor cannot open, and posts the contents back as a comment on the PR for the attacker to read.
Azure DevOps MCP: repo_get_pull_request_by_id and HTML comments
The delivery mechanism is simple and specific. Azure DevOps pull request descriptions accept Markdown and therefore permit HTML comments (). In the web UI those comments render as nothing, so a human scrolling the description sees an ordinary change. The MCP server’s REST API returns the description verbatim and hands that raw text to the agent. The attacker never interacts with the agent directly; they plant instructions in PR text they know the agent will read.
Spotlighting: the guardrail that wasn't applied to PRs
What makes this more than a generic prompt-injection note is that Microsoft had already adopted a defensive pattern — spotlighting — which wraps untrusted content in delimiters so a model can distinguish data from instructions. Manifold examined the server’s source and found that the wiki-page and build-log tools call a shared helper, createExternalContentResponse, introduced in PR #1062. The pull-request tool, repo_get_pull_request_by_id, does not call that helper and therefore returns the description raw. The Hacker News confirmed the same uncovered path in the current source as of July 21.
Reproduction across agents, and the preconditions that matter
Manifold reproduced the chain with both Copilot CLI and Claude Code, indicating the issue is not tied to a single agent. The exploit depends on several conditions present in many real teams: attacker-written PR text; a workflow that feeds PR content to an agent; a reviewer whose access is greater than the contributor’s; and an agent posture that is cleared to run tools without per-tool prompts. Manifold explicitly tested an auto-approve posture with no per-tool prompts — the checkpoint that would let a reviewer intercept an odd cross-project pipeline run before it fires — and found the escalation proceeds normally. The researchers noted that automated review and triage systems, triggered without a human prompting each run, would let the planted description fire on its own and extend the leak before detection.
What this means for security teams, reviewers, and procurement leaders
- Security teams: The immediate remediation steps Manifold and reporting sources recommend are concrete: give agents least-privilege tokens and scope them to only the project under review; limit which MCP domains a task may load (the local server narrows domains with a -d flag); and keep pipeline runs, wiki reads, and comment posting out of a code-review toolset that does not need them. Teams should also scan open PR descriptions for hidden HTML comments and review agent tool traces for cross-project pipeline runs, wiki reads, or comments posted during a review.
- Reviewers and developers: A human who cannot see the payload is not an effective control. If agents run tools without per-action prompts, reviewers cannot rely on manual inspection alone; the hidden payloads exploit a divergence between what the web UI shows and what the agent reads via the API.
- Procurement leaders: The root cause is in the server code paths, Manifold told The Hacker News, and the firm only tested the local, PAT-based server. By that logic the hosted remote MCP server could be exposed too, but Manifold did not test it. Buyers should therefore ask vendors about per-path guardrails and whether shared helpers like createExternalContentResponse are applied consistently across all response paths.
Microsoft's response and outstanding fixes
A Microsoft spokesperson thanked Manifold for coordinated disclosure and described the behavior as "a known class of AI risk" that informs its ongoing safeguards work. The company noted the attack requires an attacker already have write access to a project and a second user to invoke an AI tool over the content, and recommended customers limit project access and "review proposed changes before asking an AI tool to act on them." The spokesperson did not say whether Microsoft will change the code or assign a CVE. As of July 21 there was no fixed release, no CVE listed in public databases, and the latest release, v2.8.0, had shipped on June 24. No public report places the technique in use outside Manifold's testing.
Spotlighting raises the bar, but it is only as complete as the most lightly covered response path; a single missing wrapper on one function can leave a high-impact hole. With the proof of concept reproduced across agents and the server code singled out as the locus of failure, the concrete questions that remain are whether Microsoft will patch the PR response path, how quickly a fixed release appears, and whether a formal CVE will be assigned.
Read the original report at The Hacker News: https://thehackernews.com/2026/07/microsoft-azure-devops-mcp-flaw-lets.html
