Skip to main content
Vulnerability Database/CVE-2026-77250

CVE-2026-77250: MCP Atlassian Information Disclosure Flaw

CVE-2026-77250 is an information disclosure vulnerability in MCP Atlassian that exposes OAuth tokens in plaintext files with permissive permissions. This post explains its impact, affected versions, and mitigation steps.

Published:

CVE-2026-77250 Overview

MCP Atlassian is a Model Context Protocol (MCP) server that bridges AI assistants with Atlassian products such as Confluence and Jira. Versions prior to 0.22.0 persist OAuth access and refresh tokens to a plaintext fallback file under the user's ~/.mcp-atlassian directory. The file is created using the process-default file mode, so a permissive umask can leave the token file readable by same-group or other local users. Any local account or process that can read the file can reuse the stored credentials to access the associated Atlassian tenant. The issue is tracked as [CWE-312: Cleartext Storage of Sensitive Information] and is fixed in version 0.22.0.

Critical Impact

Local users with read access to the token file can hijack a victim's Atlassian OAuth session and act as that user against Confluence or Jira.

Affected Products

  • MCP Atlassian versions prior to 0.22.0
  • Deployments relying on the OAuth fallback token file at ~/.mcp-atlassian/oauth-<client_id>.json
  • Multi-user hosts running MCP Atlassian under a permissive umask

Discovery Timeline

  • 2026-09-22 - CVE-2026-77250 published to NVD
  • 2026-09-23 - Last updated in NVD database
  • v0.22.0 - Fix released by the MCP Atlassian project via GitHub Release v0.22.0

Technical Details for CVE-2026-77250

Vulnerability Analysis

The vulnerability resides in the OAuthConfig._save_tokens code path, which writes OAuth material to ~/.mcp-atlassian/oauth-<client_id>.json. The file contains both access_token and refresh_token fields in plaintext JSON. When the file is created, no explicit permission mode is set, so the resulting mode is derived from the calling process's umask. On hosts where administrators or container images set a permissive umask such as 022 or 002, the JSON becomes world-readable or group-readable. Any local principal that can traverse the user's home directory can read the tokens and replay them against the Atlassian API. Refresh tokens compound the risk because they allow long-lived access even after the original access token expires.

Root Cause

The root cause is missing least-privilege enforcement on a sensitive credential file. _save_tokens does not call os.chmod after write or open the file with an explicit restrictive mode such as 0o600. It also does not encrypt the token payload at rest or defer to an OS-provided secret store. The behavior is classified under [CWE-312] because credentials are persisted without cryptographic protection and without adequate filesystem access controls.

Attack Vector

Exploitation requires local access to the host running MCP Atlassian. A same-group user, a lower-privileged service account, or a compromised sibling process reads the JSON file directly from disk. The attacker extracts access_token and refresh_token, then issues authenticated requests to Confluence or Jira Cloud using the victim's OAuth session. Because refresh tokens are included, the attacker can renew access without further interaction. The attack is silent, leaves no artifacts on the Atlassian side beyond normal API activity, and does not trigger user prompts.

The upstream patch introduces broader security hardening across the project, including path confinement for attachment uploads.

python
            # Confine the upload source to the workspace before it is read: reject
            # traversal/absolute paths that escape CWD (arbitrary file read /
            # exfiltration via a caller-supplied file_path).
            file_path = str(validate_safe_path(file_path))

            # Check if file exists
            if not os.path.exists(file_path):

Source: GitHub Commit b041733

Detection Methods for CVE-2026-77250

Indicators of Compromise

  • Presence of ~/.mcp-atlassian/oauth-<client_id>.json with group or world read permissions (mode broader than 0600).
  • Reads of the token file by user IDs other than the owner of the MCP Atlassian process.
  • Atlassian audit log entries showing API calls from unexpected source IPs or user agents while reusing the victim's OAuth client ID.
  • Unexpected OAuth refresh token exchanges against Atlassian tenants originating from hosts running vulnerable MCP Atlassian versions.

Detection Strategies

  • Inventory hosts running MCP Atlassian and query the installed version; flag any release below 0.22.0.
  • File integrity monitoring on ~/.mcp-atlassian/ directories to alert on permission drift and non-owner access.
  • Correlate Atlassian Cloud audit events with the source host and user context of the MCP Atlassian service to detect off-host token reuse.

Monitoring Recommendations

  • Enable Atlassian OAuth client audit logging and forward events to a centralized SIEM for cross-source correlation.
  • Alert on Linux open() or read() syscalls against oauth-*.json files by processes not owned by the MCP Atlassian service account.
  • Track anomalous refresh token exchanges and geographically improbable API access patterns per OAuth client ID.

How to Mitigate CVE-2026-77250

Immediate Actions Required

  • Upgrade MCP Atlassian to version 0.22.0 or later on every host running the server.
  • Revoke and rotate any Atlassian OAuth client secrets and refresh tokens previously stored by vulnerable versions.
  • Audit ~/.mcp-atlassian/ on all affected hosts and delete stale token files after rotation.
  • Review Atlassian audit logs for suspicious API activity tied to the affected OAuth clients.

Patch Information

The fix ships in MCP Atlassian 0.22.0. See the GitHub Security Advisory GHSA-g5xv-mhgm-v5f6, the merged Pull Request #1448, and the commit b041733 for the code change. The release notes are published at GitHub Release v0.22.0.

Workarounds

  • Run MCP Atlassian under a dedicated service account with a restrictive umask of 077 so newly created files default to owner-only access.
  • Manually set chmod 600 ~/.mcp-atlassian/oauth-*.json and place the directory on a filesystem where only the service account has traversal rights.
  • Isolate the MCP Atlassian process on a single-tenant host or container to remove same-group and other local users from the trust boundary.
bash
# Restrict permissions on the OAuth token directory and files
umask 077
chmod 700 ~/.mcp-atlassian
chmod 600 ~/.mcp-atlassian/oauth-*.json

# Verify current permissions
ls -la ~/.mcp-atlassian/

Disclaimer: This content was generated using AI. While we strive for accuracy, please verify critical information with official sources.

Experience the Most Advanced Cybersecurity Platform

See how the world’s most intelligent, autonomous cybersecurity platform can protect your organization today and into the future.