GHSA-w66g-j6c4-hcfc MCP Atlassian: JIRA_PROJECTS_FILTER / CONFLUENCE_SPACES_FILTER allow forbidden-project content exfiltration (one LIVE-proven on Atlassian Cloud)

• PyPI mcp-atlassian: < 0.22.0 → fixed in 0.22.0

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 = ` — 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 first place). Sub-bug A2 — `src/mcp_atlassian/confluence/search.py` line 60: same pattern as A1, PLUS the substring check `"space = " not in cql` is case-sensitive (no `.lower()`). User CQL `SPACE = ""` (uppercase) bypasses the substring match. Sub-bug B — `get_board_issues` and `get_agile_boards` paths have no `projects_filter` enforcement at all — no substring check, no AST walk, the allowlist is silently ignored. An MCP client invoking `get_agile_boards` enumerates boards across the entire workspace (including forbidden projects), and `get_board_issues(boardId=)` returns all issues with no filter check. PoC End-to-end Phase C against real Atlassian Cloud + real `mcp-atlassian` Python binary v0.21.1 (latest on PyPI) with operator-provided test workspace and two real Jira projects (one allowed, one forbidden via `JIRA_PROJECTS_FILTER`): | Step | JQL submitted | Result | Verdict | |---|---|---|---| | 1 initialize | – | MCP 2024-11-05 OK | ✓ | | 2 tools/list | – | 33+ tools incl. `jira_search` | ✓ | | 3 CONTROL | `project = ` | returns allowed issue | ✓ | | 4 NEG CTRL | `summary ~ "any-string"` | wrapper appends `AND project in ()` → 0 forbidden results | ✓ | | 5 BYPASS A1 | `project = ` | returns forbidden issue with sentinel content | 🔴 BYPASS | Full RPC log and a reproducible test script are available in a disclosure bundle I have prepared. I can share the zip via a private channel (email / your preferred private fork / encrypted upload) — please reply with your preference. The bundle includes: • 00-FINDING-REPORT.md (primary report) • ATTACK-MATRIX.md • Verbatim source files at HEAD with sha256 chain of custody (`source-jira-search.py`, `source-confluence-search.py`) • Phase C live test script + JSON-RPC witness log • Bundle zip sha256: `034cbf0bcb66c325be9373ff2dc186b8b0e1747c5165d6fba3bca83054949dd3` Repro recipe (no bundle needed) : ```bash pip install mcp-atlassian export JIRA_URL=https://.atlassian.net export JIRA_USERNAME= export JIRA_API_TOKEN= export JIRA_PROJECTS_FILTER= Then drive the MCP via stdio JSON-RPC with tools/call jira_search jql="project = " Expect: forbidden project content returned despite the filter. ``` Impact Severity is higher in deployments where the operator's PAT covers a broader set of projects than `JIRA_PROJECTS_FILTER` (= the common configuration, which is the reason operators set the filter). Affected: every operator who relies on `JIRA_PROJECTS_FILTER` / `CONFLUENCE_SPACES_FILTER` to confine an attacker-controlled MCP client (= prompt-injected LLM agent) to a subset of their workspace. Suggested fix 1. Replace substring checks with AST-based JQL/CQL parsers that walk the WHERE clause looking for `project`/`space` constraints. Reject queries whose `project`/`space` constraint references a key not in the allowlist. 2. Add `projects_filter` check inside `get_board_issues` (resolve board → project, reject if not in filter) and `get_agile_boards` (filter returned list). 3. Make the Confluence substring check case-insensitive (`cql.lower()`) for defense-in-depth, even after the AST fix lands. 4. Default-deny for ambiguous queries: if the AST parser can't fully classify a clause, refuse instead of pass-through. 5. Add unit tests that assert attacker JQL `project = ` returns zero results when the filter is set. Disclosure ISO/IEC 29147. Default 90-day embargo from the date you acknowledge receipt. Happy to coordinate the CVE via the GitHub CNA pipeline. Credit under: Mordehai Attia, Founder, Corsen AI (https://corsen.ai , GitHub @CorsenAI). Thank you for maintaining mcp-atlassian — the project is widely used and your security policy was clear, which made this disclosure straightforward to file. Looking forward to coordinating the fix.