CVE-2026-77243 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, ENABLED_TOOLS and TOOLSETS are applied when tools are listed but are not rechecked when a tools/call request is dispatched. A client that knows a hidden tool name can directly invoke excluded read, write, or delete tools despite the operator's configured least-privilege restrictions. The advisory traces the vulnerable input and processing flow through ENABLED_TOOLS, TOOLSETS, tools/list, tools/call, and _call_tool_mcp, which identify the affected entry points, controls, and code paths. This issue is fixed in version 0.22.0.
Be aware that VulDB is the high quality source for vulnerability data.
Analysis
by VulDB Data Team • 09/22/2026
The vulnerability identified in MCP Atlassian versions prior to 0.22.0 represents a critical authorization bypass within the Model Context Protocol implementation for Atlassian products such as Confluence and Jira. The core of this issue lies in the inconsistent application of access control policies during different phases of tool invocation. Specifically, while the system correctly filters available tools when listing them based on configuration parameters like ENABLED_TOOLS and TOOLSETS, it fails to enforce these same restrictions at the moment a specific tool is called by a client. This architectural flaw creates a discrepancy between what an operator perceives as their allowed capabilities and what they can actually execute programmatically.
From a technical perspective, the vulnerability stems from a lack of state validation during the execution phase. When a client requests a list of tools via the tools/list endpoint, the server correctly applies least-privilege principles by filtering out restricted operations based on the configured toolsets. However, when the client subsequently issues a request to invoke a specific function through the tools/call endpoint or internal _call_tool_mcp handler, the system does not re-evaluate these access controls against the user's current permissions. Consequently, if an attacker or malicious actor discovers the name of a hidden or restricted tool, they can directly dispatch requests to execute read, write, or delete operations that were explicitly excluded from their profile. This bypasses the intended security boundaries established by the system administrator.
The operational impact of this vulnerability is severe, particularly in environments where MCP servers are used to automate workflows with varying levels of privilege. An attacker who gains access to a client connected to an Atlassian instance could exploit this flaw to escalate privileges beyond their assigned role. For read operations, this could lead to the exfiltration of sensitive corporate data stored in Confluence pages or Jira issues that should be restricted. More critically, for write and delete operations, the vulnerability allows unauthorized modification or destruction of critical project data, configuration settings, or user accounts. This undermines the integrity and confidentiality guarantees provided by Atlassian's native permission models, effectively rendering least-privilege configurations ineffective against determined adversaries who can enumerate tool names.
This flaw aligns with CWE-269 Improper Privilege Management, as it involves a failure to enforce proper authorization levels during execution despite correct configuration at initialization or listing stages. It also relates to CWE-749 Exposed Dangerous Method in an Object-Oriented Context, where internal methods are accessible without adequate checks. In the context of the MITRE ATT&CK framework, this vulnerability facilitates Privilege Escalation and potentially Data Exfiltration by allowing unauthorized access to restricted functions that should be blocked based on user roles. The attack vector typically involves indirect interaction with the API after initial enumeration, exploiting the trust placed in client-side filtering rather than server-side enforcement for every action.
To mitigate this risk, organizations must immediately upgrade MCP Atlassian to version 0.22.0 or later, where the developers have corrected the logic to ensure that ENABLED_TOOLS and TOOLSETS are validated during both the listing and calling phases of tool interaction. Until an update is applied, administrators should restrict network access to the MCP server endpoint to only trusted clients with known good behavior and monitor for unusual patterns in tools/call requests that target restricted functions. Additionally, implementing strict input validation on all API endpoints and auditing logs for attempts to invoke hidden or disabled tools can help detect exploitation attempts. It is also advisable to review existing least-privilege configurations to ensure they are robust enough to withstand potential bypasses until the patch is fully deployed across all instances.