MCP Atlassian EUVD-2026-84619

Requires: (1) an attacker with an existing local account or local process on the same host running mcp-atlassian; (2) a permissive umask so that OAuthConfig._save_tokens writes ~/.mcp-atlassian/oauth-<client_id>.json readable by same-group or other users (process-default permissions, no explicit 0600 restriction pre-0.22.0); and (3) that the OAuth plaintext-fallback token file has actually been created (OAuth flow used rather than keyring/env-only). It is NOT remotely exploitable and NOT exploitable on a single-user host with a restrictive default umask (e.g. 0077). The impact of disclosure extends to durable Atlassian access because the refresh_token is stored, enabling token renewal beyond the initial access_token lifetime.

This is a genuinely LOW-priority issue despite the CVSS 6.1 (Medium) rating. The CVSS vector CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:L/A:N confirms a purely LOCAL attack vector requiring existing low-privilege access to the host - this is not remotely exploitable. No EPSS score, no CISA KEV listing, and no public exploit code are present, so exploitation status is 'no public exploit identified at time of analysis.' The high confidentiality impact (C:H) is real - plaintext OAuth access AND refresh tokens are disclosed, granting durable reuse of the victim's Atlassian access - but it is entirely gated behind two non-default preconditions: a permissive umask on the host AND a shared/multi-user system where another local account or process can read the file. There is no signal conflict, but note the CVSS itself is vendor/GitHub_M-assigned (GitHub_M advisory), not NVD-analyzed, and the I:L rating reflects downstream Atlassian token reuse rather than direct integrity impact on the host. On a single-user workstation with a default umask this is effectively non-exploitable, which is why the practical priority is low even though token compromise sounds severe.

On a shared Linux host running mcp-atlassian under an operator account with a permissive umask (e.g. 0022 or looser), the server persists a fallback token file at ~/.mcp-atlassian/oauth-<client_id>.json with world- or group-readable permissions. A second local user or a co-tenant process reads the file, extracts the plaintext access_token and refresh_token, and reuses them to impersonate the operator's Confluence/Jira access. No public exploit code is required - reading a readable file is trivial once local access exists.