<?xml version='1.0' encoding='UTF-8'?>
<?xml-stylesheet href="/static/style.xsl" type="text/xsl"?>
<feed xmlns="http://www.w3.org/2005/Atom" xml:lang="en">
  <id>https://vulnerability.circl.lu/rss/recent/all/10</id>
  <title>Most recent entries from all</title>
  <updated>2026-10-02T21:42:32.098071+00:00</updated>
  <author>
    <name>Vulnerability-Lookup</name>
    <email>info@circl.lu</email>
  </author>
  <link href="https://vulnerability.circl.lu" rel="alternate"/>
  <generator uri="https://lkiesow.github.io/python-feedgen" version="1.0.0">python-feedgen</generator>
  <subtitle>Contains only the most 10 recent entries.</subtitle>
  <entry>
    <id>https://vulnerability.circl.lu/vuln/cve-2026-77259</id>
    <title>CVE-2026-77259 — MCP Atlassian: Arbitrary file read via confluence_upload_attachment allows exfiltration of server credentials</title>
    <updated>2026-10-02T21:42:32.115203+00:00</updated>
    <content type="xhtml">
      <div xmlns="http://www.w3.org/1999/xhtml"><p><strong>Affected:</strong> sooperset mcp-atlassian</p>
<p>MCP Atlassian is a Model Context Protocol (MCP) server for Atlassian products (Confluence and Jira). Prior to 0.22.0, confluence_upload_attachment opens a caller-selected server-local file without checking that the resolved path remains in the workspace. A caller can upload environment files, credentials, or other readable host data to a Confluence page and retrieve it through Atlassian. The advisory traces the vulnerable input and processing flow through confluence_upload_attachment, file_path, and open(file_path, "rb"), which identify the affected entry points, controls, and code paths. This issue is fixed in version 0.22.0.</p></div>
    </content>
    <link href="https://vulnerability.circl.lu/vuln/cve-2026-77259"/>
  </entry>
  <entry>
    <id>https://vulnerability.circl.lu/vuln/ghsa-6cr4-ccf3-x7h4</id>
    <title>GHSA-6cr4-ccf3-x7h4 — MCP Atlassian: Arbitrary file read via confluence_upload_attachment allows exfiltration of server credentials</title>
    <updated>2026-10-02T21:42:32.115344+00:00</updated>
    <content type="xhtml">
      <div xmlns="http://www.w3.org/1999/xhtml"><p><strong>Affected:</strong> PyPI: mcp-atlassian</p>
<p>### Summary</p>
<p>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.</p>
<p>---
### Details</p>
<p>`AttachmentsMixin.upload_attachment()` in `src/mcp_atlassian/confluence/attachments.py` opens the caller-supplied `file_path` with no boundary check:</p>
<p>```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.</p>
<p>---
### PoC</p>
<p>```bash
# 1. Prepare target file (macOS demo; on Linux use /proc/self/environ directly)
cp ~/.aws/credentials /tmp/diagram.png</p>
<p># 2. Call the MCP tool
confluence_upload_attachment(
    content_id = "&lt;any page attacker can edit&gt;",
    file_path  = "/tmp/diagram.png"
)</p>
<p># 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.</p>
<p>---
### 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/env…</p></div>
    </content>
    <link href="https://vulnerability.circl.lu/vuln/ghsa-6cr4-ccf3-x7h4"/>
  </entry>
</feed>
