Azure DevOps MCP: hidden PR text hijacks AI reviewers

Confirmed reporting by Manifold Security via The Hacker News, 2026-07-21. Microsoft’s official Azure DevOps MCP server returns pull-request descriptions to an AI coding agent without wrapping them in the same spotlighting delimiters it already uses for wiki pages and build logs. A hidden HTML comment in the PR description survives the round trip and reaches the agent as an instruction. Manifold tested v2.7.0 and v2.8.0 (latest as of June 24). Both vulnerable. No CVE, no patch release.

The one sentence to take away

If you review PRs with a coding agent — Copilot CLI, Claude Code, anything wired to the Azure DevOps MCP server — a coworker with write access to one project can rewrite what your agent does next, using text that is invisible in the web UI.

What actually happens

Manifold’s chain, reproduced verbatim from their write-up:

1. The attacker opens a PR that looks normal in the browser. Inside the description, an HTML comment (<!-- ... -->) carries the payload.
2. The reviewer asks their agent to review the PR. The agent calls the MCP tool repo_get_pull_request_by_id.
3. That tool returns the description un-delimited. The HTML comment reads as agent instructions.
4. The agent’s goal is rewritten. It uses the reviewer’s credentials to reach projects the attacker cannot.

Manifold’s proof of concept did three things in sequence with the reviewer’s token: triggered a pipeline in a different project, read a confidential wiki page, and posted the exfiltrated content back to the PR as a comment. Agents tested were Copilot CLI and Claude Code. Prerequisite: attacker needs write access to at least one project the reviewer’s org runs. That is a low bar in any org with contractor accounts.

The mechanics past that stop here. Manifold’s blog has the payload structure and screenshots if you need them for detection engineering.

Why this is the frustrating one

Microsoft already knows how to fix it. A helper called createExternalContentResponse wraps returned content in delimiters that tell the agent “everything inside is data, not instructions” — the technique Simon Willison and others call spotlighting. In PR #1062, Microsoft applied that helper to wiki-page and build-log tools. It just did not get applied to repo_get_pull_request_by_id. One code path missed. Everything else follows from that.

Microsoft’s response to Manifold, per the disclosure: they thanked the researchers and called it “a known class of AI risk.” Their recommended mitigation is that customers “limit project access and review proposed changes before asking an AI tool to act on them.”

Read that mitigation carefully. The payload is an HTML comment. The reviewer does not see it. Reviewing the PR before asking the agent to act does nothing about a class of instruction the reviewer cannot read. That is the whole point of the bug.

The honest timeline

• 2026-06-24. v2.8.0 of the Azure DevOps MCP server ships. Still vulnerable. (v2.7.0 also vulnerable.)
• Pre-disclosure. Manifold reports to Microsoft under coordinated disclosure.
• 2026-07-21. Manifold publishes. Microsoft acknowledges but ships no fixed release, no CVE, no patch date.
• 2026-07-22 morning. The Hacker News covers the disclosure. Current source in the GitHub repo is still the vulnerable code.

Not a race-condition bug. Not a memory-corruption bug that takes weeks to backport. A missing function call at one call site.

Precedent, in case anyone thinks this is theoretical

Invariant Labs disclosed the same class of attack against GitHub’s MCP server in May 2025, using public issues instead of PR descriptions. Same root cause: untrusted text returned to an agent with the reviewer’s credentials. Two vendors, two years, one unlearned lesson.

What to actually do

If you have an org running the Azure DevOps MCP server against real repositories tonight:

1. Cut the tool surface on any agent that reviews PRs. The Azure DevOps MCP server ships with domain flags. Manifold’s specific recommendation is -d to load only the domains a review agent actually needs. If your review agent has no reason to run pipelines, read wikis, or post comments in other projects, do not give it those tools. This is the single highest-leverage change you can make before Microsoft ships spotlighting on this path.
2. Scope the reviewer’s PAT to a single project. A least-privilege token limits what a hijacked agent can reach. If you have contractors with write access to a shared project, this is the token to shorten first.
3. Instrument agent traces. The tells Manifold flags are cross-project pipeline runs, wiki reads outside the reviewing project, and comments the reviewer never asked for. If your agent logs tool calls, alert on those three patterns.
4. Pre-flight PR descriptions. A one-line grep on the incoming PR body — reject or strip HTML comments before handing text to the agent — closes this specific instance without waiting on Microsoft. Not a general fix. Fine as a stopgap on this specific tool.
5. Do not rely on human review of the PR to catch it. Restated because it is the mitigation Microsoft is publishing and it does not work. HTML comments do not render.

The priority call

If your org runs Azure DevOps MCP-backed code review against internet-facing PRs and you have thirty minutes, spend them on step 1. Everything else in the list is a good-hygiene follow-up. The token-scoping and the trace instrumentation are what stop the next one of these too — the next MCP server with one code path someone forgot to wrap.

The class of bug is not going away. The specific instance closes when Microsoft calls createExternalContentResponse on one more return value. Watch the repo for the follow-up commit.