Your RSA-2048 keys break in 2030. Find every one of them before attackers do.
🐍 PyPI
Not in CISA KEV

CVE-2026-77251 — mcp-atlassian

Fix: sooperset/mcp-atlassian@b041733

CVE-2026-77251 is a CWE-1276 vulnerability in mcp-atlassian. A fix is available for mcp-atlassian — see the affected versions and patch details below.

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

Also known asGHSA-w66g-j6c4-hcfcPYSEC-2026-4102
Published
Updated
Affected
1 pkg
Patched
1 / 1
Exploits
None indexed
Exploitation data as of Oct 22, 2026 · OSV.dev, NVD, FIRST.org (EPSS)

Exploitation Status

Proof-of-concept exploit code exists

  • CISA’s SSVC triage found public proof-of-concept exploit code for this CVE, though no confirmed active exploitation.
  • CISA assesses this as automatable — exploitation doesn’t require manual, per-target effort, which raises the odds of mass scanning and opportunistic attacks.
  • A successful exploit gives an attacker total control of the affected component, not partial access.

Exploitation and automatability from CISA’s SSVC triage for CVE-2026-77251.

EPSS Exploitation Probability

via FIRST.org ↗
0.2%probability of exploitation in next 30 days
Lower Risk0.00%
Lower risk than most CVEs15th percentile — riskier than 15% of all scored CVEsHighest risk
0.00%0.25%0.49%0.74%0.2%0.2%Oct 26Oct 26

Probability of exploitation in the next 30 days, from FIRST.org EPSS.

Real-World Exposure

1 pkg affected
🐍mcp-atlassian

Real-time download stats are indexed for npm and PyPI packages. This vulnerability affects PyPI packages — download data is not available via public APIs for these ecosystems.

Description

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-bugLayerClassLive?
A1Jira jira_search jqlsubstring-bypass🔴 LIVE PROVEN 2026-05-18 on real Atlassian Cloud
A2Confluence confluence_search cqlcase-sensitive substring-bypasscode-level verified
BJira agile get_board_issues / get_agile_boardszero-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):

StepJQL submittedResultVerdict
1 initialize–MCP 2024-11-05 OK✓
2 tools/list–33+ tools incl. jira_search✓
3 CONTROLproject = <allowed>returns allowed issue✓
4 NEG CTRLsummary ~ "any-string"wrapper appends AND project in (<allowed>) → 0 forbidden results✓
5 BYPASS A1project = <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 needed) :

pip install mcp-atlassian
export JIRA_URL=https://<your-test-workspace>.atlassian.net
export JIRA_USERNAME=<your-test-email>
export JIRA_API_TOKEN=<your-pat>
export JIRA_PROJECTS_FILTER=<your-allowed-project-key>
# Then drive the MCP via stdio JSON-RPC with tools/call jira_search jql="project = <forbidden-project-key>"
# 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 = <not-in-filter> 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.

Affected Packages

1 total 1 fixed
EcosystemPackageVulnerable rangeFix
🐍PyPImcp-atlassianall versions0.22.0pip install --upgrade 'mcp-atlassian==0.22.0'

Affected Products

1 product · 1 configurations
Application
mcp atlassianmcp-atlassian
< 0.22.0
range

Detection & mitigation playbook

Open-source dependency
  1. Detect

    Scan your dependency tree (package-lock.json, pnpm-lock.yaml, requirements.txt, go.sum, etc.) for mcp-atlassian, including transitive dependencies — a direct dependency you never call can still pull in a vulnerable version.

  2. Fix

    Update mcp-atlassian to 0.22.0 or later, then make sure no transitive (indirect) dependency still pins the vulnerable range — O3 confirms CVE-2026-77251 is resolved across your whole dependency graph.

  3. Workarounds

    If you can't upgrade right away: gate or disable the affected feature, validate untrusted input at the boundary, and avoid passing attacker-controlled data into the vulnerable path. O3's runtime protection blocks exploitation in production as an interim safeguard until the upgrade lands.

Frequently Asked Questions

### 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
O3 Security · Impact-Aware SCA

Is CVE-2026-77251 in your dependencies?

Find it across PyPI, including transitive dependencies.

CVE-2026-77251: mcp-atlassian — Fixed in 0.22.0