MCP Atlassian EUVD-2026-84743

Exploitable only when mcp-atlassian is run with the HTTP streamable-http transport, configured with globally-shared operator Jira/Confluence credentials, and exposed to network callers WITHOUT an independent external authentication boundary (e.g. no auth reverse-proxy/gateway and no enforced per-user OAuth identity) - the advisory's explicit 'unless the deployment has an independent authentication boundary' clause. Under that configuration exploitation is remote, unauthenticated, and low-complexity (AV:N/AC:L/PR:N/UI:N). Limiting factors that reduce real-world risk: stdio-transport deployments are unaffected, a fronting authentication proxy or per-user token enforcement neutralizes it, and the impact is bounded by the permissions of the configured operator service account. Versions before 0.22.0 are affected; upgrading to 0.22.0 remediates.

This is the root missing-authentication flaw (CWE-306) of the sooperset/mcp-atlassian PR#1448 hardening batch, and it is the most severe in real terms: the CVSS vector CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:N (9.1) indicates fully remote, unauthenticated, low-complexity exploitation with high confidentiality and integrity impact (read AND write to Jira/Confluence) and no availability impact. Vendor scoring is internally consistent with the description. No EPSS score, CISA KEV entry, or public POC is present in the provided data, so the SSVC picture is 'no public exploit identified at time of analysis' - meaning this is a high-severity latent exposure rather than a confirmed mass-exploited bug. The single most important nuance, stated plainly in the advisory, is the gating clause 'unless the deployment has an independent authentication boundary': the flaw is only exploitable when the HTTP streamable-http endpoint is exposed WITHOUT a fronting auth proxy/gateway AND the server is configured with global operator Jira/Confluence credentials. Where that misconfiguration exists this is a genuine priority (unauthenticated operator-level access to a corporate Atlassian tenant); where a reverse-proxy auth boundary or per-user OAuth is enforced, real-world risk drops sharply. Note this is functionally a near-twin of CVE-2026-77244 (same auth-bypass root, same commit b0417334) which the vendor scored 10.0 with S:C; here S:U caps it at 9.1 - the scope-change disagreement is the main discrepancy to reconcile with the vendor.

An operator deploys mcp-atlassian in HTTP (streamable-http) mode with globally configured Jira/Confluence service-account credentials and exposes the MCP endpoint on the network without a fronting authentication proxy. An unauthenticated network attacker who can reach the endpoint sends MCP tool-call requests carrying no per-user identity; UserTokenMiddleware permits them and _get_fetcher falls back to the global operator credentials, letting the attacker read and modify any Jira issue or Confluence page the operator account can access. No public exploit code is identified at time of analysis, but the attack requires no special tooling given AV:N/AC:L/PR:N.