GHSA-WM45-QH3G-V83F: Arbitrary Server-Side File Read and Exfiltration via Attachment Upload in mcp-atlassian

The Model Context Protocol (MCP) establishes a standardized framework for exposing local capabilities, data, and tools to Large Language Models (LLMs) and cognitive agents. In typical local deployments, the MCP client and the MCP server operate co-located on the same physical loopback interface, sharing security boundaries and filesystem contexts. Under this local execution paradigm, passing absolute or relative file paths as tool arguments introduces minimal risk since the server runs with the identical privileges of the invoking user.

However, when the MCP server is deployed over remote transports, such as Server-Sent Events (SSE) or custom HTTP routing bindings (e.g., binding to wildcard interfaces like 0.0.0.0), a physical and security boundary is established between the remote client and the hosting server. In these architectural configurations, the assumption that the file paths map to the client's workspace is violated. The server attempts to map client-provided path strings to its own underlying host filesystem.

The mcp-atlassian package integrates MCP-enabled applications with Atlassian Jira and Confluence cloud instances. It exposes high-privilege tools meant to allow users to sync local documents as page attachments. Because the endpoint registers a raw file_path string argument instead of demanding multi-part file binary streams, any remote caller with access to tool execution interfaces can force the backend to perform local disk reads, crossing the critical system execution boundary.

The vulnerability is characterized as an arbitrary server-side file read, mapping closely to the mechanics of CWE-22 (Path Traversal) and CWE-552 (Files or Directories Accessible to External Parties). The primary root cause resides in the lack of path sanitization, root-jail enforcement, or canonicalization checks on user-controlled input before passing it to high-privilege filesystem read sinks. The application receives a string parameter named file_path and processes it via standard operating system abstractions without verifying if the path is contained within a designated temporary directory or workspace.

Two distinct execution paths lead directly to arbitrary file extraction. The first exists within the Confluence attachment module at src/mcp_atlassian/confluence/attachments.py. When a client invokes the confluence_upload_attachment or confluence_upload_attachments tools, the execution flow routes through upload_attachment to the inner helper _upload_attachment_direct. Here, the application calls os.path.abspath(file_path) to retrieve the absolute path before passing it to Python's built-in open(file_path, "rb") routine.

The second vulnerable sink is located within the Jira integration at src/mcp_atlassian/jira/attachments.py. Under this flow, calling jira_update_issue with an attachments argument invokes IssuesMixin.update_issue, which forwards the strings to self.upload_attachments. The absolute path of each item is resolved and resolved directly into an unconfined read sink. Because Python's open() handles absolute path strings and parent directory traversal components (../) by climbing outside the current working directory, the operating system kernel fulfills the read requests for any file readable by the process's effective UID.

To understand the structural failure, we can examine the conceptual representation of the vulnerable code path compared to secure design principles. The vulnerable functions resolve files dynamically using the host's default filesystem resolver without isolation. This is represented visually in the following architecture diagram:

In an unpatched installation of mcp-atlassian (versions < 0.22.0), the vulnerable implementation of the direct upload operates roughly as follows:

# Vulnerable implementation in src/mcp_atlassian/confluence/attachments.py
def _upload_attachment_direct(file_path, content_id):
    # Absolute or relative traversal paths are accepted directly
    resolved_path = os.path.abspath(file_path)
    
    # The application opens and reads the file without verifying containment
    with open(resolved_path, "rb") as f:
        file_data = f.read()
        
    # File contents are then sent straight to the external Atlassian API
    response = self.client.upload_attachment_to_confluence(content_id, file_data)
    return response

A robust remediation of this pattern requires validating that the target file falls strictly within an authorized, pre-configured directory. The secure pattern is demonstrated below:

# Patched/secure implementation pattern
def _upload_attachment_secure(file_path, content_id, allowed_directory="/app/workspace"):
    # Normalize and canonicalize both paths
    base_dir = os.path.realpath(allowed_directory)
    target_path = os.path.realpath(file_path)
    
    # Prevent directory traversal attacks by checking the common prefix
    if not target_path.startswith(base_dir + os.path.sep) and target_path != base_dir:
        raise PermissionError("Access denied: Path is outside the sandbox boundary")
        
    with open(target_path, "rb") as f:
        file_data = f.read()
        
    # Proceed with safe upload

Exploitation of this vulnerability requires network connectivity to the MCP server's transport port (or indirect access via a compromised front-end web application that communicates with the MCP back-end) and permission to issue tool calls. In a typical scenario where the MCP server is exposed to facilitate integration with remote LLM user interfaces, an attacker can directly issue standard MCP protocol JSON-RPC payloads.

To retrieve a critical host credential store or configuration file, the attacker first selects a destination entity, such as an active Confluence page ID or a Jira issue key that they have access to read. They then send a tools/call JSON payload specifying the targeting parameters. For example, by specifying /etc/passwd as the file_path, the server will ingest the user account list and upload it as a new attachment to the specified Confluence page.

Once the attachment is successfully written to the Atlassian instance, the attacker exfiltrates the contents using the corresponding retrieval or download tool. For Confluence, invoking confluence_download_attachment with the returned attachment ID fetches the file from the cloud storage and outputs it as a base64-encoded block or raw text stream directly to the attacker. In Jira, the attacker can log in to the Jira web console or fetch the ticket attachments via API to retrieve the host's files.

A highly critical exploit path involves targeting /proc/self/environ on Linux hosts. Many containerized deployments load sensitive credentials, including the server's own CONFLUENCE_API_TOKEN and JIRA_API_TOKEN, directly into environmental variables. Although /proc/self/environ registers a size of zero bytes in directory listings, standard stream readers can read it sequentially. By reading this virtual path, the attacker extracts the application's configuration environment, acquiring high-privilege administrative tokens to compromise the entire corporate Atlassian workspace.

The security impact of this vulnerability is elevated due to the role of MCP servers as privileged integration nodes. The CVSS base score of 7.7 reflects the high severity of unauthenticated or low-privilege confidentiality loss across distinct authorization boundaries. The scope metric is explicitly marked as 'Changed' (S:C) because the exploit allows an attacker operating within the logical boundaries of the MCP application protocol to read arbitrary files from the underlying operating system's filesystem.

This boundary crossing completely bypasses container isolation or logical tenant partitioning if multiple client interfaces share the same backend server. Furthermore, the vulnerability serves as a direct pipeline for lateral movement. By exfiltrating local source code, database credentials, or host SSH keys, an attacker can pivot from a restricted tool integration container to full host-level exploitation or persistent network-wide access.

Additionally, the compromise of the Atlassian API tokens themselves presents an immediate secondary risk. Because the server must maintain operational API access to Jira and Confluence, the exposure of /proc/self/environ or local disk configuration files grants the attacker administrative access to the connected cloud spaces. This can lead to unauthorized data manipulation, access to internal corporate wikis, and theft of proprietary IP.

To completely remediate this flaw, administrators must upgrade mcp-atlassian to version 0.22.0 or later. The patch alters the file processing architecture to enforce isolation boundaries. If an immediate upgrade is not feasible, several defensive workarounds must be deployed to mitigate the attack surface.

First, restrict the network binding of the MCP server. Ensure that the service binds strictly to local loopback interfaces (such as 127.0.0.1) rather than wildcards (0.0.0.0). Forcing clients to authenticate via a secure proxy or restricting tool access to a local stdio transport eliminates remote exploitability.

Second, implement process isolation using Docker containerization combined with read-only filesystems. Running the containerized MCP process as a non-privileged user (with a high UID) and mounting only essential directories ensures that even if a traversal occurs, the process lacks read access to critical directories like /etc, /proc, or /var/run. The container should be configured with the minimum required environment variables, utilizing secure secret managers rather than exposing high-value keys in /proc/self/environ.