Three critical flaws disclosed in MCP Atlassian server

Three critical security advisories for mcp-atlassian, the open-source Model Context Protocol server that connects AI agents to Jira and Confluence, were published on 22 September 2026. The package is maintained by the GitHub user sooperset and distributed on PyPI. Together the advisories describe arbitrary file reads from the server, unrestricted uploads of server-local files to Atlassian, and a bypass of the project's server-side request forgery protection. One advisory states that no patched version existed at the time of disclosure.

The most serious issue, tracked as CVE-2026-77262, concerns the confluence_upload_attachment tool. According to the advisory, the file_path argument supplied by the calling client is passed straight to Python's open() call with no path validation, so any file readable by the server process can be read and streamed into a multipart upload aimed at a Confluence host the attacker also controls. The reporter gives a CVSS 3.1 score of 9.3 for the default deployment, because the default streamable-http transport binds to 0.0.0.0 with no built-in authentication. Listed examples of exposed data include /etc/passwd, AWS credential files, SSH private keys, .env files and Kubernetes service-account tokens.

The advisory describes this as the read-side twin of an earlier flaw, GHSA-xjgw-4wvw-rgm4 or CVE-2026-27825, which was fixed in version 0.17.0. That fix added a validate_safe_path() check to the download path but left the upload path unguarded, so affected versions are given as 0.17.0 up to the current head of the main branch. The reporter says the issue was reproduced twice end to end against a local HTTP stub standing in for the Confluence API, driven by a real MCP client running unmodified server code, and that the stub captured the contents of /etc/passwd and /etc/hostname.

A second advisory, CVE-2026-77247, covers the broader design of the Jira and Confluence attachment upload tools. Both accept caller-controlled file paths and read them from the MCP server's own filesystem using the server process's privileges. The advisory notes that this needs no prompt injection or model misbehaviour: a normal tool call is enough. In HTTP, SSE or multi-user deployments, it says, any client permitted to invoke an upload tool can cause server-local files to be uploaded as Jira or Confluence attachments without shell or filesystem access to the host. The reporter recommends denying server-local uploads by default in multi-user deployments, restricting uploads to an allowlisted directory after resolving real paths, and rejecting UNC paths and file:// URLs.

The third advisory, CVE-2026-77274, reports an SSRF bypass in validate_url_for_ssrf(), tested against version 2.14.5. A URL of the form http://127.0.0.1:6666\@www.baidu.com is parsed by Python's urlparse as pointing to www.baidu.com, so validation passes, while the requests library sends the actual request to the loopback address. The advisory attributes the flaw to a parser mismatch between the validation step and the code that makes the request, and says an attacker who can set the X-Atlassian-Jira-Url or X-Atlassian-Confluence-Url header can reach loopback or internal services.