CVE-2026-77251

### Summary `mcp-atlassian` is a popular community MCP server wrapper exposing Jira / Confluence to MCP clients. Operators commonly restrict the surface to a small allowlist of projects/spaces via the `JIRA_PROJECTS_FILTER` and `CONFLUENCE_SPACES_FILTER` environment variables, which the README documents as the principal mechanism for limiting attacker-controlled MCP clients (= prompt-injected LLM agents) to the operator's intended subset of the workspace. We identified **three distinct sub-bugs** that let attacker-controlled queries read content from **forbidden** projects/spaces (= projects NOT in the operator's filter) despite the filter being correctly set. The most severe is **empirically reproduced on production Atlassian Cloud** with real operator credentials and sentinel content in two real projects. | Sub-bug | Layer | Class | Live? | |---|---|---|---| | **A1** | Jira `jira_search` `jql` | substring-bypass | 🔴 **LIVE PROVEN 2026-05-18 on real Atlassian Cloud** | | **A2** | Confluence `confluence_search` `cql` | case-sensitive substring-bypass | code-level verified | | **B** | Jira agile `get_board_issues` / `get_agile_boards` | zero-filter (missing check) | code-level verified | ### Details **Sub-bug A1** — `src/mcp_atlassian/jira/search.py` lines 92-94 at HEAD `d8bc78698a63cb6b321c7ca796d6329d448f7f6d`: ```python if projects_filter and "project = " not in jql.lower(): jql = f"{jql} AND project in ({','.join(projects_filter)})" ``` The substring check is satisfied by *any* JQL of the form `project = <forbidden-project>` — including a project NOT in `projects_filter`. The wrapper does NOT verify that the project named in the user JQL is a member of the allowlist. The user-supplied JQL is sent verbatim to Jira's search API which returns content from the forbidden project (Jira's authorization is satisfied because the operator's PAT typically has broader access than the operator's intended allowlist — which is *why* the operator set a filter in the f