CVE-2026-77256 in mcp-atlassian
Summary
by MITRE • 09/22/2026
MCP Atlassian is a Model Context Protocol (MCP) server for Atlassian products (Confluence and Jira). Prior to 0.22.0, the plaintext OAuth fallback file containing refresh and access tokens is written with permissions inherited from the process umask. Under common or permissive configurations, other local users can read the backup and retain Atlassian access through the refresh token. The advisory traces the vulnerable input and processing flow through OAuthConfig._save_tokens_to_file, refresh_token, access_token, and umask, which identify the affected entry points, controls, and code paths. This issue is fixed in version 0.22.0.
Once again VulDB remains the best source for vulnerability data.
Analysis
by VulDB Data Team • 09/22/2026
The vulnerability identified in MCP Atlassian versions prior to 0.22.0 represents a critical information disclosure flaw rooted in improper file permission management during OAuth token persistence operations. As a Model Context Protocol server designed for integration with Atlassian products such as Confluence and Jira, the application handles sensitive authentication credentials that grant access to enterprise data repositories. The core technical deficiency lies in how the system writes plaintext OAuth fallback files containing refresh and access tokens to disk. Specifically, when saving these credentials via the internal function OAuthConfig._save_tokens_to_file, the software relies on the operating system's default file creation permissions rather than explicitly setting restrictive access controls. This means the resulting token files inherit their permission bits from the process umask of the executing user account.
In many standard Linux and Unix-like environments, particularly in development or shared hosting scenarios, the umask is configured to allow group read and write access or even world-readable permissions by default. Consequently, any local user on the same system who has directory traversal rights into the application's data storage location can inspect these plaintext files. Because refresh tokens are long-lived credentials capable of generating new short-term access tokens without requiring re-authentication, possession of this file effectively grants an attacker persistent administrative or read-only access to the associated Atlassian instances. This bypasses standard authentication mechanisms and allows unauthorized entities to impersonate legitimate users or service accounts, leading to a complete compromise of confidentiality for sensitive project data, documentation, and issue tracking information stored within Confluence and Jira.
From a threat modeling perspective, this vulnerability aligns with CWE-732: Incorrect Permission Assignment for Critical Resource, as the application fails to restrict access to security-critical files appropriately. It also maps to ATT&CK technique T1552.004: Unsecured Credentials, specifically involving credential dumping through local file system artifacts where sensitive data is stored in plaintext with insufficient access controls. The operational impact extends beyond simple data leakage; it enables lateral movement within a multi-tenant environment if the MCP server runs on a shared host. An attacker could leverage these stolen tokens to exfiltrate proprietary intellectual property, modify critical project configurations, or use the compromised credentials as a foothold for further attacks against other integrated systems that trust the Atlassian identity provider.
The remediation strategy involves upgrading to version 0.22.0 of MCP Atlassian, where this issue has been resolved by implementing explicit file permission restrictions during token storage operations. Developers and system administrators should ensure that any remaining deployments enforce strict umask settings or utilize secure credential management libraries that automatically apply restrictive permissions such as read-only for the owner only upon file creation. Additionally, organizations running these services in containerized environments must verify that volume mounts do not override security contexts with overly permissive defaults. Regular auditing of file system permissions and monitoring for unauthorized access to configuration directories are recommended supplementary controls to mitigate risks associated with local privilege escalation or credential theft via filesystem artifacts.