CVE-2026-77256: MCP Atlassian: world-readable OAuth token file exposure

HIGHPoC AVAILABLECISA: TRACK*
Published September 22, 2026
CISO Take

MCP Atlassian, the Model Context Protocol server that connects AI agents to Jira and Confluence, writes its plaintext OAuth fallback file (refresh and access tokens) with permissions inherited from the process umask (CWE-732). On shared or permissively configured hosts, any other local user can read that file and keep Atlassian access through the long-lived refresh token, even after the access token expires. Exploitation likelihood is modest: EPSS is 0.00347 (top 74th percentile), the CVE is not in CISA KEV, and SSVC says TRACK*. A public PoC exists, and the package has 38 other CVEs, which points to a weak security track record. The attack needs local access, so the blast radius is limited to multi-user developer boxes, shared CI runners and jump hosts. Upgrade to mcp-atlassian 0.22.0 or later, restrict the token file to mode 0600, and revoke and rotate any Atlassian OAuth tokens that were stored on shared hosts.

Sources:NVDEPSSGitHub AdvisoryATLASCISA SSVC

What is the risk?

Medium-to-high. The weakness is trivial to exploit once an attacker has a local account, and the stolen refresh token gives persistent access that outlives the original session. Limiting factors: it needs local access on the same host, the EPSS percentile is only moderate (top 74%), the CVE is not in KEV, and only 1 downstream dependent is tracked. The impact is confidentiality of Jira and Confluence data and possibly integrity, depending on the scopes granted. The package has a notable history of vulnerabilities (38 other CVEs) and no OpenSSF Scorecard data, which lowers confidence in its security hygiene.

How does the attack unfold?

Initial Access
Attacker obtains a low-privileged local account on a host where MCP Atlassian runs, such as a shared dev box or CI runner.
AML.T0012
Credential Access
Attacker reads the plaintext OAuth fallback file, which is readable because of a permissive umask, and copies the refresh and access tokens.
AML.T0055
Persistence
Attacker uses the refresh token to mint new access tokens, keeping access to Atlassian after the original token expires.
AML.T0091.000
Impact
Attacker reads or modifies Jira and Confluence data with the victim's identity, exposing confidential project and security information.
AML.T0036

What systems are affected?

PackageEcosystemVulnerable RangePatched
MCP Atlassianpip—No patch
2 dependents85% patched~4d to patchFull package profile →

Do you use MCP Atlassian? You're affected.

How severe is it?

CVSS 3.1
N/A
EPSS
0.3%
chance of exploitation in 30 days
Higher than 28% of all CVEs
Exploitation Status
Exploit Available
Exploitation: MEDIUM
Sophistication
Trivial
Exploitation Confidence
medium
○CISA SSVC: Public PoC
○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 should I do?

1 step
  1. 1) Upgrade mcp-atlassian to 0.22.0 or later (pip install -U mcp-atlassian). 2) Locate any existing plaintext OAuth fallback token files and set them to 0600 (and their parent directories to 0700). 3) Set a restrictive umask (e.g. 077) for the service or user account that runs the MCP server. 4) Revoke and rotate Atlassian OAuth refresh and access tokens on any host where other local users or untrusted workloads could have read the file. 5) Prefer an OS keyring or secrets manager over the file fallback where possible. 6) Review Atlassian audit logs for token use from unexpected IPs or user agents, and audit file access on hosts with shared accounts. 7) Run MCP servers under dedicated, isolated accounts or containers.

What does CISA's SSVC say?

DecisionTrack*
Exploitationpoc
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:

EU AI Act
Art. 15-Accuracy, robustness and cybersecurity
ISO 42001
A.7.4-Quality of data and security of AI system resources
NIST AI RMF
MANAGE 2.3-Risk treatment and response for identified AI risks
OWASP LLM Top 10
LLM06-Excessive Agency

Frequently Asked Questions

What is CVE-2026-77256?

MCP Atlassian, the Model Context Protocol server that connects AI agents to Jira and Confluence, writes its plaintext OAuth fallback file (refresh and access tokens) with permissions inherited from the process umask (CWE-732). On shared or permissively configured hosts, any other local user can read that file and keep Atlassian access through the long-lived refresh token, even after the access token expires. Exploitation likelihood is modest: EPSS is 0.00347 (top 74th percentile), the CVE is not in CISA KEV, and SSVC says TRACK*. A public PoC exists, and the package has 38 other CVEs, which points to a weak security track record. The attack needs local access, so the blast radius is limited to multi-user developer boxes, shared CI runners and jump hosts. Upgrade to mcp-atlassian 0.22.0 or later, restrict the token file to mode 0600, and revoke and rotate any Atlassian OAuth tokens that were stored on shared hosts.

Is CVE-2026-77256 actively exploited?

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

How to fix CVE-2026-77256?

1) Upgrade mcp-atlassian to 0.22.0 or later (pip install -U mcp-atlassian). 2) Locate any existing plaintext OAuth fallback token files and set them to 0600 (and their parent directories to 0700). 3) Set a restrictive umask (e.g. 077) for the service or user account that runs the MCP server. 4) Revoke and rotate Atlassian OAuth refresh and access tokens on any host where other local users or untrusted workloads could have read the file. 5) Prefer an OS keyring or secrets manager over the file fallback where possible. 6) Review Atlassian audit logs for token use from unexpected IPs or user agents, and audit file access on hosts with shared accounts. 7) Run MCP servers under dedicated, isolated accounts or containers.

What systems are affected by CVE-2026-77256?

This vulnerability affects the following AI/ML architecture patterns: agent frameworks, MCP servers, tool-integrated LLM assistants, shared developer workstations, CI/CD agent runners.

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

No CVSS score has been assigned yet.

What is the AI security impact?

Affected AI Architectures

agent frameworksMCP serverstool-integrated LLM assistantsshared developer workstationsCI/CD agent runners

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

EU AI Act: Art. 15
ISO 42001: A.7.4
NIST AI RMF: MANAGE 2.3
OWASP LLM Top 10: LLM06

What are the technical details?

Original Advisory

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.

Exploitation Scenario

An attacker with a low-privileged account on a shared development or CI host finds that a colleague runs MCP Atlassian for their AI coding assistant. The tool saved its OAuth fallback token file under a permissive umask, so the file is world- or group-readable. The attacker reads the file, copies the refresh token and uses it from their own machine to mint new access tokens against the Atlassian API. They then use the AI agent's privileges to read confidential Jira tickets and Confluence pages, such as security findings, architecture documents and credentials pasted into pages. They keep that access until the token is revoked.

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.

Timeline

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

Related Vulnerabilities