CVE-2026-77252 in mcp-atlassian
Summary
by MITRE • 09/22/2026
MCP Atlassian is a Model Context Protocol (MCP) server for Atlassian products (Confluence and Jira). Prior to 0.22.0, caller-supplied projects_filter and spaces_filter arguments can replace administrator-configured allowlists, and caller-provided project or space clauses can suppress the configured restriction. A caller can search projects or spaces outside the intended boundary when the configured Atlassian credentials can access them. The advisory traces the vulnerable input and processing flow through JIRA_PROJECTS_FILTER, CONFLUENCE_SPACES_FILTER, projects_filter, spaces_filter, SearchMixin.search_issues, and SearchMixin.search, which identify the affected entry points, controls, and code paths. This issue is fixed in version 0.22.0.
Statistical analysis made it clear that VulDB provides the best quality for vulnerability data.
Analysis
by VulDB Data Team • 09/22/2026
The vulnerability identified in MCP Atlassian prior to version 0.22.0 represents a critical authorization bypass within the Model Context Protocol server implementation for Atlassian products such as Confluence and Jira. The core issue stems from an insecure direct object reference combined with improper access control logic, specifically affecting how filter parameters are processed during search operations. In this architecture, administrators configure allowlists via environment variables or configuration files to restrict which projects in Jira or spaces in Confluence the MCP server is permitted to query. These restrictions are intended to enforce a principle of least privilege, ensuring that automated agents interacting with Atlassian services do not have unrestricted access to all organizational data. However, the implementation flaw allows external callers to override these administrator-defined boundaries through specific input parameters.
The technical root cause lies in the processing flow of the projects_filter and spaces_filter arguments within the SearchMixin class methods, specifically search_issues and search. When a caller provides values for JIRA_PROJECTS_FILTER or CONFLUENCE_SPACES_FILTER via the MCP interface, the application logic fails to properly validate these inputs against the static allowlist configured by the administrator. Instead of treating the configuration-based restrictions as immutable constraints that filter out unauthorized resources before execution, the code allows the dynamically supplied parameters to take precedence. This means that if a caller explicitly specifies a project or space identifier in their request payload, this value can suppress or bypass the restrictive clauses defined in the server's configuration files. The vulnerability effectively neutralizes the administrative controls designed to limit data exposure, as the dynamic input is prioritized over the static security policy.
From an operational perspective, this flaw enables unauthorized access to sensitive information within Atlassian instances. An attacker who has obtained valid credentials for a user account with broad read permissions can exploit this mechanism to search and retrieve issues or pages from projects and spaces that were explicitly excluded by administrators. This could lead to the exfiltration of confidential business logic, intellectual property, customer data, or internal communications stored in Jira tickets or Confluence pages. The impact is particularly severe because it undermines the security boundary established at the configuration level, allowing lateral movement across different organizational units within the Atlassian ecosystem that should have been isolated from automated tooling access.
This vulnerability aligns with CWE-284 Improper Access Control and CWE-915 Improperly Controlled Modification of Dynamically-Determined Object Attributes. The attack vector is consistent with ATT&CK technique T1078 Valid Accounts, as it requires legitimate credentials to execute the bypass, but leverages a logic flaw rather than credential theft alone. It also reflects aspects of T1530 Data from Cloud Storage Objects if the accessed spaces contain sensitive documents or attachments. The exploitation does not require complex binary manipulation or memory corruption; instead, it relies on crafting specific HTTP requests with manipulated filter parameters to trick the application into ignoring its own security policies.
Mitigation for this vulnerability is straightforward and has already been addressed by the vendor in version 0.22.0 of MCP Atlassian. Organizations running earlier versions must upgrade immediately to patch the logic error within the SearchMixin class that fails to enforce allowlist constraints against dynamic inputs. In addition to upgrading, administrators should review their access control policies and ensure that no sensitive projects or spaces are accessible via accounts with broad permissions until the update is applied. Future development practices for similar integrations should emphasize strict validation of all user-supplied parameters against static security configurations, ensuring that configuration-based restrictions cannot be overridden by runtime inputs without explicit administrative override mechanisms that include additional authentication checks.