MCP Atlassian CVE-2026-77268

Requires an attacker with an existing LOCAL presence (a separate user account or a co-resident process) on the host running MCP Atlassian, AND the OAuth fallback token directory ~/.mcp-atlassian plus oauth-<client_id>.json must have been created with group- or world-readable permission bits (i.e. a permissive process umask, not owner-only 0600/0700 modes). Exploitation is limited to deployments using OAuth token-file fallback on a multi-user or multi-process host; single-user hosts with a restrictive umask are not exposed. No network access, no user interaction, and no Atlassian credentials are needed beyond reading the file - the stolen refresh token itself provides continued Atlassian access. Not exploitable remotely and not against a single-tenant default deployment.

This is a genuinely low-to-moderate priority local information-disclosure issue that the vendor CVSS (5.5, CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:N/A:N) captures accurately. The AV:L attack vector is the dominant limiting factor: exploitation requires an attacker who is ALREADY a local user or process on the same host running the MCP Atlassian server, plus a permissive umask/directory mode that leaves ~/.mcp-atlassian and oauth-<client_id>.json group- or world-readable. There is no EPSS score, no CISA KEV listing, and no public exploit - so exploitation status is 'no public exploit identified at time of analysis.' The signals are internally consistent (local, low-complexity, requires an existing foothold, confidentiality-only), so there is no CVSS-vs-description conflict to flag. The one place I diverge from the vendor is impact scope: the leaked artifact is a refresh+access token that grants a full reusable Atlassian session, so downstream integrity impact on Atlassian data is plausible (I lean C:H/I:L), but the primary vulnerability is disclosure. Overall this is a defense-in-depth hardening fix, not an urgent remotely-exploitable flaw - real priority is low absent a multi-user host with an existing local adversary.

On a shared or multi-tenant host running MCP Atlassian with a permissive umask, a second local user (or a compromised low-privilege process) reads the world/group-readable ~/.mcp-atlassian/oauth-<client_id>.json, extracts the access_token and refresh_token, and replays them to impersonate the victim's authenticated Atlassian (Confluence/Jira) session. No public proof-of-concept is available, and exploitation requires prior local access plus a non-default permission bit, consistent with the AV:L/PR:L/AC:L vector.