CVE-2026-77249 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, JiraUserMixin._lookup_user_by_permissions uses the module-level requests.get function instead of the fetcher's protected session. A caller-controlled public Jira URL can redirect that unhooked request to an internal address, bypassing the redirect checks added for CVE-2026-27826. The advisory traces the vulnerable input and processing flow through JiraUserMixin._lookup_user_by_permissions, requests.get, self.jira._session.get, and _make_ssrf_safe_hook, 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 Server-Side Request Forgery (SSRF) flaw rooted in inconsistent session management within the JiraUserMixin class. Specifically, the method _lookup_user_by_permissions utilizes the global requests.get function rather than the protected session instance maintained by the fetcher component. This architectural inconsistency creates a significant security gap because the module-level request object lacks the specific hooks and validation logic applied to the primary session used for other operations. The core issue lies in the failure to enforce uniform security controls across all network communication paths within the application, allowing an attacker to exploit this discrepancy to bypass existing safeguards.
The operational impact of this flaw is severe as it enables unauthorized access to internal resources that are typically isolated from external networks. An attacker can craft a public Jira URL containing a redirect target pointing to an internal address, such as localhost or private IP ranges. When the vulnerable method executes its request using requests.get, it does not trigger _make_ssrf_safe_hook, which is responsible for validating and sanitizing URLs against SSRF patterns. Consequently, the unhooked request follows the redirect chain directly to the internal destination without undergoing the necessary security checks that were implemented in response to previous vulnerabilities like CVE-2026-27826. This allows the attacker to interact with internal services, potentially leading to data exfiltration or further exploitation of backend systems.
From a classification perspective, this vulnerability aligns with CWE-918, which addresses Server-Side Request Forgery (SSRF) flaws where server-side code makes requests based on user-supplied input without proper validation. The specific mechanism here involves the use of an unvalidated HTTP client instance that bypasses security middleware or hooks designed to prevent internal network access. In terms of attack tactics, this behavior corresponds to ATT&CK technique T1571, which covers Non-Standard Ports and Protocols often used in SSRF attacks to reach internal services, as well as the broader category of Server-Side Request Forgery under T1434 if it involves network-level manipulation. The failure lies not just in the request itself but in the inconsistent application of security controls across different code paths within the same module.
To mitigate this vulnerability, organizations must immediately upgrade MCP Atlassian to version 0.22.0 or later, where the developers have corrected the session handling logic to ensure all requests pass through the secure hook mechanism. In environments where upgrading is not immediately feasible, network-level controls such as firewall rules should be implemented to restrict outbound connections from the server hosting MCP Atlassian to only known and necessary external endpoints. Additionally, input validation at the proxy or reverse gateway level can help detect and block redirect chains that attempt to access internal IP ranges. It is also recommended to review other instances within the codebase where requests.get might be used directly instead of through a validated session object to prevent similar bypasses in future updates.