Published: 2026-09-29

29 CVEs for mcp-atlassian: what Jira and Confluence users should do now

In short: on 22 September 2026, 29 CVE records were published for mcp-atlassian, the most popular community MCP server for Jira and Confluence. They include two critical flaws that let unauthenticated requests over the HTTP transport use the server's Atlassian credentials. Update to at least version 0.23.1, which also closes a later critical flaw in the SSE transport.

mcp-atlassian (GitHub: sooperset/mcp-atlassian) is not an Atlassian product. It is an open-source project with close to 6,000 stars on GitHub. It is especially popular with organisations that self-host Jira or Confluence, because Atlassian's own remote MCP server is aimed at Atlassian Cloud customers. That is where this unusually large batch of vulnerabilities now lands: internal Jira environments holding sensitive projects.

What exactly was disclosed?

The project's security page lists 36 advisories. Of these, 33 were published together on 10 July 2026, alongside version 0.22.0, which fixes them: 2 critical, 19 high and 12 medium. GitHub, acting as CVE numbering authority, published most of the matching CVE records on 22 September. That is why they are only now showing up in vulnerability databases.

Both critical flaws concern authentication in the HTTP transport:

CVE-2026-77254 (CVSS 9.1): a POST request without an Authorization header was let through and fell back to the globally configured Jira and Confluence credentials. By default the HTTP server listened on all network interfaces (0.0.0.0), so anyone who could reach the endpoint could call tools with the service account's permissions.
CVE-2026-77244 (CVSS 10.0): token verification accepted any non-empty string as a valid token. In the documented quickstart setup, with a single set of credentials in environment variables, that meant unauthenticated access.

The largest cluster sits in the attachment upload tools. By supplying its own file_path, an MCP client could read arbitrary files from the server and upload them to Jira or Confluence as attachments, including files containing API tokens. The advisory for CVE-2026-73498 describes an AI agent being tricked by untrusted content into calling that tool. Other advisories cover SSRF, bypasses of the project and space filters, and OAuth tokens written to disk with overly broad permissions.

One more followed later. On 19 August 2026 a critical advisory (CVSS 10.0) was published for the SSE transport: the authentication middleware did not recognise the SSE paths and let every request through. It affects versions up to and including 0.23.0 and is fixed in 0.23.1. If you moved to 0.22.0 in July, you are not done yet.

Why so many flaws in a single project?

A striking number of the advisory titles include "incomplete fix". They cover attempts to close earlier flaws from February 2026: CVE-2026-27825 (code execution via a write path, CVSS 9.0) and CVE-2026-27826 (SSRF via headers, CVSS 8.2). CVE-2026-77271, for example, shows that the path validation added in version 0.17.0 used the working directory as its boundary. In a container, that is the application directory, so an attacker could overwrite the server's own Python modules.

Our analysis: this pattern is typical of a project that started as a local, single-user tool and grew into a multi-user network service. A local server that talks to one developer over stdio has a very different threat model from an HTTP endpoint on the corporate network. Nearly all the critical flaws sit in that transition: defaults that are harmless locally but leave the door open on a network.

Our advice

(1) Find every place mcp-atlassian runs, including developer laptops, and check the version. Anything below 0.23.1 needs updating. (2) If you run it over HTTP or SSE, treat this as an incident rather than a routine patch: review the service account's activity in Jira and Confluence for unexpected attachment uploads and searches, and rotate the API tokens. (3) Limit the service account to the projects and spaces the agent actually needs. The built-in filters turned out to be bypassable, so permissions in Atlassian itself are the real boundary. (4) On Atlassian Cloud, consider Atlassian's official server instead. A community server is not unsafe by definition, but maintaining it belongs on your patch calendar. More in our guide to MCP security & watchouts and the overview of MCP servers for productivity & collaboration.

What does this mean for MCP more broadly?

The protocol is not at fault here: these are implementation flaws in one server. But after the LiteLLM flaw in September, this is the second major case in a short time where an MCP endpoint with missing or overly permissive authentication is at the heart of the problem. The 28 July 2026 specification revision tightens the authorization requirements. That only helps if servers actually enforce them, and with a self-hosted community server, that responsibility falls first and foremost on your own organisation.

Sources

Frequently asked questions

Am I vulnerable if I use mcp-atlassian?

Versions before 0.22.0 contain the 33 flaws disclosed in July; versions up to and including 0.23.0 also contain a critical authentication flaw in the SSE transport. Update to at least 0.23.1. The highest risk applies to deployments that expose the server over HTTP or SSE on a network.

Does this affect Atlassian's official MCP server (Rovo)?

No. mcp-atlassian is a community project (sooperset/mcp-atlassian), independent of Atlassian. The advisories only concern that project, not Atlassian's own remote MCP server.

Why are CVEs appearing now if the fixes shipped in July?

The advisories were published on 10 July 2026 alongside version 0.22.0; the corresponding CVE records were published on 22 September. From that point on, tools that rely on CVE data can flag the old versions as vulnerable.

Last updated: 2026-09-29