MCP Atlassian CVE-2026-77256

Requires the MCP Atlassian server (<0.22.0) to run on a multi-user/shared host AND the process umask to be permissive enough that the OAuth fallback token file (containing refresh + access tokens) is created group- or world-readable. The attacker must already have a separate local account on that host; there is no network vector despite the vendor's AV:N. Exploitation is limited to environments where the OAuth fallback-file storage path is actually used and other untrusted local users share the machine - single-user or properly-umasked deployments are not exposed. Impact persists via the refresh token even after credential rotation, which is the key limiting-yet-aggravating factor for defenders.

This is a local, multi-user token-exposure flaw (CWE-732) in the sooperset MCP Atlassian server: the plaintext OAuth fallback file holding refresh and access tokens is created with permissions inherited from the process umask, so a permissive or default umask leaves it world- or group-readable to other local accounts. The vendor CVSS 4.0 vector (8.3, AV:N/AC:L/PR:L/UI:N/VC:H/SC:H) overstates real-world risk: it labels the vector as Network (AV:N) and asserts a subsequent-system scope change (SC:H), but the description is unambiguous that the exploit requires OTHER LOCAL USERS on the same host to read the on-disk backup - this is local access, not network. A more defensible base score is ~6.1 (AV:L/PR:L/S:U, confidentiality-dominant). There is no EPSS score, no CISA KEV listing, and no public exploit code, so exploitation status is 'no public exploit identified at time of analysis.' Realistic priority is MODERATE-and-conditional: the impact (durable Atlassian access via a stolen refresh token, surviving password changes) is meaningful, but it is entirely gated on a shared/multi-tenant host with a permissive umask - not a default-config remote-unauth scenario. Treat the headline 8.3 as inflated; prioritize on the basis of whether the MCP server runs on a shared host.

On a shared or multi-tenant host running the MCP Atlassian server, an unprivileged local user lists the OAuth fallback file whose permissions were left group/world-readable by a permissive umask, reads the stored refresh and access tokens, and replays the refresh token to obtain fresh Atlassian access as the operator's identity - retaining Confluence/Jira access even after the operator rotates their password. No public exploit code exists; the 'attack' is a simple file read requiring only an existing local account.