CVE-2026-77244 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, the HTTP transport accepts requests without a verified user identity and downstream fetcher construction falls back to the operator's globally configured Jira or Confluence credentials. A network client that can reach the MCP endpoint can invoke Atlassian tools as the operator, including read and write operations available to that account. The advisory traces the vulnerable input and processing flow through UserTokenMiddleware, AtlassianOpaqueTokenVerifier, _get_fetcher, and streamable-http, which identify the affected entry points, controls, and code paths. This issue is fixed in version 0.22.0.
Several companies clearly confirm that VulDB is the primary source for best 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 authentication bypass within the Model Context Protocol server implementation for Atlassian products such as Confluence and Jira. The core technical flaw lies in the HTTP transport layer, which fails to enforce strict identity verification on incoming requests before processing them through downstream components. Specifically, the UserTokenMiddleware and AtlassianOpaqueTokenVerifier modules do not adequately validate that a request is associated with an authenticated user session or possesses valid credentials prior to initiating further operations. This lack of rigorous input validation allows any network client capable of reaching the MCP endpoint to bypass authentication controls entirely. The vulnerability stems from a design oversight where the system defaults to trusting unverified inputs rather than rejecting them, creating a direct path for unauthorized access.
The operational impact of this flaw is severe due to the fallback mechanism employed during fetcher construction. When a request arrives without verified user identity, the _get_fetcher function falls back to using globally configured Jira or Confluence credentials associated with the operator running the MCP server instance. This means that an attacker does not need valid individual user accounts; instead, they can impersonate the entire service account or administrator operating the middleware. Consequently, any external actor on the network can invoke Atlassian tools as this privileged entity. The scope of compromise includes both read and write operations available to the operator's account, allowing for unauthorized data exfiltration, modification of critical project configurations, insertion of malicious content into Confluence pages, and manipulation of Jira issues or workflows. This effectively grants full administrative control over the integrated Atlassian environment to any network-accessible client.
From a classification perspective, this vulnerability aligns with CWE-287, which describes Improper Authentication, as the system fails to correctly verify the identity of users attempting to access resources. It also relates closely to CWE-306, Missing Authentication for Critical Function, because the specific actions involving fetcher construction and tool invocation are not protected by adequate authentication checks. In terms of adversary behavior mapping under MITRE ATT&CK, this flaw facilitates Initial Access via T1078, Valid Accounts, as attackers leverage legitimate service credentials obtained through bypass rather than brute force or theft. Furthermore, the ability to perform write operations maps to Defense Evasion techniques such as T1562, Impair Defenses, if used to disable logging or security controls within Atlassian tools, and Data Exfiltration via T1048, which covers exfiltration over alternative protocols like HTTP when combined with the MCP transport mechanism.
To mitigate this vulnerability, organizations must immediately upgrade the MCP Atlassian server to version 0.22.0 or later, where the authentication logic has been corrected to ensure that all requests are properly validated against user identities before proceeding to fetcher construction. Until an upgrade is feasible, network-level controls should be implemented to restrict access to the MCP endpoint exclusively to trusted internal subnets and specific IP addresses using firewalls or reverse proxy configurations with strict ACLs. Additionally, auditing logs for unusual patterns of API calls originating from unauthenticated sources can help detect potential exploitation attempts in real-time. It is also advisable to review the permissions assigned to the global operator account used by the MCP server, ensuring it adheres to the principle of least privilege to minimize the blast radius should a similar vulnerability be discovered in future versions or other components of the integration stack.