CVE-2026-77244: MCP Atlassian's HTTP transport accepts any token and acts with the operator's Jira and Confluence account
Before 0.22.0, mcp-atlassian's HTTP transport accepts any non-empty token, and requests without a real user identity fall back to the operator's configured Jira or Confluence credentials. Anyone who can reach the MCP endpoint can read and write Jira and Confluence as the operator.
What it is
AtlassianOpaqueTokenVerifier.verify_token() accepts any non-empty string as a valid token, and the OAuth proxy auth provider is off by default, so the HTTP transport doesn't challenge requests.
When a request has no per-user token, fetcher construction falls back to the globally configured JIRA_USERNAME/JIRA_API_TOKEN or CONFLUENCE_USERNAME/CONFLUENCE_API_TOKEN, which is the documented quickstart setup. A network client can then call any Atlassian tool with the operator's permissions.
CVE-2026-77254 (GHSA-vc8m-84rp-53hx) describes the same flow through the streamable-http transport and is fixed in the same release.
How to check
- Affected: mcp-atlassian (PyPI) before 0.22.0 running with an HTTP transport (SSE or streamable-http) and server-side Atlassian credentials.
- Check whether the MCP port is reachable from anything other than localhost.
How to fix
- Upgrade mcp-atlassian to 0.22.0 or later.
- Until then, run it over stdio or keep the HTTP endpoint behind a proxy that enforces authentication, and rotate the Atlassian API token if the endpoint was exposed.
pip show mcp-atlassian | grep -i version