Your RSA-2048 keys break in 2030. Find every one of them before attackers do.
🐍
🐍 PyPI
Not in CISA KEV
MEDIUM severity

CVE-2026-77250 — mcp-atlassian

MEDIUMFix: sooperset/mcp-atlassian@b041733

CVE-2026-77250 is a medium-severity (CVSS 6.1) CWE-312 vulnerability in mcp-atlassian. A fix is available for mcp-atlassian — see the affected versions and patch details below.

MCP Atlassian: OAuth fallback token storage writes plaintext access and refresh tokens with group-readable permissions

Also known asGHSA-g5xv-mhgm-v5f6PYSEC-2026-4094
Published
Updated
Affected
1 pkg
Patched
1 / 1
Exploits
None indexed
Exploitation data as of Oct 22, 2026 · OSV.dev, NVD, FIRST.org (EPSS)

Exploitation Status

Proof-of-concept exploit code exists

  • CISA’s SSVC triage found public proof-of-concept exploit code for this CVE, though no confirmed active exploitation.

Exploitation and automatability from CISA’s SSVC triage for CVE-2026-77250.

EPSS Exploitation Probability

via FIRST.org ↗
0.1%probability of exploitation in next 30 days
Lower Risk0.00%
Lower risk than most CVEs1th percentile — riskier than 1% of all scored CVEsHighest risk
0.00%0.20%0.41%0.61%0.1%0.1%Oct 26Oct 26

Probability of exploitation in the next 30 days, from FIRST.org EPSS.

How urgent is this, really

CVE-2026-77250 by exploitation likelihood (EPSS) against impact (CVSS). Outside the shaded patch-first corner.

Where this sits among everything scored

Of 394,803 CVEs with a current EPSS score, this one falls in the < 10% band (highlighted). Counts from FIRST.org, log-scaled.

Real-World Exposure

1 pkg affected
🐍mcp-atlassian

Real-time download stats are indexed for npm and PyPI packages. This vulnerability affects PyPI packages — download data is not available via public APIs for these ecosystems.

Description

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.

Affected Packages

1 total 1 fixed
EcosystemPackageVulnerable rangeFix
🐍PyPImcp-atlassianall versions0.22.0pip install --upgrade 'mcp-atlassian==0.22.0'

Affected Products

1 product · 1 configurations
Application
mcp atlassianmcp-atlassian
< 0.22.0
range

Detection & mitigation playbook

Open-source dependency
  1. Detect

    Scan your dependency tree (package-lock.json, pnpm-lock.yaml, requirements.txt, go.sum, etc.) for mcp-atlassian, including transitive dependencies — a direct dependency you never call can still pull in a vulnerable version.

  2. Fix

    Update mcp-atlassian to 0.22.0 or later, then make sure no transitive (indirect) dependency still pins the vulnerable range — O3 confirms CVE-2026-77250 is resolved across your whole dependency graph.

  3. Workarounds

    If you can't upgrade right away: gate or disable the affected feature, validate untrusted input at the boundary, and avoid passing attacker-controlled data into the vulnerable path. O3's runtime protection blocks exploitation in production as an interim safeguard until the upgrade lands.

Frequently Asked Questions

### 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_atlassi
O3 Security · Impact-Aware SCA

Is CVE-2026-77250 in your dependencies?

Find it across PyPI, including transitive dependencies.

CVE-2026-77250: mcp-atlassian — Fixed in 0.22.0