CVE-2026-77250: MCP Atlassian: OAuth fallback token storage writes plaintext access and refresh tokens with group-readable permissions
Summary
When OAuth tokens are saved, MCP Atlassian always writes a plaintext fallback copy under ~/.mcp-atlassian/oauth-<clientid>.json. The fallback file is created with the process default umask rather than restrictive permissions. In this environment the file was created as mode 0664, exposing access and refresh tokens to same-group local users and any process that can read the home directory.
Details
OAuthConfig.savetokens() stores OAuth token data in keyring, but it also unconditionally maintains a plaintext file fallback for backwards compatibility in src/mcpatlassian/utils/oauth.py:350-386. If keyring saving fails it also falls back to the same file path in src/mcpatlassian/utils/oauth.py:387-391.
The fallback writer creates ~/.mcp-atlassian and then writes oauth-<clientid>.json with a normal open(tokenpath, "w") call in src/mcpatlassian/utils/oauth.py:392-420. No mode=0o600, os.open(..., 0o600), chmod, or owner-only directory permission is applied. The file contains both accesstoken and refreshtoken (src/mcpatlassian/utils/oauth.py:360-367) and is later loaded from the same plaintext path in src/mcpatlassian/utils/oauth.py:450-470.
The security policy warns that OAuth client credentials and secrets should not be exposed (SECURITY.md:39-44), but the current implementation creates a persistent plaintext token copy even when keyring succeeds.
PoC
The following safe local proof uses a temporary HOME and mocked keyring writes. It creates and deletes only temporary files.
bash uv run python - <<'PY' import json, os, shutil, stat, tempfile from pathlib import Path from unittest.mock import patch from mcpatlassian.utils.oauth import OAuthConfig
home = tempfile.mkdtemp(prefix='mcp-atlassian-oauth-poc-') oldhome = os.environ.get('HOME') os.environ['HOME'] = home try: cfg = OAuthConfig(clientid='poc-client', clientsecret='client-secret', redirecturi='http://localhost/callback', scope='offlineaccess', cloudid='cloud-id') cfg.accesstoken = 'poc-access-token' cfg.refreshtoken = 'poc-refresh-token' cfg.expiresat = 2000000000 with patch('keyring.setpassword', returnvalue=None): cfg.savetokens() tokenfile = Path(home) / '.mcp-atlassian' / 'oauth-poc-client.json' mode = stat.SIMODE(tokenfile.stat().stmode) data = json.loads(tokenfile.readtext()) print(json.dumps({ 'tokenfileexists': tokenfile.exists(), 'tokenfilemodeoctal': oct(mode), 'containsaccesstoken': data.get('accesstoken') == 'poc-access-token', 'containsrefreshtoken': data.get('refreshtoken') == 'poc-refresh-token', 'tokenfilepath': str(tokenfile), }, indent=2, sortkeys=True)) finally: if oldhome is not None: os.environ['HOME'] = oldhome else: os.environ.pop('HOME', None) shutil.rmtree(home) PY
Observed output from this environment:
json { "containsaccesstoken": true, "containsrefreshtoken": true, "tokenfileexists": true, "tokenfilemodeoctal": "0o664", "tokenfilepath": "/tmp/mcp-atlassian-oauth-poc-9m9wvktp/.mcp-atlassian/oauth-poc-client.json" }
The proof confirms that a plaintext file containing both access and refresh tokens is created and is not owner-only.
Impact
A local user, container sidecar, compromised dependency, backup job, or other process with filesystem read access to the account's home directory can recover OAuth access and refresh tokens. Refresh tokens can allow continued Atlassian API access until revoked or expired, depending on the OAuth app and token policy. In shared hosts, Kubernetes volumes, developer workstations, and CI runners, this can lead to persistent Atlassian account compromise.
Other sources
MCP Atlassian is a Model Context Protocol (MCP) server for Atlassian products (Confluence and Jira). Prior to 0.22.0, OAuthConfig writes a plaintext fallback file containing access and refresh tokens under the user's .mcp-atlassian directory using process-default permissions. On systems with a permissive umask, same-group or other local users and processes can read the persisted tokens and reuse the associated Atlassian access. The advisory traces the vulnerable input and processing flow through OAuthConfig.savetokens, ~/.mcp-atlassian/oauth-<clientid>.json, accesstoken, and refreshtoken, which identify the affected entry points, controls, and code paths. This issue is fixed in version 0.22.0.
— MITRE
Affected Software
Remediation
Recommended actions to resolve this vulnerability, in priority order.
- Upgrade
Upgrade
pip/mcp-atlassianto a version that resolves this vulnerability.Fixed in 0.22.0 - Upgrade
Upgrade
MCP Atlassianto a version that resolves this vulnerability.Fixed in 0.22.0
Event History
Frequently Asked Questions
Who can exploit this issue?
A same-group or other local user or process may be able to exploit it if the system's umask causes the OAuth fallback token file to be created with group-readable or otherwise permissive permissions. The attacker needs local access and permission to read the persisted file.
What credentials are exposed if the vulnerable fallback file is readable?
The file contains plaintext OAuth access_token and refresh_token values. A reader can reuse the associated Atlassian access.
How can I determine whether an installation is affected?
Installations running a version earlier than 0.22.0 are affected when OAuthConfig has written a fallback file at ~/.mcp-atlassian/oauth-<client_id>.json and that file has permissive permissions. Check the file's permissions and whether it contains access_token and refresh_token fields.
What should be done if upgrading is not immediately possible?
Restrict access to the affected OAuth fallback files under ~/.mcp-atlassian so that other local users and groups cannot read them. Because the tokens are stored in plaintext, treat tokens in files that were readable by others as potentially exposed.