https://cve.radiocsirt.org Contains only the most 10 recent entries. http://www.rssboard.org/rss-specification python-feedgen en Mon, 05 Oct 2026 22:16:00 +0000 https://cve.radiocsirt.org/vuln/bdu:2026-14794 bdu:2026-14794 https://cve.radiocsirt.org/vuln/bdu:2026-14794 https://cve.radiocsirt.org/vuln/brew-mcp-atlassian-ghsa-wm45-qh3g-v83f <p><strong>Affected:</strong> Homebrew: mcp-atlassian</p> <p>### Summary</p> <p>A client that can invoke MCP tools can read **arbitrary files from the server host** and exfiltrate them as Atlassian attachments. The attachment-upload tools take a client-supplied `file_path` and `open()` it on the **server&#39;s** filesystem.</p> <p>The upload tools are meant to attach a file from the **caller&#39;s** environment — the client supplies a path expecting it to refer to its own machine. Over a remote transport (HTTP/SSE) that path is instead resolved and read on the server, and the tool offers no way for the client to send file *content* in place of a server-side path. A remote client therefore reads the server&#39;s files — and, in multi-tenant deployments, other tenants&#39; data — instead of its own. (In a local `stdio` deployment the server runs as the user, so the path refers to the user&#39;s own files and reading any path is the intended behavior; the exposure is specific to remote/multi-user transports.)</p> <p>### Details</p> <p>The upload tools read a client-supplied path directly on the server:</p> <p>- `src/mcp_atlassian/confluence/attachments.py` — `upload_attachment` → `_upload_attachment_direct` → `os.path.abspath(file_path)` → `open(file_path, &#34;rb&#34;)` - `src/mcp_atlassian/jira/attachments.py` — `upload_attachment` → `os.path.abspath(file_path)` → `open(file_path, &#34;rb&#34;)`</p> <p>`os.path.abspath()` only normalizes the path; the file is then opened on the server wherever it points and its bytes are sent to Atlassian as an attachment. There is no path a client can use to reference its…</p> <p><strong>Affected:</strong> Homebrew: mcp-atlassian</p> <p>### Summary</p> <p>A client that can invoke MCP tools can read **arbitrary files from the server host** and exfiltrate them as Atlassian attachments. The attachment-upload tools take a client-supplied `file_path` and `open()` it on the **server&#39;s** filesystem.</p> <p>The upload tools are meant to attach a file from the **caller&#39;s** environment — the client supplies a path expecting it to refer to its own machine. Over a remote transport (HTTP/SSE) that path is instead resolved and read on the server, and the tool offers no way for the client to send file *content* in place of a server-side path. A remote client therefore reads the server&#39;s files — and, in multi-tenant deployments, other tenants&#39; data — instead of its own. (In a local `stdio` deployment the server runs as the user, so the path refers to the user&#39;s own files and reading any path is the intended behavior; the exposure is specific to remote/multi-user transports.)</p> <p>### Details</p> <p>The upload tools read a client-supplied path directly on the server:</p> <p>- `src/mcp_atlassian/confluence/attachments.py` — `upload_attachment` → `_upload_attachment_direct` → `os.path.abspath(file_path)` → `open(file_path, &#34;rb&#34;)` - `src/mcp_atlassian/jira/attachments.py` — `upload_attachment` → `os.path.abspath(file_path)` → `open(file_path, &#34;rb&#34;)`</p> <p>`os.path.abspath()` only normalizes the path; the file is then opened on the server wherever it points and its bytes are sent to Atlassian as an attachment. There is no path a client can use to reference its…</p> https://cve.radiocsirt.org/vuln/brew-mcp-atlassian-ghsa-wm45-qh3g-v83f https://cve.radiocsirt.org/vuln/euvd-2026-369706 EUVD-2026-369706 https://cve.radiocsirt.org/vuln/euvd-2026-369706 https://cve.radiocsirt.org/vuln/fkie_cve-2026-73496 <p>MCP Atlassian is a Model Context Protocol (MCP) server for Atlassian products (Confluence and Jira). Prior to 0.22.0, the confluence_upload_attachment and confluence_upload_attachments tools pass a client-controlled file_path through src/mcp_atlassian/confluence/attachments.py upload_attachment, and the jira_update_issue attachments parameter reaches src/mcp_atlassian/jira/attachments.py upload_attachment, without confining either path to an approved server workspace. In a remote HTTP, SSE, or multi-user deployment, absolute or traversing paths are resolved on the MCP server and uploaded to Atlassian, allowing a client with write-tool access to disclose server files, environment-held Atlassian credentials, or another tenant&#39;s data. A local single-user stdio deployment does not cross this trust boundary because the server runs in the caller&#39;s environment. This issue is fixed in version 0.22.0.</p> <p>MCP Atlassian is a Model Context Protocol (MCP) server for Atlassian products (Confluence and Jira). Prior to 0.22.0, the confluence_upload_attachment and confluence_upload_attachments tools pass a client-controlled file_path through src/mcp_atlassian/confluence/attachments.py upload_attachment, and the jira_update_issue attachments parameter reaches src/mcp_atlassian/jira/attachments.py upload_attachment, without confining either path to an approved server workspace. In a remote HTTP, SSE, or multi-user deployment, absolute or traversing paths are resolved on the MCP server and uploaded to Atlassian, allowing a client with write-tool access to disclose server files, environment-held Atlassian credentials, or another tenant&#39;s data. A local single-user stdio deployment does not cross this trust boundary because the server runs in the caller&#39;s environment. This issue is fixed in version 0.22.0.</p> https://cve.radiocsirt.org/vuln/fkie_cve-2026-73496 https://cve.radiocsirt.org/vuln/ghsa-wm45-qh3g-v83f <p><strong>Affected:</strong> PyPI: mcp-atlassian</p> <p>### Summary</p> <p>A client that can invoke MCP tools can read **arbitrary files from the server host** and exfiltrate them as Atlassian attachments. The attachment-upload tools take a client-supplied `file_path` and `open()` it on the **server&#39;s** filesystem.</p> <p>The upload tools are meant to attach a file from the **caller&#39;s** environment — the client supplies a path expecting it to refer to its own machine. Over a remote transport (HTTP/SSE) that path is instead resolved and read on the server, and the tool offers no way for the client to send file *content* in place of a server-side path. A remote client therefore reads the server&#39;s files — and, in multi-tenant deployments, other tenants&#39; data — instead of its own. (In a local `stdio` deployment the server runs as the user, so the path refers to the user&#39;s own files and reading any path is the intended behavior; the exposure is specific to remote/multi-user transports.)</p> <p>### Details</p> <p>The upload tools read a client-supplied path directly on the server:</p> <p>- `src/mcp_atlassian/confluence/attachments.py` — `upload_attachment` → `_upload_attachment_direct` → `os.path.abspath(file_path)` → `open(file_path, &#34;rb&#34;)` - `src/mcp_atlassian/jira/attachments.py` — `upload_attachment` → `os.path.abspath(file_path)` → `open(file_path, &#34;rb&#34;)`</p> <p>`os.path.abspath()` only normalizes the path; the file is then opened on the server wherever it points and its bytes are sent to Atlassian as an attachment. There is no path a client can use to reference its…</p> <p><strong>Affected:</strong> PyPI: mcp-atlassian</p> <p>### Summary</p> <p>A client that can invoke MCP tools can read **arbitrary files from the server host** and exfiltrate them as Atlassian attachments. The attachment-upload tools take a client-supplied `file_path` and `open()` it on the **server&#39;s** filesystem.</p> <p>The upload tools are meant to attach a file from the **caller&#39;s** environment — the client supplies a path expecting it to refer to its own machine. Over a remote transport (HTTP/SSE) that path is instead resolved and read on the server, and the tool offers no way for the client to send file *content* in place of a server-side path. A remote client therefore reads the server&#39;s files — and, in multi-tenant deployments, other tenants&#39; data — instead of its own. (In a local `stdio` deployment the server runs as the user, so the path refers to the user&#39;s own files and reading any path is the intended behavior; the exposure is specific to remote/multi-user transports.)</p> <p>### Details</p> <p>The upload tools read a client-supplied path directly on the server:</p> <p>- `src/mcp_atlassian/confluence/attachments.py` — `upload_attachment` → `_upload_attachment_direct` → `os.path.abspath(file_path)` → `open(file_path, &#34;rb&#34;)` - `src/mcp_atlassian/jira/attachments.py` — `upload_attachment` → `os.path.abspath(file_path)` → `open(file_path, &#34;rb&#34;)`</p> <p>`os.path.abspath()` only normalizes the path; the file is then opened on the server wherever it points and its bytes are sent to Atlassian as an attachment. There is no path a client can use to reference its…</p> https://cve.radiocsirt.org/vuln/ghsa-wm45-qh3g-v83f