TL;DR

mcp-atlassian (sooperset) is the most widely deployed Model Context Protocol server for Jira and Confluence — ~161K PyPI downloads a week, 4M+ all-time. On 2026-07-10 the maintainer shipped 0.22.0, a "comprehensive security audit" that closed 37 advisories at once. Those advisories carried no CVE ids at the time; on 2026-09-22 GitHub (as CNA) assigned a block of 26 CVEs (CVE-2026-77243 through CVE-2026-77274, plus the two February ids CVE-2026-27825/-27826) and pushed them into the advisory database, which is why the server reappears across every recency-sorted sweep this week looking like a fresh wave. It is not: everything here is fixed in 0.22.0 (with follow-on hardening in 0.22.1 / 0.23.0 / 0.23.1; current release 0.23.1, 2026-08-19). The one entry that must not be missed is CVE-2026-77244 (CVSS 10.0): in HTTP transport the token verifier accepts any non-empty string, and when no auth provider is built the server falls back to the operator's globally configured Jira/Confluence credentials — an unauthenticated network client gets full operator-level Jira/Confluence access. If you patched to ≥ 0.22.0 in July you are done; if you are still on an older HTTP-transport deployment, this is the reason to upgrade today. This repo already tracked one member of the July batch (CVE-2026-73498) in the MCP CVE batch and the February MCPwnfluence pair (CVE-2026-27825/-27826) in the stdio systemic-RCE advisory; this file is the full September CVE assignment.

What happened

A July fix, a September CVE block. The maintainer's 0.22.0 release notes describe resolving 37 advisories: "path confinement for attachments/content files; HTTP transport authentication boundary enforcement; SSRF hardening with DNS-pinning; tool authorization enforcement; filter boundary protection; OAuth token file permissions (0600); and reflected XSS prevention." All 37 were published as GitHub Security Advisories on 2026-07-10 with severity labels but no CVE numbers. GitHub assigned CVEs to 26 of them on 2026-09-22 and the advisory database mirrored them the same day. Per this repo's standing rule, a database-publication date is not a disclosure date — the disclosure and the fix are both July; the CVEs are a late-assigned identifier layer. NVD confirms CVE-2026-77244 was published 2026-09-22 by GitHub with the vendor commit, PR #1448 and the v0.22.0 tag as references.

The classes, and what each lets an attacker do. The 26 CVEs collapse into the four failure modes this repo has documented across ~30 MCP servers — an HTTP surface that is open by default, a path argument that isn't confined, an SSRF guard that isn't applied on every branch, and an authorization check enforced at list time but not at call time:

CVE CVSS Class
CVE-2026-77244 10.0 Critical Auth bypass: AtlassianOpaqueTokenVerifier.verify_token() accepts any non-empty token; HTTP transport then falls back to global operator credentials
CVE-2026-77254 (GHSA-vc8m-84rp-53hx) 9.1 Critical Unauthenticated HTTP requests use globally configured Jira/Confluence credentials (binds 0.0.0.0, POST without Authorization passes)
CVE-2026-27825 9.0 Critical Arbitrary file write via unconstrained download_path in confluence_download_attachment → RCE on restart
CVE-2026-77243 8.8 High ENABLED_TOOLS / TOOLSETS authorization bypass: list-time filtered, call-time not — any of 73 tools invokable
CVE-2026-77248 8.6 High Unauthenticated arbitrary local file read via upload_attachment file_path
CVE-2026-77255 8.6 High Confused-deputy arbitrary file read in JIRA update_issue attachments — an agent forces the privileged MCP process to read JIRA_API_TOKEN and host secrets
CVE-2026-77247 / -77246 / -77262 8.3 / 7.4 / 8.6 Path traversal / server-local file exfiltration via attachment tools
CVE-2026-27826 8.2 High SSRF via unvalidated X-Atlassian-Jira-Url / X-Atlassian-Confluence-Url headers
CVE-2026-77274 8.2 High SSRF protection bypass
CVE-2026-77271 7.7 High Incomplete path-traversal fix → intra-CWD module overwrite → RCE (validate_safe_path() defaults to os.getcwd())
CVE-2026-77257 / -77258 / -77259 / -77260 / -77251 / -77267 7.7 High HTTP upload path acceptance, credential-exfil file reads, project/space filter authorization bypass, incomplete SSRF remediation
CVE-2026-77249 / -77253 / -77261 / -77265 / -77266 / -77268 / -77269 / -77270 / -77250 / -77272 5.3–7.1 SSRF (DNS-rebinding), moderate path traversals, insecure OAuth token file permissions, reflected XSS in the OAuth setup callback

The two Critical HTTP-transport CVEs are the ones that matter for a reader who only reads the headline: an mcp-atlassian HTTP endpoint reachable on the network before 0.22.0 is operator-level Jira/Confluence access with no credential. The confused-deputy and path-traversal reads (CVE-2026-77255, -77248, -77260) are the agent-specific ones: a prompt-injected agent, or a low-privilege MCP client, drives the privileged server process to read JIRA_API_TOKEN, host config and other secrets the agent's own sandbox would deny.

Version map (PyPI time, fetched 2026-09-23). The vulnerable range for the whole batch is < 0.22.0. Fixes and hardening: 0.22.0 (2026-07-10, the audit), 0.22.1 (2026-07-11, JQL-injection and SSRF hardening), 0.23.0 (2026-07-18, Starlette bump + FastMCP 3.x migration), 0.23.1 (2026-08-19, fixes CVE-less GHSA-5j8j-256g-vvp5 — an unauthenticated SSE-transport tool-execution bug where the auth middleware only matched /mcp, not /sse and /messages/). Current release is 0.23.1.

Am I affected?

pip show mcp-atlassian 2>/dev/null | grep -i '^version'      # < 0.22.0 = the whole batch; < 0.23.1 = also the SSE bug
pip index versions mcp-atlassian 2>/dev/null | head -1
# If you run the HTTP or SSE transport, is it reachable and does it hold global creds?
env | grep -E 'CONFLUENCE_API_TOKEN|JIRA_API_TOKEN|ATLASSIAN'   # global fallback creds = the blast radius of CVE-2026-77244/-77254
ss -tlnp 2>/dev/null | grep -E '0\.0\.0\.0|:::' | grep -i python   # bound to all interfaces?
  • Affected if: you run mcp-atlassian < 0.22.0, and especially if its --transport streamable-http / --transport sse listener is reachable beyond loopback with CONFLUENCE_API_TOKEN / JIRA_API_TOKEN set — that is unauthenticated operator access (CVE-2026-77244, 10.0).
  • Not affected / already fixed if: you upgraded to ≥ 0.22.0 in July (all 26 CVEs) — go to 0.23.1 to also close the August SSE bug. stdio-transport-only local use was never exposed to the network CVEs but was to the path-traversal file reads.

If you are affected

  • Upgrade to 0.23.1 now; there is no partial fix. If you cannot upgrade immediately, take the HTTP/SSE listener off 0.0.0.0, put it behind an authenticating proxy, and unset the global credential fallback.
  • Because the pre-0.22.0 HTTP transport could be used with the operator's Jira/Confluence token by anyone who reached it, rotate CONFLUENCE_API_TOKEN / JIRA_API_TOKEN if the listener was ever network-reachable, and review Jira/Confluence audit logs for actions you cannot attribute — rotating-cloud-credentials.md, if-an-mcp-server-was-malicious.md.

Prevention

  • Never expose an MCP server's HTTP/SSE transport on 0.0.0.0 without an auth proxy — the recurring root cause in this repo's MCP tracking. prevention/mcp-hygiene.md.
  • A "patched" version number is not the same as a CVE: this batch was fixed for two months before it had CVE ids, so a CVE-feed-only monitor would have flagged it in September while the fix had been available since July. Track the vendor's advisory tab and release notes, not just NVD. prevention/supply-chain-attack-surface.md.
  • Treat a privileged MCP server as a confused deputy: an agent that can call its tools can make it read files the agent itself cannot. Give the server the narrowest credential and filesystem scope it can run with.

Sources