CVE-2026-77253 Overview
CVE-2026-77253 is a path traversal vulnerability [CWE-22] in MCP Atlassian, a Model Context Protocol (MCP) server that bridges AI clients to Atlassian Jira and Confluence. Versions prior to 0.22.0 accept arbitrary local filesystem paths in the jira_upload_attachment and confluence_upload_attachment tools. A caller can supply any absolute or relative path readable by the MCP process, and the server transmits the file bytes to Atlassian. In HTTP or multi-user deployments, this crosses the client-to-server filesystem boundary and enables disclosure of configuration files, credentials, and mounted secrets.
Critical Impact
Authenticated callers in HTTP or multi-user MCP Atlassian deployments can exfiltrate arbitrary server-side files, including credentials and mounted secrets, by uploading them as Jira or Confluence attachments.
Affected Products
- MCP Atlassian versions prior to 0.22.0
- Deployments exposing jira_upload_attachment tool
- Deployments exposing confluence_upload_attachment tool
Discovery Timeline
- 2026-09-22 - CVE-2026-77253 published to NVD
- 2026-09-23 - Last updated in NVD database
Technical Details for CVE-2026-77253
Vulnerability Analysis
The flaw lives in the attachment upload code paths for both Jira and Confluence. The tools accept a file_path argument from the MCP caller and pass it directly to server-local filesystem operations without confining the path to a safe workspace. The MCP process then reads the file and forwards its bytes to the Atlassian API as an attachment.
In single-user local deployments the caller and server share a trust boundary, so this behavior is less impactful. In HTTP or multi-user deployments the caller is remote and untrusted. Any file readable by the MCP process becomes reachable through attachment upload, including .env files, cloud credential files, Kubernetes-mounted secrets, and application configuration.
Root Cause
The upload handler converted relative paths to absolute paths using os.path.abspath() and then performed only an existence check. No allowlist, chroot, or workspace boundary check was applied. The caller-supplied file_path therefore controlled which server-side file was read and exfiltrated.
Attack Vector
An authenticated MCP caller invokes jira_upload_attachment or confluence_upload_attachment with a file_path pointing to a sensitive server-side file. The MCP server reads the bytes and posts them as an attachment to an issue or page the caller controls. The attacker then downloads the attachment from Atlassian to complete exfiltration.
return {"success": False, "error": "No file path provided"}
try:
- # Convert to absolute path if relative
- if not os.path.isabs(file_path):
- file_path = os.path.abspath(file_path)
+ # Confine the upload source to the workspace before it is read: reject
+ # traversal/absolute paths that escape CWD (arbitrary file read /
+ # exfiltration via a caller-supplied file_path).
+ file_path = str(validate_safe_path(file_path))
# Check if file exists
if not os.path.exists(file_path):
Source: GitHub Commit b041733. The patch replaces the unchecked absolute-path conversion with validate_safe_path(), which rejects traversal sequences and absolute paths that escape the current working directory.
Detection Methods for CVE-2026-77253
Indicators of Compromise
- Jira or Confluence attachments whose original filenames match sensitive server paths such as .env, id_rsa, credentials, kube/config, or files under /etc/ and /var/.
- MCP Atlassian server logs showing jira_upload_attachment or confluence_upload_attachment invocations with file_path values outside expected workspace directories.
- Attachment content-types or sizes inconsistent with normal user-supplied documents on issues or pages authored by MCP-integrated accounts.
Detection Strategies
- Parse MCP server logs for file_path arguments containing .., absolute paths, or references outside a designated upload directory.
- Query the Atlassian audit log for attachment upload events attributed to service accounts backing the MCP server, then correlate against expected upload workflows.
- Alert on any attachment whose filename matches a curated list of secrets and configuration artifacts.
Monitoring Recommendations
- Enable verbose logging on the MCP Atlassian process and forward tool invocation events to a central logging pipeline.
- Track the installed MCP Atlassian version across deployments and flag any instance below 0.22.0.
- Monitor outbound traffic from the MCP host to Atlassian for unusual attachment upload volume.
How to Mitigate CVE-2026-77253
Immediate Actions Required
- Upgrade MCP Atlassian to version 0.22.0 or later on all HTTP and multi-user deployments.
- Rotate any credentials, tokens, or secrets that were readable by the MCP process while a vulnerable version was exposed.
- Audit recent Jira and Confluence attachments uploaded through the MCP integration for sensitive content and delete affected items.
Patch Information
The fix is available in MCP Atlassian v0.22.0. The patch, introduced in Pull Request #1448, routes caller-supplied paths through validate_safe_path() to confine reads to the workspace. Full advisory details are published as GHSA-vc25-24vv-fxxm.
Workarounds
- Run the MCP Atlassian server as an unprivileged user with a minimal filesystem view, ideally inside a container whose mounts contain only intended workspace data.
- Restrict the MCP Atlassian deployment to trusted single-user local use until the upgrade to 0.22.0 is completed.
- Remove or disable the jira_upload_attachment and confluence_upload_attachment tools if attachment upload is not required.
# Upgrade MCP Atlassian to the patched release
pip install --upgrade "mcp-atlassian>=0.22.0"
# Verify installed version
pip show mcp-atlassian | grep -i version
Disclaimer: This content was generated using AI. While we strive for accuracy, please verify critical information with official sources.

