Executive brief
mcp-atlassian is a popular bridge that exposes Jira and Confluence data to AI agents (LLMs) through a standardized protocol. Operators set project and space filters to prevent AI agents—which may be controlled by untrusted prompts—from accessing restricted projects. Due to three distinct filter-bypass bugs, attackers can craft search queries that return sensitive data from forbidden projects and spaces despite these restrictions being in place. One bypass has been confirmed working against real Atlassian Cloud deployments.
Technical details
The vulnerability consists of three sub-bugs in filter enforcement: (A1) Jira's jira_search endpoint checks only whether the string "project = " appears in the query using a case-insensitive substring search, then appends an allowlist; an attacker can supply "project = <forbidden-key>" and bypass this check because the substring match is satisfied regardless of which project is named. (A2) Confluence's confluence_search has the same logic but with a case-sensitive substring check, allowing uppercase "SPACE = " to bypass it. (B) Agile board endpoints (get_board_issues, get_agile_boards) lack filter checks entirely. Attack vector is network (the MCP protocol accepts remote JQL/CQL queries); no authentication is required beyond the operator's PAT credentials, which the operator has already provided. An attacker controlling an LLM prompt can exfiltrate data from any project in the operator's Jira workspace. Patches are available in later versions that implement proper AST-based query parsing instead of substring checks.
Affected products
- mcp-atlassian mcp-atlassian up to 0.21.1
Timeline
- 2026-09-22: disclosed: GHSA-w66g-j6c4-hcfc advisory published
- 2026-05-18: exploited: Live bypass confirmed on production Atlassian Cloud