What is the CVSS score of EUVD-2026-84752?

EUVD-2026-84752 has a CVSS 4.0 base score of 8.3 (High). CVSS vector: CVSS:4.0/AV:N/AC:L/AT:N/PR:L/UI:N/VC:H/VI:N/VA:N/SC:H/SI:N/SA:N. EPSS exploitation probability: 0.5%.

Is there a public PoC exploit available for EUVD-2026-84752?

Yes, a public proof-of-concept exploit is available for EUVD-2026-84752. Prioritise patching immediately. EPSS: 0.5%.

How to fix or mitigate EUVD-2026-84752?

Within 24 hours, inventory every deployment of mcp-atlassian, flag any instance below version 0.22.0 that runs the HTTP or streamable-http transport with shared operator Atlassian credentials, and temporarily restrict who may invoke the upload_attachment and upload_attachments tools (including through jira update_issue) or disable those tools where the integration does not require them; simultaneously review recent Jira and Confluence attachment activity on the connected tenants for unexpected files or unusual uploader accounts. Within 7 days, upgrade all identified remote and multi-user instances to mcp-atlassian 0.22.0, confirm the new version is running, and re-enable upload functionality only for the clients that need it. Within 30 days, run the MCP server in a least-privilege container or dedicated service account with filesystem access confined to the workspace directory, remove shared Atlassian credentials in favor of per-client scoping where the product supports it, and add alerting on upload tool calls and attachment creation so any future path-traversal or exfiltration attempt is detected quickly.

MCP Atlassian EUVD-2026-84752

Q: Which versions of MCP Atlassian are affected by EUVD-2026-84752?

The Atlassian MCP integration (mcp-atlassian) in versions before 0.22.0 can be abused by a permitted MCP client to read files off the host running the server and forward them out as Jira or…. A patch is available.

| CVE-2026-77247 HIGH

External Control of File Name or Path (CWE-73)

2026-09-22 GitHub_M

GHSA-f6pj-qv47-g96w

Python Information Disclosure Atlassian Mcp Atlassian

8.3

CVSS 4.0 · Vendor: GitHub_M

View

Attack ChainAIDerived

Hypothetical attack flow derived from CVE metadata – not a confirmed exploit chain

Access

Obtain permitted MCP client access to remote server
Delivery

Invoke Jira/Confluence upload tool with crafted file_path
Exploit

Server opens arbitrary host file as attachment
Execution

Read attachment back from Atlassian
Impact

Exfiltrate secrets/config from host

Vulnerability Assessment

Weakness	CWE CWE-73 OWASP Top 10:2025 A06:2025 - Insecure Design ASVS 5.0 V5 - File Handling File name/path control
Exploitation Conditions	Requires a remote or multi-user deployment of mcp-atlassian prior to 0.22.0 (HTTP/streamable-http transport rather than local single-user stdio), where the server runs with operator Atlassian credentials shared across clients. The attacker must be a permitted MCP client authorized to invoke the Jira or Confluence upload tools (upload_attachment/upload_attachments, reachable via jira update_issue). Limiting factors: PR:L means the caller must already be an authorized client (not anonymous); in single-user/stdio installs the caller already owns the host so there is no privilege boundary crossed; no user interaction is needed. The read is bounded to files the server process can access.
Impact	This is a genuine but access-gated file-disclosure flaw, not a headline emergency. The vendor CVSS 4.0 base of 8.3 (AV:N/AC:L/AT:N/PR:L/UI:N/VC:H/VI:N/VA:N/SC:H) correctly captures network reach, low complexity, and high confidentiality impact, but the PR:L requirement is decisive: exploitation depends on already being a permitted MCP client with upload-tool access to a remote/multi-user deployment sharing operator Atlassian credentials - this is not an anonymous internet-facing bug. The SC:H subsequent-scope claim is arguable; in a stdio/single-user install (the common MCP deployment mode) the caller already has host access, so the vulnerability adds little. No EPSS score, no CISA KEV listing, and no public exploit code are present in the input - no public exploit identified at time of analysis. The CWE assignment (CWE-73, external control of file name/path) and the PR-diff evidence (validate_safe_path replacing a bare os.path.abspath) confirm the mechanism precisely. Net: a real priority only for organizations running mcp-atlassian in shared/multi-tenant HTTP mode; low real-world urgency elsewhere given niche product footprint and no exploitation signal.
Exploit ScenarioDerived	An organization runs mcp-atlassian in remote/HTTP multi-user mode where several clients share the operator's Atlassian credentials. A permitted-but-untrusted client calls the Jira or Confluence upload tool (upload_attachment/upload_attachments, e.g. via jira update_issue) with file_path set to a sensitive host path such as /etc/passwd, an OAuth token file, or a mounted secret; the server opens and uploads it as an attachment, which the caller then reads back. No public exploit code is identified in the provided data, but the flow is fully documented in the advisory and fix diff.

This Week Schedule remediation this week. Why: HIGH severity (CVSS 7.0-8.9).

Patch available 0.5% exploitation probability (EPSS)

Get an e-mail when this CVE is exploited, patched or re-scored. Free account.

Alert me

AnalysisAIv1 – Sep 22, 2026

Path traversal in the MCP Atlassian server (mcp-atlassian) prior to 0.22.0 allows an authenticated MCP client to read files from the host running the server and exfiltrate them as Jira or Confluence attachments, because the upload tools open caller-supplied file_path / file_paths arguments without confining them to the workspace. The privilege boundary only exists in remote or multi-user deployments (HTTP/streamable-http transport with operator Atlassian credentials shared across clients), since in a single-user stdio install the caller already owns the host; exploitation requires a permitted client authorized to invoke upload_attachment/upload_attachments (including via jira update_issue), and the read is bounded to files the server process can access. No public exploit code identified at time of analysis and no confirmed active exploitation; vendor-released patch: 0.22.0.

RemediationAI

Upgrade mcp-atlassian to version 0.22.0 or later, per the vendor advisory at https://github.com/sooperset/mcp-atlassian/security/advisories/GHSA-f6pj-qv47-g96w and the release tag https://github.com/sooperset/mcp-atlassian/releases/tag/v0.22.0; the fix (PR https://github.com/sooperset/mcp-atlassian/pull/1448, commit b041733473f95119dd539542a43c280737a8e460) substitutes the unconstrained os.path.abspath call with validate_safe_path(), confining upload sources to the workspace. If upgrading immediately is not possible, compensating controls are: switch the deployment from HTTP/streamable-http back to single-user stdio transport so no untrusted client shares the server's credentials (trade-off: loses multi-client and remote access); restrict who can reach the MCP endpoint and which tool calls are permitted, denying upload_attachment/upload_attachments and jira update_issue attachment arguments (trade-off: breaks legitimate attachment workflows); and run the MCP server process under a dedicated least-privilege OS account, container, or sandbox with its Atlassian token stored outside any path the server can read and with read access limited to a dedicated upload/workspace directory (trade-off: container and mount reconfiguration, and credentials must be injected at runtime rather than read from a host config file, which itself would otherwise be a prime exfiltration target).

Affected VersionsENISA

mcp-atlassian < 0.22.0

Affected Packages

pypi mcp-atlassian fix: 0.22.0

Source: OSV (Open Source Vulnerabilities)

Affects your stack

Affects 1 package in pypi

Checking this CVE against your own stacks and servers is part of the Basic plan and up.

Technical ContextAI · show details

The issue is classified as CWE-73 (External Control of File Name or Path) in the mcp-atlassian Python package, an MCP (Model Context Protocol) server that exposes Confluence and Jira operations as tools to LLM clients over stdio or HTTP/streamable-http transports. The vulnerable flow routes a caller-controlled argument through AttachmentsMixin.upload_attachment, AttachmentsMixin.upload_attachments, the file_path and file_paths parameters, and the jira update_issue path: the server converted the supplied path with os.path.abspath (no confinement check) and then opened and read the file locally before transmitting it as an attachment to Atlassian. Because the path was interpreted on the MCP server's host rather than inside the caller's environment, any path readable by the server process (e.g. /etc/passwd, the server's own configuration holding Atlassian API tokens) could be pulled into an Atlassian ticket or page where the client can retrieve it. The upstream fix in 0.22.0 replaces the abspath conversion with validate_safe_path(), rejecting traversal and absolute paths that escape the working directory. The same upstream hardening PR also addressed adjacent server-side trust boundaries - SSRF redirect validation and DNS rebinding pinning on the Confluence session, ANDing the caller-supplied spaces_filter with the operator's configured allowlist rather than letting it replace it, and refusing attachment downloads into the working-directory root - but those are separate weaknesses, not the CWE-73 file-disclosure path described here.

Know when Mcp Atlassian gets its next vulnerability

Watch products and get an email when something new is published
Check this CVE against your own stack and servers
Exploit and PoC references, threat intelligence from 22 sources

Continue with Google Continue with GitHub

No credit card · 7-day full trial

Severity by source

Vendor (GitHub_M) PRIMARY 8.3 HIGH

CVSS:4.0/AV:N/AC:L/AT:N/PR:L/UI:N/VC:H/VI:N/VA:N/SC:H/SI:N/SA:N

vuln.today AI 6.5 MEDIUM

Network-reachable tool call by an authorized-but-untrusted caller (PR:L), arbitrary host-file read gives C:H; no integrity or availability impact and no cross-system scope change (S:U).

3.1 AV:N/AC:L/PR:L/UI:N/S:U/C:H/I:N/A:N

4.0 AV:N/AC:L/AT:N/PR:L/UI:N/VC:H/VI:N/VA:N/SC:N/SI:N/SA:N

Primary rating from Vendor (GitHub_M).

CVSS VectorVendor: GitHub_M

Attack Vector

Network

Attack Complexity

Low

Attack Requirements

None

Privileges Required

Low

User Interaction

None

Vulnerable system: Confidentiality

High

Vulnerable system: Integrity

None

Vulnerable system: Availability

None

Subsequent system: Confidentiality

High

Subsequent system: Integrity

None

Subsequent system: Availability

None

Lifecycle Timeline

Patch available

Sep 22, 2026 - 20:18 EUVD

CVE Published

Sep 22, 2026 - 18:34 cve.org

HIGH 8.3

DescriptionCVE.org

MCP Atlassian is a Model Context Protocol (MCP) server for Atlassian products (Confluence and Jira). Prior to 0.22.0, Jira and Confluence upload tools interpret caller-controlled path arguments on the MCP server and open those files before sending them as attachments. In remote or multi-user deployments, a permitted client can disclose host files without shell or direct filesystem access. The advisory traces the vulnerable input and processing flow through AttachmentsMixin.upload_attachment, AttachmentsMixin.upload_attachments, file_path, file_paths, and jira update_issue, which identify the affected entry points, controls, and code paths. This issue is fixed in version 0.22.0.

Technical POC Analysis

CWE-73 (External Control of File Name or Path).

Full technical POC analysis - root cause, step-by-step exploitation and patch breakdown - is part of the Pro and Business plans.

Executive ViewAI

Why It Matters

The Atlassian MCP integration (mcp-atlassian) in versions before 0.22.0 can be abused by a permitted MCP client to read files off the host running the server and forward them out as Jira or Confluence attachments, turning a trusted collaboration channel into a potential data-exfiltration path. Exposure is concentrated in shared, remote deployments where the server runs with operator Atlassian credentials used across multiple clients; single-user desktop installs carry little incremental risk since the caller already owns the machine. Leadership should care because the affected host may hold credentials, configuration, or business data, and the theft would surface as ordinary attachment activity in systems teams already trust.

Business Impact: High

Compensating Controls

Apply vendor patch.

Threat Intelligence Overview

EPSS Score

0.5%

Top 60% exploitable

Prevalence

Low

niche open-source Atlassian MCP server, small production footprint

Threat Intel

1 source

Exploit

POC

Public exploit code exists

Data Quality

6 sources

Confidence: High

EUVD 🇯🇵JVN

NVD

CVE.org

EPSS

Vulnrichment GHSA

GitHub

How this decision was reached

The engine reads each signal below and applies a fixed list of rules from top to bottom. The first rule that matches sets the recommended action – like a statement, every line is shown.

SignalValue

Severity HIGH

CISA KEV No

Public POC Yes

EPSS 0.5%

Patch available Yes

Active threat No

Deciding rule

HIGH severity (CVSS 7.0-8.9)

What every action level means

Emergency Immediate action required. Criteria: CRITICAL + in CISA KEV (actively exploited) without patch, OR CRITICAL + EPSS > 30% without patch, OR CRITICAL + active threat signals without patch.

Act Now Prioritize within 24-48h. Criteria: in KEV with patch available, OR CRITICAL + public POC, OR HIGH + EPSS > 10%, OR CRITICAL + active threat, OR any CRITICAL severity.

This Week Schedule remediation this week. Criteria: HIGH severity (CVSS 7.0-8.9). Patch within normal change window.

This Month Plan within 30 days. Criteria: MEDIUM severity (CVSS 4.0-6.9), lower exploitation probability. Include in regular patch cycle.

Monitor Track and reassess. Criteria: LOW severity (CVSS 0.1-3.9), minimal exploitation risk. No immediate action needed.

SSVC AssessmentENISA

SSVC Decision

Scheduled

Exploitation

Poc

System Exposure· derived

Open

Automatable

Human Impact

High

Technical Impact

Partial

Priority Score

Low Medium High Critical

KEV: 0

EPSS: 0

CVSS: +42

PoC: +20

Weaponized: 0

Threat intel: 0

Gov advisory: 0

Attack Technique

Information Disclosure MEDIUM

Information disclosure occurs when an application unintentionally exposes sensitive data that aids attackers in reconnaissance or directly compromises security.