<?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-01T15:51:41.896219+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/fkie_cve-2026-77270</id>
    <title>fkie_cve-2026-77270</title>
    <updated>2026-10-01T15:51:41.899122+00:00</updated>
    <content type="xhtml">
      <div xmlns="http://www.w3.org/1999/xhtml">
        <p>MCP Atlassian is a Model Context Protocol (MCP) server for Atlassian products (Confluence and Jira). Prior to 0.22.0, the Jira and Confluence attachment upload tools treat caller-controlled file_path values as trusted server-local paths. The server opens the selected file and uploads it to an Atlassian issue or page, allowing an MCP caller with upload access to disclose any file readable by the server process. The advisory traces the vulnerable input and processing flow through confluence_upload_attachment, jira_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/fkie_cve-2026-77270"/>
  </entry>
  <entry>
    <id>https://vulnerability.circl.lu/vuln/ghsa-f26r-j276-ggg4</id>
    <title>GHSA-f26r-j276-ggg4 — MCP Atlassian: Arbitrary File Read via Upload Attachment Tools</title>
    <updated>2026-10-01T15:51:41.899198+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>The upload attachment tools in both Confluence and Jira accept arbitrary file paths without path traversal validation. The upload_attachment methods read any file accessible to the server process and upload it to a Confluence page or Jira issue. Despite the existence of a validate_safe_path utility function (used correctly in download operations), the upload paths do not use it. This allows an authenticated MCP client (or an AI assistant manipulated via prompt injection) to exfiltrate arbitrary files from the server filesystem to an attacker-controlled Confluence page or Jira issue.</p>
<p>## Details</p>
<p>The vulnerability exists in two parallel code paths:</p>
<p>### Confluence: src/mcp_atlassian/confluence/attachments.py:35-108</p>
<p># src/mcp_atlassian/confluence/attachments.py:62-65
    # Convert to absolute path if relative
    if not os.path.isabs(file_path):
        file_path = os.path.abspath(file_path)</p>
<p># Check if file exists
    if not os.path.exists(file_path):
        # error...</p>
<p>The file_path parameter is only checked for existence, not for path traversal. Any path like /etc/passwd, /etc/shadow, ~/.ssh/id_rsa, or ../../../sensitive-file is accepted.</p>
<p>**Contrast with Confluence download operations (which ARE protected):**</p>
<p># src/mcp_atlassian/confluence/attachments.py:223
    validate_safe_path(target_path)  # &lt;-- used for downloads</p>
<p># src/mcp_atlassian/confluence/attachments.py:272
    validate_safe_path(target_dir)   # &lt;-- used for downloads</p>
<p>The validat…</p></div>
    </content>
    <link href="https://vulnerability.circl.lu/vuln/ghsa-f26r-j276-ggg4"/>
  </entry>
</feed>
