<?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://db.gcve.eu/rss/recent/all/10</id>
  <title>Most recent entries from all</title>
  <updated>2026-09-30T21:11:05.254089+00:00</updated>
  <author>
    <name>Vulnerability-Lookup</name>
    <email>info@gcve.eu</email>
  </author>
  <link href="https://db.gcve.eu" 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://db.gcve.eu/vuln/fkie_cve-2026-77247</id>
    <title>fkie_cve-2026-77247</title>
    <updated>2026-09-30T21:11:05.257972+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, Jira and Confluence upload tools interpret caller-controlled path arguments on the MCP server and open those files before sending them as attachments. In remote or multi-user deployments, a permitted client can disclose host files without shell or direct filesystem access. The advisory traces the vulnerable input and processing flow through AttachmentsMixin.upload_attachment, AttachmentsMixin.upload_attachments, file_path, file_paths, and jira update_issue, 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://db.gcve.eu/vuln/fkie_cve-2026-77247"/>
  </entry>
  <entry>
    <id>https://db.gcve.eu/vuln/ghsa-f6pj-qv47-g96w</id>
    <title>GHSA-f6pj-qv47-g96w — MCP Atlassian: Arbitrary server-local file upload to Jira/Confluence attachments via unrestricted file_path parameters</title>
    <updated>2026-09-30T21:11:05.258139+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 Jira and Confluence attachment upload tools accept caller-controlled file path parameters and read those paths from the MCP server's local filesystem before uploading the file as an Atlassian attachment.</p>
<p>In local `stdio` deployments, this can expose files readable by the user's MCP process. In documented HTTP/SSE or `streamable-http` deployments, the impact is higher: any MCP client that is allowed to invoke write/upload tools can cause the server process to read a server-local file and upload it to Jira or Confluence.</p>
<p>This is not dependent on an AI prompt injection or model behavior. It can be triggered deterministically with a normal MCP tool call.</p>
<p>## Details</p>
<p>The vulnerable behavior exists because upload tool arguments are treated as server-local filesystem paths.</p>
<p>Relevant implementation points:</p>
<p>- `mcp_atlassian.confluence.attachments.AttachmentsMixin.upload_attachment`
  - Accepts `file_path`.
  - Converts the supplied value to an absolute path when needed.
  - Checks existence with `os.path.exists`.
  - Passes the path into the attachment upload flow.</p>
<p>- `mcp_atlassian.confluence.attachments.AttachmentsMixin._upload_attachment_direct`
  - Opens the supplied `file_path` with `open(file_path, "rb")`.
  - Sends the resulting file object as multipart form data to Confluence.</p>
<p>- `mcp_atlassian.confluence.attachments.AttachmentsMixin.upload_attachments`
  - Iterates caller-supplied `file_paths`.
  - Calls `upload_attachment` for each path.</p>
<p>- `mcp_atlassi…</p></div>
    </content>
    <link href="https://db.gcve.eu/vuln/ghsa-f6pj-qv47-g96w"/>
  </entry>
</feed>
