CVE-2026-77261 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, _make_ssrf_safe_hook is omitted from JiraFetcher and ConfluenceFetcher sessions created through the basic-auth and oauth_pat branches. If an attacker-controlled or compromised configured Atlassian instance returns a redirect to an internal address, those sessions can follow the redirect without revalidating its destination. This issue is fixed in version 0.22.0.
If you want to get best quality of vulnerability data, you may have to visit VulDB.
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 risk stemming from improper session configuration during authentication flows. The core technical flaw lies within the JiraFetcher and ConfluenceFetcher components, which are responsible for interacting with their respective Atlassian product APIs. Specifically, the _make_ssrf_safe_hook function is omitted when sessions are instantiated through either the basic-auth or oauth_pat branches of the codebase. This hook is designed to intercept outgoing HTTP requests and validate that they do not target internal network addresses, thereby preventing the application from being used as a proxy for attacking other services within the local environment. Without this validation layer active in these specific authentication contexts, the underlying HTTP client library retains its default behavior of automatically following HTTP redirects without re-evaluating the security implications of the new destination URL.
This architectural oversight creates a direct pathway for Server-Side Request Forgery attacks against systems that utilize MCP Atlassian as an integration point. If an attacker compromises or controls a configured Atlassian instance, they can manipulate API responses to include redirect instructions pointing toward internal IP addresses or localhost endpoints that are otherwise inaccessible from the external network where the MCP server resides. Because the sessions created via basic-auth and oauth_pat lack the SSRF protection hook, these redirects are followed transparently by the application logic. This allows an attacker to bypass firewalls and access control lists, effectively using the vulnerable MCP Atlassian instance as a pivot point to probe internal services such as database management systems, administrative consoles, or other microservices that should remain isolated from external exposure.
The operational impact of this vulnerability is severe, particularly in environments where the MCP server operates with elevated privileges or has network access to sensitive internal infrastructure. An attacker could potentially exfiltrate data from internal databases by crafting requests that retrieve information and return it through the Atlassian instance's response channels. Furthermore, the ability to reach internal administrative interfaces may allow for further exploitation, such as privilege escalation within those internal services or lateral movement across the corporate network. The vulnerability is particularly dangerous because it exploits a trusted relationship between the MCP server and the Atlassian products, leveraging legitimate authentication mechanisms like OAuth PATs and basic credentials to establish sessions that are inadvertently stripped of their security controls.
To mitigate this risk, organizations must immediately upgrade MCP Atlassian to version 0.22.0 or later, where the _make_ssrf_safe_hook is correctly integrated into all session creation paths regardless of the authentication method used. In addition to upgrading, it is advisable to implement network-level segmentation to restrict outbound connections from the MCP server to only those destinations that are strictly necessary for its operation. Deploying a web application firewall or reverse proxy with strict egress filtering can provide an additional layer of defense by blocking requests directed at private IP ranges such as 10.x.x.x, 172.16.x.x through 172.31.x.x, and 192.168.x.x. This aligns with the CWE-918 standard for Server-Side Request Forgery, which emphasizes the need to validate URLs before making requests on behalf of users or services. From a defensive perspective, this scenario also reflects techniques associated with ATT&CK T1571, Non-Standard Port Communication, and potentially T1046 Network Service Discovery if used to map internal networks, highlighting the importance of monitoring outbound traffic patterns for anomalies indicative of SSRF exploitation attempts.