CVE-2026-77251

MCP Atlassian is a Model Context Protocol (MCP) server for Atlassian products (Confluence and Jira). Prior to 0.22.0, Jira search accepts a forbidden project clause because it checks only for the presence of project syntax, Confluence search uses an incomplete case-sensitive space check, and Jira board APIs omit project-filter enforcement. These paths expose issues, boards, or pages outside JIRA_PROJECTS_FILTER or CONFLUENCE_SPACES_FILTER when the operator credentials have broader access. The advisory traces the vulnerable input and processing flow through jira_search, confluence_search, get_board_issues, get_agile_boards, JIRA_PROJECTS_FILTER, and CONFLUENCE_SPACES_FILTER, which identify the affected entry points, controls, and code paths. This issue is fixed in version 0.22.0.

MCP Atlassian is a Model Context Protocol (MCP) server for Atlassian products (Confluence and Jira). Prior to 0.22.0, Jira search accepts a forbidden project clause because it checks only for the presence of project syntax, Confluence search uses an incomplete case-sensitive space check, and Jira board APIs omit project-filter enforcement. These paths expose issues, boards, or pages outside JIRA_PROJECTS_FILTER or CONFLUENCE_SPACES_FILTER when the operator credentials have broader access. The advisory traces the vulnerable input and processing flow through jira_search, confluence_search, get_board_issues, get_agile_boards, JIRA_PROJECTS_FILTER, and CONFLUENCE_SPACES_FILTER, which identify the affected entry points, controls, and code paths. This issue is fixed in version 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:

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 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 = "<forbidden-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=<forbidden-board>) 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 = <allowed> | returns allowed issue | ✓ | | 4 NEG CTRL | summary ~ "any-string" | wrapper appends AND project in (<allowed>) → 0 forbidden results | ✓ | | 5 BYPASS A1 | project = <forbidden> | 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…

MCP Atlassian is a Model Context Protocol (MCP) server for Atlassian products (Confluence and Jira). Prior to 0.22.0, Jira search accepts a forbidden project clause because it checks only for the presence of project syntax, Confluence search uses an incomplete case-sensitive space check, and Jira board APIs omit project-filter enforcement. These paths expose issues, boards, or pages outside JIRA_PROJECTS_FILTER or CONFLUENCE_SPACES_FILTER when the operator credentials have broader access. The advisory traces the vulnerable input and processing flow through jira_search, confluence_search, get_board_issues, get_agile_boards, JIRA_PROJECTS_FILTER, and CONFLUENCE_SPACES_FILTER, which identify the affected entry points, controls, and code paths. This issue is fixed in version 0.22.0.

MCP Atlassian is a Model Context Protocol (MCP) server for Atlassian products (Confluence and Jira). Prior to 0.22.0, Jira search accepts a forbidden project clause because it checks only for the presence of project syntax, Confluence search uses an incomplete case-sensitive space check, and Jira board APIs omit project-filter enforcement. These paths expose issues, boards, or pages outside JIRA_PROJECTS_FILTER or CONFLUENCE_SPACES_FILTER when the operator credentials have broader access. The advisory traces the vulnerable input and processing flow through jira_search, confluence_search, get_board_issues, get_agile_boards, JIRA_PROJECTS_FILTER, and CONFLUENCE_SPACES_FILTER, which identify the affected entry points, controls, and code paths. This issue is fixed in version 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:

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 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 = "<forbidden-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=<forbidden-board>) 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 = <allowed> | returns allowed issue | ✓ | | 4 NEG CTRL | summary ~ "any-string" | wrapper appends AND project in (<allowed>) → 0 forbidden results | ✓ | | 5 BYPASS A1 | project = <forbidden> | 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…

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:

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 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 = "<forbidden-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=<forbidden-board>) 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 = <allowed> | returns allowed issue | ✓ | | 4 NEG CTRL | summary ~ "any-string" | wrapper appends AND project in (<allowed>) → 0 forbidden results | ✓ | | 5 BYPASS A1 | project = <forbidden> | 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…