CVE-2026-77248: mcp-atlassian: unauth file read via upload_attachment

Q: Is CVE-2026-77248 actively exploited?

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

Q: How to fix CVE-2026-77248?

1) Upgrade mcp-atlassian to 0.22.0 or later (PR #1448). 2) Until patched, do not expose the streamable-http transport on 0.0.0.0. Bind it to 127.0.0.1 or a private interface and require authentication at a reverse proxy, mTLS or network ACLs. 3) Prefer per-user OAuth or the OAuth proxy rather than global operator credentials, and use a least-privilege Atlassian service account. 4) Rotate the Atlassian API token and any secrets held in the server's environment or filesystem if the instance was exposed. 5) Run the server in a container with a minimal filesystem and no mounted SSH keys. 6) Detect abuse by reviewing MCP and proxy logs for upload_attachment calls with absolute file_path values such as /proc/self/environ, /etc/passwd or ~/.ssh, and audit Jira and Confluence for unexpected attachments uploaded by the service account.

Q: What systems are affected by CVE-2026-77248?

This vulnerability affects the following AI/ML architecture patterns: agent frameworks, MCP servers, tool-calling LLM integrations, multi-user shared AI agent deployments.

Q: What is the CVSS score for CVE-2026-77248?

CVE-2026-77248 has a CVSS v3.1 base score of 8.6 (HIGH). The EPSS exploitation probability is 0.47%.

GHSA-cc5h-2pwp-pvccHIGHPoC AVAILABLE

Published September 22, 2026

CISO Take

mcp-atlassian versions before 0.22.0 let any unauthenticated network client call every MCP tool in the documented streamable-http deployment, and the upload_attachment tool reads arbitrary server-side files without path validation. An attacker can upload a file such as /proc/self/environ to a page or issue they choose and then download it, which exposes the operator's Atlassian API token, .env secrets and SSH keys. A public PoC exists and the CVSS is 8.6 (scope changed, high confidentiality impact). Exploitation likelihood is modest for now (EPSS 0.4%, top 67%, not in CISA KEV), and the package has only 1 tracked downstream dependent, but the attack needs no credentials and is trivial to script against any exposed instance, so the real exposure depends on where the server is reachable. Upgrade to 0.22.0 immediately, rotate the Atlassian token and any secrets in the server environment if the server was reachable from untrusted networks, and bind the transport to localhost or put it behind an authenticating reverse proxy.

Sources:NVDGitHub AdvisoryEPSSATLAS

What is the risk?

High. The attack is network-reachable, needs no privileges or user interaction, and has low complexity. The default streamable-http binding is 0.0.0.0, and the unauthenticated fallback uses the operator's global Atlassian credentials. A public PoC exists, but EPSS is low (0.00413, top 67%) and there is no KEV listing or Nuclei template, so mass exploitation has not been observed. The risk is highest for internet-exposed or flat-network deployments where the operator's Atlassian principal has admin rights. The package has 38 other CVEs, which points to a weak security track record, and no OpenSSF Scorecard data is available.

How does the attack unfold?

Initial Access

The attacker sends an MCP tools/call request with no Authorization header to the exposed streamable-http endpoint, which falls back to the operator's global Atlassian credentials.

AML.T0049

Tool Invocation

The attacker calls upload_attachment with an arbitrary file_path such as /proc/self/environ and an attacker-chosen page or issue.

AML.T0053

Collection and Exfiltration

The attacker calls download_attachment to read back the file contents, which expose the Atlassian token, .env secrets and SSH keys.

AML.T0086

Impact

The attacker uses the stolen credentials and the unauthenticated read/write tools to access and tamper with Jira and Confluence data and pivot to other systems.

AML.T0055

Initial Access

The attacker sends an MCP tools/call request with no Authorization header to the exposed streamable-http endpoint, which falls back to the operator's global Atlassian credentials.

AML.T0049

Tool Invocation

The attacker calls upload_attachment with an arbitrary file_path such as /proc/self/environ and an attacker-chosen page or issue.

AML.T0053

Collection and Exfiltration

The attacker calls download_attachment to read back the file contents, which expose the Atlassian token, .env secrets and SSH keys.

AML.T0086

Impact

The attacker uses the stolen credentials and the unauthenticated read/write tools to access and tamper with Jira and Confluence data and pivot to other systems.

AML.T0055

What systems are affected?

Package	Ecosystem	Vulnerable Range	Patched
MCP Atlassian	pip	< 0.22.0	`0.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

8.6 / 10

EPSS

0.5%

chance of exploitation in 30 days

Higher than 41% of all CVEs

Source: EPSS v3 — FIRST.org

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?

AVNetwork

ACLow

PRNone

UINone

SChanged

CHigh

INone

ANone

What should I do?

1 step

1) Upgrade mcp-atlassian to 0.22.0 or later (PR #1448). 2) Until patched, do not expose the streamable-http transport on 0.0.0.0. Bind it to 127.0.0.1 or a private interface and require authentication at a reverse proxy, mTLS or network ACLs. 3) Prefer per-user OAuth or the OAuth proxy rather than global operator credentials, and use a least-privilege Atlassian service account. 4) Rotate the Atlassian API token and any secrets held in the server's environment or filesystem if the instance was exposed. 5) Run the server in a container with a minimal filesystem and no mounted SSH keys. 6) Detect abuse by reviewing MCP and proxy logs for upload_attachment calls with absolute file_path values such as /proc/self/environ, /etc/passwd or ~/.ssh, and audit Jira and Confluence for unexpected attachments uploaded by the service account.

How is it classified?

Auth BypassData ExtractionData LeakageAgentPluginAPIAML.T0037- Data from Local System AML.T0049- Exploit Public-Facing Application AML.T0053- AI Agent Tool Invocation AML.T0055- Unsecured Credentials AML.T0086- Exfiltration via AI Agent Tool Invocation

Which compliance frameworks are affected?

This CVE is relevant to:

EU AI Act

Art. 15-Accuracy, robustness and cybersecurity

ISO 42001

A.6.2.6-AI system operation and monitoring

NIST AI RMF

MANAGE 2.3-Responses to unknown or newly identified risks

OWASP LLM Top 10

LLM03-Supply ChainLLM06-Excessive Agency

Frequently Asked Questions

What is CVE-2026-77248?

Is CVE-2026-77248 actively exploited?

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

How to fix CVE-2026-77248?

1) Upgrade mcp-atlassian to 0.22.0 or later (PR #1448). 2) Until patched, do not expose the streamable-http transport on 0.0.0.0. Bind it to 127.0.0.1 or a private interface and require authentication at a reverse proxy, mTLS or network ACLs. 3) Prefer per-user OAuth or the OAuth proxy rather than global operator credentials, and use a least-privilege Atlassian service account. 4) Rotate the Atlassian API token and any secrets held in the server's environment or filesystem if the instance was exposed. 5) Run the server in a container with a minimal filesystem and no mounted SSH keys. 6) Detect abuse by reviewing MCP and proxy logs for upload_attachment calls with absolute file_path values such as /proc/self/environ, /etc/passwd or ~/.ssh, and audit Jira and Confluence for unexpected attachments uploaded by the service account.

What systems are affected by CVE-2026-77248?

This vulnerability affects the following AI/ML architecture patterns: agent frameworks, MCP servers, tool-calling LLM integrations, multi-user shared AI agent deployments.

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

CVE-2026-77248 has a CVSS v3.1 base score of 8.6 (HIGH). The EPSS exploitation probability is 0.47%.

What is the AI security impact?

Affected AI Architectures

agent frameworksMCP serverstool-calling LLM integrationsmulti-user shared AI agent deployments

MITRE ATLAS Techniques

AML.T0037Data from Local System

AML.T0049Exploit Public-Facing Application

AML.T0053AI Agent Tool Invocation

AML.T0055Unsecured Credentials

AML.T0086Exfiltration via AI Agent Tool Invocation

Compliance Controls Affected

EU AI Act: Art. 15

ISO 42001: A.6.2.6

NIST AI RMF: MANAGE 2.3

OWASP LLM Top 10: LLM03, LLM06

What are the technical details?

Original Advisory

### Summary In the documented multi-user HTTP deployment (`--transport streamable-http` with global operator Atlassian credentials), sooperset/mcp-atlassian exposes all tools to **unauthenticated network clients**, and the `upload_attachment` tool reads an attacker-supplied `file_path` with **no path validation**. Chained, an unauthenticated network attacker reads arbitrary files on the MCP server host (e.g. `/proc/self/environ` → the operator's Atlassian API token + `.env` secrets, `~/.ssh/id_rsa`, `/etc/passwd`) by uploading them to an attacker-chosen page/issue and reading them back. ### Details **Missing authentication (transport):** - streamable-http binds `0.0.0.0` by default (`src/mcp_atlassian/__init__.py:151`). - The OAuth-proxy auth provider is opt-in (`ATLASSIAN_OAUTH_PROXY_ENABLE`, default false), so `main_mcp` is built with `auth=None` (`src/mcp_atlassian/servers/main.py:724-731, 813-817`). - `UserTokenMiddleware._parse_auth_header` sets `auth_validation_error` only for a *malformed* Authorization header; a request with **no** Authorization header passes through (`main.py:416-446, 582-595`). - `_get_fetcher` then falls through to the global credential fallback using the operator's `.env` Atlassian token (`src/mcp_atlassian/servers/dependencies.py:644-676`). `check_write_access` gates only on read-only mode, not auth → read **and** write tools reachable. **Arbitrary file read (sink):** - `upload_attachment`'s `file_path` flows unsanitized into `open(file_path, 'rb')` — Confluence `src/mcp_atlassian/confluence/attachments.py:477` (from `servers/confluence.py:1294-1369`); Jira `src/mcp_atlassian/jira/attachments.py:386` (from `servers/jira.py:1609-1673`). No `validate_safe_path` / allowlist (contrast the download flow, hardened after CVE-2026-27825). ### Proof of Concept ``` # unauthenticated (no Authorization header) against a default streamable-http deployment: tools/call upload_attachment { "file_path": "/proc/self/environ", "page_id": "<attacker-chosen>" } # then read it back: tools/call download_attachment { ... } # returns the bytes (base64) -> operator's ATLASSIAN token + .env secrets ``` ### Impact Unauthenticated arbitrary local file read on the MCP server host — including the operator's Atlassian API token and `.env` secrets — a boundary the Atlassian-scoped tool must not cross, plus unauthenticated use of every read/write Atlassian tool as the operator's (often admin) principal. Distinct from GHSA-xjgw-4wvw-rgm4 (file *write* via download_path) and GHSA-7r34-79r5-rcc9 (URL-header SSRF). ### Suggested fix Require authentication on the streamable-http transport by default (do not fall back to operator global credentials for unauthenticated requests); apply `validate_safe_path`/allowlist to `file_path` in `upload_attachment` as the download flow already does. ### Affected `mcp-atlassian` <= 0.21.1.

Exploitation Scenario

An attacker scans for an MCP server running over streamable-http and sends a tools/call request with no Authorization header. The server falls back to the operator's Atlassian credentials, so the request is accepted. The attacker calls upload_attachment with file_path set to /proc/self/environ and a page_id of a page they can read, which attaches the server's environment variables to that page. They then call download_attachment to retrieve the contents as base64, which reveals the Atlassian API token and other secrets. They repeat the process for ~/.ssh/id_rsa and other files, then use the stolen token to access the whole Atlassian tenant and pivot into connected systems.

Weaknesses (CWE)

CWE-22Improper Limitation of a Pathname to a Restricted Directory ('Path Traversal')Primary CWE-22Improper Limitation of a Pathname to a Restricted Directory CWE-306Missing Authentication for Critical Functionality

CWE-22 — Improper Limitation of a Pathname to a Restricted Directory ('Path Traversal'): The product uses external input to construct a pathname that is intended to identify a file or directory that is located underneath a restricted parent directory, but the product does not properly neutralize special elements within the pathname that can cause the pathname to resolve to a location that is outside of the restricted directory.

[Implementation] Assume all input is malicious. Use an "accept known good" input validation strategy, i.e., use a list of acceptable inputs that strictly conform to specifications. Reject any input that does not strictly conform to specifications, or transform it into something that does. When performing input validation, consider all potentially relevant properties, including length, type of input, the full range of acceptable values, missing or extra inputs, syntax, consistency across related fields, and conformance to business rules. As an example of business rule logic, "boat" may be syntactically valid because it only contains alphanumeric characters, but it is not valid if the input is only expected to contain colors such as "red" or "blue." Do not rely exclusively on looking for malicious or malformed inputs. This is likely to miss at least one undesirable input, especially if the code's environment changes. This can give attackers enough room to bypass the intended validation. However, denylis
[Architecture and Design] For any security checks that are performed on the client side, ensure that these checks are duplicated on the server side, in order to avoid CWE-602. Attackers can bypass the client-side checks by modifying values after the checks have been performed, or by changing the client to remove the client-side checks entirely. Then, these modified values would be submitted to the server.

Source: MITRE CWE corpus.