Summary
MCP Atlassian: OAuth fallback token storage writes plaintext access and refresh tokens with group-readable permissions
Advisory details
Summary
When OAuth tokens are saved, MCP Atlassian always writes a plaintext fallback copy under ~/.mcp-atlassian/oauth-<client_id>.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._save_tokens() stores OAuth token data in keyring, but it also unconditionally maintains a plaintext file fallback for backwards compatibility in src/mcp_atlassian/utils/oauth.py:350-386. If keyring saving fails it also falls back to the same file path in src/mcp_atlassian/utils/oauth.py:387-391.
The fallback writer creates ~/.mcp-atlassian and then writes oauth-<client_id>.json with a normal open(token_path, "w") call in src/mcp_atlassian/utils/oauth.py:392-420. No mode=0o600, os.open(..., 0o600), chmod, or owner-only directory permission is applied. The file contains both access_token and refresh_token (src/mcp_atlassian/utils/oauth.py:360-367) and is later loaded from the same plaintext path in src/mcp_atlassian/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.
uv run python - <<'PY'
import json, os, shutil, stat, tempfile
from pathlib import Path
from unittest.mock import patch
from mcp_atlassian.utils.oauth import OAuthConfig
home = tempfile.mkdtemp(prefix='mcp-atlassian-oauth-poc-')
old_home = os.environ.get('HOME')
os.environ['HOME'] = home
try:
cfg = OAuthConfig(client_id='poc-client', client_secret='client-secret', redirect_uri='http://localhost/callback', scope='offline_access', cloud_id='cloud-id')
cfg.access_token = 'poc-access-token'
cfg.refresh_token = 'poc-refresh-token'
cfg.expires_at = 2000000000
with patch('keyring.set_password', return_value=None):
cfg._save_tokens()
token_file = Path(home) / '.mcp-atlassian' / 'oauth-poc-client.json'
mode = stat.S_IMODE(token_file.stat().st_mode)
data = json.loads(token_file.read_text())
print(json.dumps({
'token_file_exists': token_file.exists(),
'token_file_mode_octal': oct(mode),
'contains_access_token': data.get('access_token') == 'poc-access-token',
'contains_refresh_token': data.get('refresh_token') == 'poc-refresh-token',
'token_file_path': str(token_file),
}, indent=2, sort_keys=True))
finally:
if old_home is not None:
os.environ['HOME'] = old_home
else:
os.environ.pop('HOME', None)
shutil.rmtree(home)
PY
Observed output from this environment:
{
"contains_access_token": true,
"contains_refresh_token": true,
"token_file_exists": true,
"token_file_mode_octal": "0o664",
"token_file_path": "/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.
References
- https://github.com/advisories/GHSA-g5xv-mhgm-v5f6
- https://github.com/sooperset/mcp-atlassian/security/advisories/GHSA-g5xv-mhgm-v5f6
- https://nvd.nist.gov/vuln/detail/CVE-2026-77250
- https://github.com/sooperset/mcp-atlassian/pull/1448
- https://github.com/sooperset/mcp-atlassian/commit/b041733473f95119dd539542a43c280737a8e460
- https://github.com/sooperset/mcp-atlassian/releases/tag/v0.22.0
Related vulnerabilities
All Supply chain →- MEDIUMCVE-2026-91982
Vikunja: TOTP secret is readable after enrollment, no step-up auth
- HIGHCVE-2026-62376
Vikunja: Plaintext storage of password-reset/email-confirm tokens in database enables account takeover on DB read access
- HIGHCVE-2026-107807
Nginx UI: Node Secret Credential Exposure via URL Query Parameter
- MEDIUMCVE-2026-63406
AnyCable: Telemetry Subsystem Contains Hardcoded Authentication Token and Transmits CLI Arguments Including Secrets
- HIGHSC-ARTIPACKED-2024
On August 13, 2024, Palo Alto Networks Unit 42 published ArtiPACKED, a widespread CI/CD misconfiguration class in which GitHub Actions build artifacts inadvertently leaked authentication tokens, affecting major open-source projects from Google, Microsoft, Red Hat, AWS, Canonical, and OWASP. The root cause is that actions/checkout persists credentials by default, writing the workflow's GITHUB_TOKEN into the checked-out .git/config for authenticated Git operations; when a later step uploaded the workspace (test results, build output, or the full checkout directory) via actions/upload-artifact, the .git directory and its embedded token, along with environment-derived secrets and cloud credentials, were packaged into the downloadable artifact. Because v4 artifacts can be downloaded while the run is still in progress and are readable by anyone for public repositories, an attacker could win a race condition: download the artifact, extract the still-valid GITHUB_TOKEN before the job completed and the token expired, and use it to push code, create branches, or pivot into connected cloud environments. Unit 42 identified numerous large projects leaking tokens this way and disclosed each responsibly for remediation.
- HIGHCVE-2026-96627
Arcane: Delegated users:update permission allows admin account takeover via password reset (no privilege-hierarchy check)