CVE-2026-77268: mcp-atlassian: world-readable OAuth token file exposure

GHSA-4596-2p6p-28cvMEDIUMPoC AVAILABLE
Published September 22, 2026
CISO Take

mcp-atlassian versions before 0.22.0 write Atlassian OAuth access and refresh tokens to ~/.mcp-atlassian/ with default umask permissions (typically 0644), so any other local user can read them and impersonate the victim in Jira and Confluence. The CVSS score is a moderate 5.5 because exploitation requires local access, but a public PoC exists and the refresh token gives persistent access. The EPSS score is low (0.00122) even though its percentile is high, CISA SSVC says TRACK, and the CVE is not in KEV. Downstream exposure is narrow (1 tracked dependent), though the package has 38 other CVEs, which signals a weak security track record. Upgrade to 0.22.0, tighten permissions on existing token files, and rotate any tokens that lived on shared hosts, CI runners or multi-user workstations.

Sources:NVDEPSSGitHub AdvisoryATLASCISA SSVC

What is the risk?

Medium overall. Exploitation is trivial (a single file read) and a PoC exists, but it needs local access to a shared system with an existing victim session. The refresh token extends the exposure window beyond access token expiry. Risk is highest on shared servers, CI/CD runners and containers where keyring is unavailable and the file fallback is the only storage. Single-user laptops are at low risk. Confidentiality impact is high (Jira/Confluence data); integrity and availability are not directly affected by the flaw, though the stolen tokens grant the victim's API permissions.

How does the attack unfold?

Initial Access
Attacker gains a low-privileged local account or foothold on a shared host where mcp-atlassian OAuth is in use.
AML.T0012
Credential Access
Attacker reads the world-readable ~/.mcp-atlassian/oauth-*.json file containing access and refresh tokens.
AML.T0055
Token Abuse
Attacker uses the stolen bearer token and refresh token to authenticate to the Atlassian API as the victim.
AML.T0091.000
Impact
Attacker reads or modifies Jira issues and Confluence pages and keeps persistent access via token refresh.
AML.T0036

What systems are affected?

PackageEcosystemVulnerable RangePatched
MCP Atlassianpip< 0.22.00.22.0
2 dependents85% patched~4d to patchFull package profile →

Do you use MCP Atlassian? You're affected.

How severe is it?

CVSS 3.1
5.5 / 10
EPSS
0.2%
chance of exploitation in 30 days
Higher than 4% of all CVEs
Exploitation Status
Exploit Available
Exploitation: MEDIUM
Sophistication
Trivial
Exploitation Confidence
medium
○Public PoC indexed (trickest/cve)
Composite signal derived from CISA KEV, VulnCheck KEV, CISA SSVC, EPSS, Metasploit, Exploit-DB, trickest/cve, Nuclei templates, and inthewild.io exploitation reports.

What is the attack surface?

AVACPRUISCIA
AVLocal
ACLow
PRLow
UINone
SUnchanged
CHigh
INone
ANone

What should I do?

1 step
  1. 1) Upgrade mcp-atlassian to 0.22.0 or later. 2) On existing installs run chmod 700 ~/.mcp-atlassian and chmod 600 ~/.mcp-atlassian/oauth-*.json. 3) Rotate or revoke OAuth tokens and client secrets for any account used on shared or multi-user systems, and review Atlassian audit logs for unusual API access from unexpected IPs. 4) Prefer a working keyring backend, or run the server in single-user containers with isolated home directories. 5) Detect with file permission scans for world-readable oauth-*.json files under user home directories.

What does CISA's SSVC say?

DecisionTrack
Exploitationnone
AutomatableNo
Technical Impactpartial

Source: CISA Vulnrichment (SSVC v2.0). Decision based on the CISA Coordinator decision tree.

How is it classified?

Which compliance frameworks are affected?

This CVE is relevant to:

ISO 42001
A.6.2.6-AI system operation and monitoring
NIST AI RMF
MANAGE 2.3-Risk treatment and response for AI system risks
OWASP LLM Top 10
LLM06-Excessive Agency

Frequently Asked Questions

What is CVE-2026-77268?

mcp-atlassian versions before 0.22.0 write Atlassian OAuth access and refresh tokens to ~/.mcp-atlassian/ with default umask permissions (typically 0644), so any other local user can read them and impersonate the victim in Jira and Confluence. The CVSS score is a moderate 5.5 because exploitation requires local access, but a public PoC exists and the refresh token gives persistent access. The EPSS score is low (0.00122) even though its percentile is high, CISA SSVC says TRACK, and the CVE is not in KEV. Downstream exposure is narrow (1 tracked dependent), though the package has 38 other CVEs, which signals a weak security track record. Upgrade to 0.22.0, tighten permissions on existing token files, and rotate any tokens that lived on shared hosts, CI runners or multi-user workstations.

Is CVE-2026-77268 actively exploited?

Proof-of-concept exploit code is publicly available for CVE-2026-77268, increasing the risk of exploitation.

How to fix CVE-2026-77268?

1) Upgrade mcp-atlassian to 0.22.0 or later. 2) On existing installs run chmod 700 ~/.mcp-atlassian and chmod 600 ~/.mcp-atlassian/oauth-*.json. 3) Rotate or revoke OAuth tokens and client secrets for any account used on shared or multi-user systems, and review Atlassian audit logs for unusual API access from unexpected IPs. 4) Prefer a working keyring backend, or run the server in single-user containers with isolated home directories. 5) Detect with file permission scans for world-readable oauth-*.json files under user home directories.

What systems are affected by CVE-2026-77268?

This vulnerability affects the following AI/ML architecture patterns: agent frameworks, MCP servers, CI/CD pipelines with AI agents, containerized AI tooling.

What is the CVSS score for CVE-2026-77268?

CVE-2026-77268 has a CVSS v3.1 base score of 5.5 (MEDIUM). The EPSS exploitation probability is 0.15%.

What is the AI security impact?

Affected AI Architectures

agent frameworksMCP serversCI/CD pipelines with AI agentscontainerized AI tooling

MITRE ATLAS Techniques

AML.T0037Data from Local System
AML.T0055Unsecured Credentials
AML.T0083Credentials from AI Agent Configuration
AML.T0091.000Application Access Token

Compliance Controls Affected

ISO 42001: A.6.2.6
NIST AI RMF: MANAGE 2.3
OWASP LLM Top 10: LLM06

What are the technical details?

Original Advisory

## Summary The OAuth token fallback file storage in `OAuthConfig._save_tokens_to_file()` creates token files containing access tokens, refresh tokens, and cloud IDs with default filesystem permissions (typically `0644` on Linux, world-readable). Any local user on a shared system can read these files to obtain full Atlassian API credentials, enabling unauthorized access to the victim's Jira and Confluence data. ## Details The vulnerability exists in `src/mcp_atlassian/utils/oauth.py` in the `_save_tokens_to_file` method. **Step 1 -- Directory created without restrictive permissions:** At line 402-403, the token directory is created with `mkdir(exist_ok=True)` which uses the default umask (typically creating directories with mode `0755`): ```python # src/mcp_atlassian/utils/oauth.py:402-403 token_dir = Path.home() / ".mcp-atlassian" token_dir.mkdir(exist_ok=True) ``` **Step 2 -- Token file written with default permissions:** At line 417-418, the token file containing sensitive credentials is written using `open()` with no explicit mode, inheriting default umask permissions (typically `0644` on Linux): ```python # src/mcp_atlassian/utils/oauth.py:406-418 token_path = token_dir / f"oauth-{self.client_id}.json" if token_data is None: token_data = { "refresh_token": self.refresh_token, "access_token": self.access_token, "expires_at": self.expires_at, "cloud_id": self.cloud_id, "base_url": self.base_url, } with open(token_path, "w") as f: json.dump(token_data, f) ``` **Step 3 -- The file contains full API credentials:** The token file contains: - `access_token`: A valid OAuth access token for the Atlassian API - `refresh_token`: Can be exchanged for new access tokens indefinitely - `cloud_id`: Identifies the target Atlassian Cloud instance - `base_url`: The target Data Center instance URL **No `os.chmod` or `os.fchmod` is called** anywhere after file creation. The primary storage via `keyring` (line 373) is secure, but the fallback file storage at line 386 is always written in addition to keyring (line 386: `self._save_tokens_to_file(token_data)`). When keyring fails (common in headless/container/CI environments), the fallback becomes the only storage. ## PoC ```bash # Step 1: Victim runs mcp-atlassian with OAuth and completes the flow. # This creates the token file. # Step 2: As any other user on the same system, read the token file: cat /home/victim/.mcp-atlassian/oauth-*.json # Expected output (sensitive credentials in plaintext): # {"refresh_token": "eyJ...", "access_token": "eyJ...", "expires_at": 1741234567.0, "cloud_id": "abc-123", "base_url": null} # Step 3: Verify the token works: curl -H "Authorization: Bearer <stolen_access_token>" \ "https://api.atlassian.com/ex/jira/<stolen_cloud_id>/rest/api/3/myself" # Step 4: Use the refresh token to get a new access token: curl -X POST "https://auth.atlassian.com/oauth/token" \ -d "grant_type=refresh_token" \ -d "client_id=<from_env>" \ -d "client_secret=<from_env>" \ -d "refresh_token=<stolen_refresh_token>" ``` **Verify file permissions (on Linux/macOS):** ```bash ls -la ~/.mcp-atlassian/ # drwxr-xr-x 2 user user 4096 Mar 10 12:00 . # -rw-r--r-- 1 user user 256 Mar 10 12:00 oauth-abc123.json # ^^ ^^ ^^ # world-readable! ``` ## Impact - **Credential theft**: Any local user can read the OAuth tokens and impersonate the victim on their Atlassian Cloud/Data Center instance. - **Persistent access**: The refresh token allows the attacker to generate new access tokens indefinitely, even after the original access token expires. - **Full API access**: The stolen tokens grant the same API permissions as the victim, including reading/writing Jira issues, Confluence pages, and potentially sensitive project data. - **Affected environments**: Shared servers, CI/CD runners, multi-user workstations, and containerized deployments where the fallback file storage is used (keyring unavailable). ## Recommended Fix **1. Set restrictive permissions on the directory and file:** ```python # src/mcp_atlassian/utils/oauth.py import os import stat def _save_tokens_to_file(self, token_data: dict | None = None) -> None: """Save the tokens to a file as fallback storage.""" try: token_dir = Path.home() / ".mcp-atlassian" token_dir.mkdir(exist_ok=True, mode=0o700) token_path = token_dir / f"oauth-{self.client_id}.json" if token_data is None: token_data = { "refresh_token": self.refresh_token, "access_token": self.access_token, "expires_at": self.expires_at, "cloud_id": self.cloud_id, "base_url": self.base_url, } # Open with restrictive permissions (owner-only read/write) fd = os.open( str(token_path), os.O_WRONLY | os.O_CREAT | os.O_TRUNC, stat.S_IRUSR | stat.S_IWUSR, # 0o600 ) try: with os.fdopen(fd, "w") as f: json.dump(token_data, f) except Exception: os.close(fd) raise logger.debug(f"Saved OAuth tokens to file {token_path} (fallback storage)") except Exception as e: logger.error(f"Failed to save tokens to file: {e}") ``` **2. Additionally, fix the directory permissions for existing installations:** ```python # In __init__ or from_env, ensure existing directories are tightened token_dir = Path.home() / ".mcp-atlassian" if token_dir.exists(): os.chmod(str(token_dir), 0o700) ```

Exploitation Scenario

A developer runs mcp-atlassian with OAuth on a shared build server or multi-tenant dev host where keyring is unavailable, so the tokens are written to ~/.mcp-atlassian/oauth-<client_id>.json with mode 0644. A low-privileged local user, or malware running under another account, reads the file and copies the access token, refresh token and cloud_id. The attacker calls the Atlassian API with the bearer token to read Jira issues and Confluence pages, then uses the refresh token and OAuth client credentials to mint new tokens and keep access after the original token expires.

Weaknesses (CWE)

CWE-732 — Incorrect Permission Assignment for Critical Resource: The product specifies permissions for a security-critical resource in a way that allows that resource to be read or modified by unintended actors.

  • [Implementation] When using a critical resource such as a configuration file, check to see if the resource has insecure permissions (such as being modifiable by any regular user) [REF-62], and generate an error or even exit the software if there is a possibility that the resource could have been modified by an unauthorized party.
  • [Architecture and Design] Divide the software into anonymous, normal, privileged, and administrative areas. Reduce the attack surface by carefully defining distinct user groups, privileges, and/or roles. Map these against data, functionality, and the related resources. Then set the permissions accordingly. This will allow you to maintain more fine-grained control over your resources. [REF-207]

Source: MITRE CWE corpus.

CVSS Vector

CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:N/A:N

Timeline

Published
September 22, 2026
Last Modified
September 23, 2026
First Seen
September 23, 2026

Related Vulnerabilities