SURIQ
An AI helper that can file a Jira ticket for you can also be talked into handing over the keys to the server it runs on. Two advisories, one for the Confluence upload tool and one covering the server-side read across both apps, published on July 10, 2026 describe exactly that in mcp-atlassian, one of the more widely used open-source bridges between AI assistants and Atlassian's Jira and Confluence. The attachment-upload tools take a file path from the caller and open it on the server. Point that path at the process environment or a private SSH key, and the tool reads the file and ships it out as an attachment. Both issues are rated high, CVSS 7.7, and both are fixed in version 0.22.0.
The detail that decides whether this touches you is the transport. Run mcp-atlassian locally over standard input and output for a single user, and the server already runs as you, so reading your own files is the job, not a bug. The exposure appears the moment the tool is served over a network, streamable HTTP or server-sent events, or shared across tenants. There, the path the client supplies resolves on the server rather than the caller's machine, so a remote client reads the host's files, and in a multi-tenant setup, another tenant's data.
What actually broke
MCP, the Model Context Protocol, is the wiring that lets an AI assistant call real tools: read a Confluence page, comment on a Jira issue, attach a file. mcp-atlassian is one such server, and its upload tools were written for a different threat model than the one they run in. They assume the caller is attaching a file from the caller's own machine, so they accept a file_path and pass it to open(file_path, "rb"). The only handling is os.path.abspath(), which tidies the string but enforces no boundary. Over a remote transport the client has no way to send file bytes instead of a path, so the server reads whatever the path names and uploads the result.
The advisories flag three tools carrying the flaw:
confluence_upload_attachmentandconfluence_upload_attachments, which attach a file to a Confluence page.jira_update_issue, through its attachment parameter, which attaches a file to a Jira issue.
All three are corrected in 0.22.0. There is no CVE assigned to either advisory yet, and neither is disputed or withdrawn.
The part worth sitting with: no attacker login required
The reporter's proof of concept reads the server's environment and an SSH private key directly, which already assumes a client that can call the tools. The sharper version needs no such access. The reporter embedded instructions inside a Jira ticket telling the agent to call the upload tool with a sensitive server path. An assistant that reads that ticket as part of its normal work follows the text and exfiltrates the file, with none of the attacker's own credentials involved. The trigger is not a login. It is an agent that acts on attacker-controlled words.
We have now covered this shape enough times to call it a class. A public GitHub issue that made an AI agent leak a private repository. A test app that hijacked the agent testing it. A clean repo that turned a coding agent into a reverse shell. A rigged container image that seized root through Docker's agent tools. Each is a different bug. The common root is that a tool is only as trustworthy as the least-trusted text the agent feeds it.
A smaller lesson lives in the code
The same file already had the right guard. The download path calls validate_safe_path() before it touches disk. Upload never got the call. One side of the read boundary was hardened and the mirror side was left open, which is how path-handling bugs usually survive a first pass. When you patch one direction of file input or output, audit the other the same day, because the author who missed it once tends to miss it symmetrically.
How would you know if it happened
Because the stolen data leaves as an attachment, the tell is in Atlassian, not on the host. Hunt for attachment uploads from the account the MCP server authenticates as that do not match its normal behavior: files posted to pages or issues no human touched, attachments whose contents look like an environment dump or key material, or a burst of uploads right after the agent processed an externally submitted ticket. On the host itself, the server process opening paths like the process environment, anything under a user's .ssh directory, or files under /etc is worth an alert on its own, since a Jira-and-Confluence connector has no honest reason to read them.
What to do now
- Upgrade to 0.22.0. It is the one-line fix, applied.
- If you cannot upgrade today and you serve the tool remotely, stop. Bind it to single-user standard input and output, or put it behind authentication you control and trust.
- Run the server with the least the job needs. It should not be able to read host secrets, SSH keys, or an environment full of credentials in the first place. Put it in a container with a minimal filesystem and no host secrets mounted.
- Treat every ticket, page, and comment the agent ingests as untrusted input. The prompt-injection path needs no attacker credentials, only an agent that acts on attacker-controlled text.
None of the pieces here are exotic. A path with no boundary check, a tool built for one threat model and deployed under another, an agent that trusts its inputs. That combination will keep producing advisories for as long as we bolt file-touching tools onto assistants and hang them off the open web. Patch this one today, then go look at the other MCP servers you run for the same shape.