Attack ChainAIDerived
Hypothetical attack flow derived from CVE metadata – not a confirmed exploit chain
-
AccessAuthenticate as permitted MCP caller
-
DeliveryCraft search with forbidden project/space clause
-
ExploitServer skips allowlist enforcement
-
ExecutionQuery runs under broad operator credentials
-
ImpactExfiltrate issues/boards/pages outside filter
Vulnerability Assessment
| Weakness |
CWE
|
| Exploitation Conditions | Requires an authenticated/permitted caller of the MCP-Atlassian server (PR:L) in a deployment where the server's operator credentials (the shared Jira/Confluence tokens) grant access broader than the configured JIRA_PROJECTS_FILTER or CONFLUENCE_SPACES_FILTER. The vulnerability is only meaningful when those allowlist filters are actually configured to restrict access AND the underlying operator account can see more than the filter permits - i.e., shared-credential, multi-tenant, or delegated MCP deployments. Exploitation needs no user interaction and no special network conditions beyond reaching the MCP endpoint; the limiting factors are the requirement to be an accepted MCP client and the existence of a configured-but-narrower filter over broadly-scoped operator credentials. Affected versions are prior to 0.22.0. |
| Impact | This is a moderate-priority authorization/filter-bypass information-disclosure flaw, not a top-tier emergency. The CVSS 4.0 vector (8.3, AV:N/AC:L/AT:N/PR:L/UI:N/VC:H/VI:N/VA:N/SC:H) tells a consistent story: network-reachable, low complexity, but requires low privileges (PR:L - an already-permitted MCP caller) and yields confidentiality impact only (VI:N/VA:N - no integrity or availability loss). The high base score is driven by VC:H combined with the subsequent-system scope change (SC:H), reflecting that the MCP server acts as a confused deputy using operator credentials that are broader than the caller should reach. No EPSS score, no CISA KEV listing, and no public exploit code are present in the input - so there is no public exploit identified at time of analysis and no evidence of active exploitation. The realistic risk is bounded by deployment model: it only matters in shared-credential MCP deployments where operator tokens have access beyond the configured JIRA_PROJECTS_FILTER/CONFLUENCE_SPACES_FILTER. Note a metadata tension worth verifying: the assigned CWE-1276 ('Hardware Child Block Incorrectly Connected to Parent System') does not fit a software JQL/CQL filter-bypass - the behavior is squarely incorrect-authorization (CWE-863/CWE-284). This does not change the risk but flags an inaccurate classifier. |
| Exploit ScenarioDerived | In a multi-user or shared-credential MCP-Atlassian deployment, an authenticated but restricted caller issues a Jira search with a crafted project clause (or a Confluence search abusing the case-sensitive space check, or calls get_board_issues/get_agile_boards), and because the server only checks for the presence of project syntax rather than enforcing the allowlist, it returns issues, boards, and pages from projects/spaces outside JIRA_PROJECTS_FILTER/CONFLUENCE_SPACES_FILTER. The attacker thereby reads confidential Atlassian content the operator credentials can see but the caller was never authorized for. No public proof-of-concept is referenced, though the fixing PR #1448 and commit b0417334 detail the exact vulnerable code paths. |
Get an e-mail when this CVE is exploited, patched or re-scored. Free account.
Alert meAnalysisAIv1 – Sep 22, 2026
Information disclosure in MCP Atlassian (sooperset/mcp-atlassian) before 0.22.0 allows an authenticated caller of the MCP server to read Jira issues, agile boards, and Confluence pages that the operator intended to exclude via JIRA_PROJECTS_FILTER or CONFLUENCE_SPACES_FILTER, because the Jira search path only checks whether a project clause is present rather than whether it is permitted, the Confluence search path applies an incomplete case-sensitive space check (and lets a caller-supplied spaces_filter replace rather than narrow the configured allowlist), and the Jira board APIs (get_board_issues, get_agile_boards) omit project-filter enforcement entirely. The flaw requires low privileges (an accepted MCP client) and no user interaction, but it only yields data beyond the intended scope when the server's shared operator credentials hold broader Atlassian access than the configured filter - the typical shared-credential, delegated, or multi-tenant MCP deployment. There is no confirmed active exploitation and no public exploit identified at time of analysis; the issue is fixed in 0.22.0, and an independent assessment rates it a moderate-priority filter-bypass/authorization control failure rather than a top-tier emergency.
RemediationAI
Upgrade to MCP Atlassian 0.22.0 or later - this is the vendor-confirmed fix - by pinning the release at https://github.com/sooperset/mcp-atlassian/releases/tag/v0.22.0; the underlying change is commit b041733473f95119dd539542a43c280737a8e460 (PR https://github.com/sooperset/mcp-atlassian/pull/1448), and full details are in advisory GHSA-w66g-j6c4-hcfc. If upgrading immediately is not possible, the most reliable compensating control is to stop relying on the application-level allowlists and instead issue the MCP server an Atlassian token whose native project/space permissions exactly match the intended scope, since that boundary is enforced by Atlassian rather than by the vulnerable Python checks - the trade-off is that this removes the server's ability to traverse anything outside the token scope, including legitimate cross-project automation. Additional targeted mitigations: do not expose the affected Jira board tools (get_board_issues, get_agile_boards) to untrusted callers, and treat CONFLUENCE_SPACES_FILTER as non-authoritative on vulnerable versions because a caller-supplied spaces_filter can replace it; restrict and authenticate who can reach the MCP endpoint (the flaw requires an accepted MCP client, so tightening client registration removes the exposure path entirely); and monitor Jira/Confluence audit logs for search and board calls referencing projects or spaces outside the configured allowlists. Note that the same upstream PR also hardens path handling and outbound request behavior unrelated to this CVE; those fixes arrive with the same 0.22.0 upgrade, and pinning attachment downloads or disabling them is advisable if you upgrade only partially or run a patched-backport build.
Affected VersionsENISA
Affected Packages
Source: OSV (Open Source Vulnerabilities)
Affects your stack
Affects 1 package in pypi
Checking this CVE against your own stacks and servers is part of the Basic plan and up.
Technical ContextAI · show details
MCP Atlassian is a Model Context Protocol (MCP) server that brokers requests from MCP clients (LLM agents and tooling) into Atlassian Confluence and Jira REST APIs using operator-configured OAuth or token credentials. Operators are meant to constrain that broker with allowlists - JIRA_PROJECTS_FILTER and CONFLUENCE_SPACES_FILTER - so that a caller cannot reach projects or spaces beyond an approved set even though the underlying Atlassian account can. CVE-2026-77251 is mapped to CWE-1276, an incomplete/improper check for a condition the code did not anticipate; concretely, the enforcement logic trusted the shape of caller input instead of validating it against policy. Three distinct entry points are affected: jira_search, which added the project constraint only if a project clause was absent, so a caller-supplied project (or equivalent JQL) slipped past; confluence_search, which used a case-sensitive check that a differently cased or structured CQL space clause could evade, and additionally let the caller-supplied spaces_filter replace config.spaces_filter instead of being ANDed with it; and get_board_issues / get_agile_boards, which never applied the project filter at all. The upstream fix in PR #1448 introduces an _and_spaces_filter helper that unconditionally ANDs the configured allowlist into CQL, correctly quotes space identifiers, and preserves a trailing ORDER BY clause, so even a caller CQL containing 'space = X' cannot escape the operator's list; it also states the caller argument may only narrow within the configured allowlist. The same pull request bundles unrelated hardening (workspace confinement for Confluence attachment uploads, SSRF redirect validation and DNS pinning, and refusal to download attachments into the working-directory root) that belongs to other advisories, not to this CVE. Per the assessed vector (CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:C/C:H/I:N/A:N), the impact is confidentiality-only with a scope change, and integrity/availability are unaffected.
Know when Mcp Atlassian gets its next vulnerability
- Watch products and get an email when something new is published
- Check this CVE against your own stack and servers
- Exploit and PoC references, threat intelligence from 22 sources
No credit card · 7-day full trial
Severity by source
CVSS:4.0/AV:N/AC:L/AT:N/PR:L/UI:N/VC:H/VI:N/VA:N/SC:H/SI:N/SA:N
Network-reachable, low complexity; PR:L because a permitted MCP caller is required; S:C as data is accessed beyond the intended authorization boundary via operator creds; confidentiality-only, so I:N/A:N.
Primary rating from Vendor (GitHub_M).
CVSS VectorVendor: GitHub_M
Lifecycle Timeline
2DescriptionCVE.org
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.
Technical POC Analysis
Authorization allowlist enforced by a string-presence check instead of parsing the query.
Full technical POC analysis - root cause, step-by-step exploitation and patch breakdown - is part of the Pro and Business plans.
Executive ViewAI
MCP Atlassian, an open-source connector that lets AI assistants query Jira and Confluence, can return content its administrators believed they had fenced off: project filters, Confluence space filters, and agile board restrictions are not consistently enforced across all query paths. Organizations running the connector with a shared, broadly privileged Atlassian service account - the common delegated and multi-tenant pattern - can expose Jira issues, boards, and Confluence pages to any MCP client the server accepts, silently eroding the access boundaries leadership depends on for data governance in AI tooling. No public exploit has been identified at time of analysis, but the flaw directly undercuts least-privilege claims made to data owners and auditors.
No vendor-released patch identified at time of analysis. Interim mitigations: reduce the Atlassian service account's permissions so its real access matches the configured project and space filters, since out-of-scope disclosure only occurs when those credentials are broader than the intended allowlist; issue distinct credentials per MCP server instance, client, or tenant rather than one shared operator account; constrain which clients may reach the MCP server through network and authentication controls; disable or undeploy the board-related tooling (get_board_issues, get_agile_boards) if agile board access is not required; and enable and monitor Atlassian audit logs and MCP server access logs for anomalous cross-project or cross-space queries.
Threat Intelligence Overview
How this decision was reached
The engine reads each signal below and applies a fixed list of rules from top to bottom. The first rule that matches sets the recommended action – like a statement, every line is shown.
What every action level means
SSVC AssessmentENISA
Priority Score
Attack Technique
Information disclosure occurs when an application unintentionally exposes sensitive data that aids attackers in reconnaissance or directly compromises security.
More in Mcp Atlassian
View allServer-side request forgery in MCP Atlassian (the Model Context Protocol server for Confluence and Jira) prior to 0.22.0
MCP Atlassian (sooperset/mcp-atlassian) before 0.22.0 applies its ENABLED_TOOLS and TOOLSETS least-privilege filters onl
Path traversal in MCP Atlassian releases prior to 0.22.0 lets a caller of the confluence_upload_attachment MCP tool read
Unauthenticated arbitrary file read in MCP Atlassian (sooperset/mcp-atlassian) before 0.22.0 lets a remote network calle
Arbitrary local file read leading to data exfiltration affects sooperset's MCP Atlassian server (mcp-atlassian) prior to
Unauthenticated server-local file exfiltration in MCP Atlassian (sooperset/mcp-atlassian) before 0.22.0 allows a remote
Server-side request forgery in MCP Atlassian prior to 0.22.0 lets an attacker who controls or has already compromised th
MCP Atlassian (sooperset/mcp-atlassian) before 0.22.0 lets a low-privileged authenticated MCP caller write attacker-chos
Server-side request forgery in MCP Atlassian (sooperset/mcp-atlassian) before 0.22.0 allows a low-privileged authenticat
Arbitrary local file read in MCP Atlassian (mcp-atlassian) prior to 0.22.0 allows an authenticated MCP caller who can re
Arbitrary server-local file read and exfiltration in MCP Atlassian (sooperset/mcp-atlassian) prior to 0.22.0 lets an aut
Path traversal in the MCP Atlassian server (mcp-atlassian) prior to 0.22.0 allows an authenticated MCP client to read fi
EUVD-2026-84625
GHSA-w66g-j6c4-hcfc
NVD
CVE.org
EPSS
Exploit-DB