GHSA-MRQ8-FV7V-HHJG

Vulnerability from github – Published: 2026-09-22 20:34 – Updated: 2026-09-22 20:34

Summary

MCP Atlassian: HTTP upload tools accept arbitrary server-local file paths

Details

sooperset/mcp-atlassian: HTTP upload tools can attach arbitrary server-local files

Date: 2026-05-05 Target: sooperset/mcp-atlassian Commit: d8bc78698a63cb6b321c7ca796d6329d448f7f6d

Summary

mcp-atlassian supports HTTP/SSE deployment for persistent, remote, and multi-user use. In that mode, write-capable Jira and Confluence attachment flows accept caller-controlled server-local file paths and read those paths without an upload-source allowlist or base directory restriction.

An authenticated caller, or a prompt-injected agent with tool-call capability, can cause the MCP server process to read a local file it can access and attach that file into a Jira issue or Confluence page using configured Atlassian credentials.

This is distinct from the prior download-path advisory: that issue was an arbitrary file write sink. This path is upload-source local file disclosure.

Impact

Impact is local file disclosure through an authenticated Atlassian attachment write. In Docker/Kubernetes deployments that mount .env or token material into the service, exposed files may include API tokens, OAuth credentials, service configuration, or other local secrets readable by the MCP process.

The issue is bounded by tool access and Atlassian permissions: the attacker needs an MCP call path to a write tool and an issue/page where the attachment can be written. It is not direct RCE.

Severity is Medium-to-High depending on deployment:

Medium for single-user/local stdio usage or tightly scoped tokens.
High where HTTP/streamable deployments are shared, write tools are exposed, and the server has access to secrets or broad filesystem mounts.

Source Evidence

HTTP/multi-user deployment is first-class:

docs/http-transport.mdx:1-7 describes running as a persistent HTTP service for multi-user and remote deployment.
docs/http-transport.mdx:10-13 lists SSE and streamable-http endpoints.
docs/http-transport.mdx:88-90 says both HTTP transports support per-request authentication.
docs/advanced/docker-production.mdx:25-37 shows Docker deployment with .env, exposed ports, and HOST=0.0.0.0.
docs/advanced/docker-production.mdx:91-103 shows Atlassian credentials stored in .env.
src/mcp_atlassian/__init__.py:359-363 defaults HTTP host to 0.0.0.0 unless overridden.

The Confluence upload path reads caller-chosen server-local files:

src/mcp_atlassian/servers/confluence.py:1290-1315 exposes file_path and explicitly accepts absolute or relative paths.
src/mcp_atlassian/servers/confluence.py:1356-1363 passes file_path to confluence_fetcher.upload_attachment.
src/mcp_atlassian/confluence/attachments.py:62-70 only converts relative paths to absolute and checks existence.
src/mcp_atlassian/confluence/attachments.py:77-80 passes the path to _upload_attachment_direct.
src/mcp_atlassian/confluence/attachments.py:477 opens file_path for the multipart upload.

The Jira update path can also upload caller-chosen server-local files:

src/mcp_atlassian/servers/jira.py:1564-1568 exposes jira_update_issue as a write tool in toolset:jira_issues.
src/mcp_atlassian/servers/jira.py:1609-1618 accepts attachments as a JSON array or comma-separated list of file paths.
src/mcp_atlassian/servers/jira.py:1648-1674 parses those file paths and adds them to the update payload.
src/mcp_atlassian/jira/issues.py:1132-1137 forwards attachments to upload_attachments.
src/mcp_atlassian/jira/attachments.py:372-389 converts relative paths to absolute, checks existence, opens the path, and passes it to jira.add_attachment.

Existing controls do not authorize the upload source path:

src/mcp_atlassian/utils/decorators.py:45-72 blocks writes only when read-only mode is enabled.
src/mcp_atlassian/servers/main.py:276-279 filters write tools out of listing only in read-only mode.
src/mcp_atlassian/utils/toolsets.py:158-183 currently enables all toolsets when TOOLSETS is unset.
docs/advanced/docker-production.mdx:109-119 documents READ_ONLY_MODE=true as an optional production hardening setting, not a default.
src/mcp_atlassian/confluence/attachments.py:217-223 and src/mcp_atlassian/jira/attachments.py:37-43 show validate_safe_path exists for download destinations, but no equivalent upload-source containment is applied.

Root cause

The codebase already has a path-containment primitive (validate_safe_path) and applies it to download destinations to prevent writes outside a configured base directory — that is, it correctly defends the filesystem-write side of the boundary. But the upload-source side of the same boundary is not defended at all: the Confluence and Jira attachment paths convert caller-supplied paths to absolute, check that the file exists, open it, and stream the bytes to Atlassian, with no equivalent "must resolve inside an upload base directory" check. The authorization model implicitly treats "the MCP process can read this file" as equivalent to "the MCP caller is authorized to upload this file," which is correct only for single-user stdio mode. For HTTP/SSE multi-user mode (which the project documents as first-class and ships with HOST=0.0.0.0), it is not — caller identity and process filesystem-read capability are different boundaries. The structural fix is to apply the existing validate_safe_path containment primitive to upload-source paths under a separate UPLOAD_BASE_DIR configuration, and to disable server-local upload tools by default in HTTP transport mode unless that base directory is configured.

Auth boundary violated

Boundary: Per-user resource ownership (in HTTP/SSE multi-user mode, an authenticated MCP caller's tool surface should expose only files the caller is authorized to upload — not arbitrary files in the MCP process's filesystem view, including operator-mounted secrets and other tenants' data).

Respected at: src/mcp_atlassian/confluence/attachments.py:217-223 and src/mcp_atlassian/jira/attachments.py:37-43 (validate_safe_path is correctly applied to download-destination paths to prevent writes outside a base directory).

Violated at: src/mcp_atlassian/confluence/attachments.py:62-70,77-80,477 (Confluence upload path: relative-to-absolute conversion, existence check, then open(file_path), with no validate_safe_path call against an upload base directory) and src/mcp_atlassian/jira/attachments.py:372-389 (Jira upload path: identical pattern). The boundary is silently dropped: the same containment primitive that defends the download side is not invoked on the upload side.

Reproduction

Observed:

CONFLUENCE_SINK content_id=attacker-visible-page-id filename=mcp-atlassian-poc-secret.txt
CONFLUENCE_EXFIL_MARKER=FAKE_SECRET_MARKER_DO_NOT_PUBLISH_REAL_SECRET
CONFLUENCE_RESULT={'success': True, 'filename': 'mcp-atlassian-poc-secret.txt'}
JIRA_SINK issue_key=ATTACKER-1 filename=mcp-atlassian-poc-secret.txt
JIRA_EXFIL_MARKER=FAKE_SECRET_MARKER_DO_NOT_PUBLISH_REAL_SECRET
JIRA_RESULT={'success': True, 'filename': 'mcp-atlassian-poc-secret.txt'}

The PoC uses fake upload sinks and does not contact Atlassian. It demonstrates the vulnerable behavior: a caller-provided absolute server-local path is accepted, read, and delivered to the attachment sink.

Known Issue / Dupe Checks

Known advisories are different:

GHSA-xjgw-4wvw-rgm4: arbitrary file write through unconstrained Confluence download path.
GHSA-7r34-79r5-rcc9: SSRF through unvalidated Atlassian URL headers.

Closest public non-security overlap:

issue #618: usability report that upload requires server-side paths.
issue #1163: unrelated upload failure on Data Center.
PRs #987 / #949: download-path hardening, not upload-source path containment.

No public issue/PR/advisory found for upload-side arbitrary local file read.

Suggested Fix

Add an explicit upload source policy, for example:

require MCP_ATLASSIAN_UPLOAD_BASE_DIR for server-local upload tools in HTTP/SSE/streamable mode
reject absolute paths unless they resolve inside that configured base directory
apply validate_safe_path(path, base_dir=upload_base_dir) before existence checks or reads
consider disabling server-local upload tools by default in HTTP mode unless an upload directory is configured

Add regression tests for both Confluence and Jira upload paths:

reject /etc/passwd
reject ../../../etc/passwd
reject symlinks escaping the upload base
accept a file inside the configured upload directory
verify READ_ONLY_MODE=true still blocks the write independently

Severity

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

Show details on source website

JSON

To clipboard

{
  "affected": [
    {
      "package": {
        "ecosystem": "PyPI",
        "name": "mcp-atlassian"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            },
            {
              "fixed": "0.22.0"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [
    "CVE-2026-77257"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-22"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2026-09-22T20:34:58Z",
    "nvd_published_at": null,
    "severity": "HIGH"
  },
  "details": "# sooperset/mcp-atlassian: HTTP upload tools can attach arbitrary server-local files\n\nDate: 2026-05-05\nTarget: `sooperset/mcp-atlassian`\nCommit: `d8bc78698a63cb6b321c7ca796d6329d448f7f6d`\n\n## Summary\n\n`mcp-atlassian` supports HTTP/SSE deployment for persistent, remote, and multi-user use. In that mode, write-capable Jira and Confluence attachment flows accept caller-controlled server-local file paths and read those paths without an upload-source allowlist or base directory restriction.\n\nAn authenticated caller, or a prompt-injected agent with tool-call capability, can cause the MCP server process to read a local file it can access and attach that file into a Jira issue or Confluence page using configured Atlassian credentials.\n\nThis is distinct from the prior download-path advisory: that issue was an arbitrary file write sink. This path is upload-source local file disclosure.\n\n## Impact\n\nImpact is local file disclosure through an authenticated Atlassian attachment write. In Docker/Kubernetes deployments that mount `.env` or token material into the service, exposed files may include API tokens, OAuth credentials, service configuration, or other local secrets readable by the MCP process.\n\nThe issue is bounded by tool access and Atlassian permissions: the attacker needs an MCP call path to a write tool and an issue/page where the attachment can be written. It is not direct RCE.\n\nSeverity is Medium-to-High depending on deployment:\n\n- Medium for single-user/local stdio usage or tightly scoped tokens.\n- High where HTTP/streamable deployments are shared, write tools are exposed, and the server has access to secrets or broad filesystem mounts.\n\n## Source Evidence\n\nHTTP/multi-user deployment is first-class:\n\n- `docs/http-transport.mdx:1-7` describes running as a persistent HTTP service for multi-user and remote deployment.\n- `docs/http-transport.mdx:10-13` lists SSE and streamable-http endpoints.\n- `docs/http-transport.mdx:88-90` says both HTTP transports support per-request authentication.\n- `docs/advanced/docker-production.mdx:25-37` shows Docker deployment with `.env`, exposed ports, and `HOST=0.0.0.0`.\n- `docs/advanced/docker-production.mdx:91-103` shows Atlassian credentials stored in `.env`.\n- `src/mcp_atlassian/__init__.py:359-363` defaults HTTP host to `0.0.0.0` unless overridden.\n\nThe Confluence upload path reads caller-chosen server-local files:\n\n- `src/mcp_atlassian/servers/confluence.py:1290-1315` exposes `file_path` and explicitly accepts absolute or relative paths.\n- `src/mcp_atlassian/servers/confluence.py:1356-1363` passes `file_path` to `confluence_fetcher.upload_attachment`.\n- `src/mcp_atlassian/confluence/attachments.py:62-70` only converts relative paths to absolute and checks existence.\n- `src/mcp_atlassian/confluence/attachments.py:77-80` passes the path to `_upload_attachment_direct`.\n- `src/mcp_atlassian/confluence/attachments.py:477` opens `file_path` for the multipart upload.\n\nThe Jira update path can also upload caller-chosen server-local files:\n\n- `src/mcp_atlassian/servers/jira.py:1564-1568` exposes `jira_update_issue` as a write tool in `toolset:jira_issues`.\n- `src/mcp_atlassian/servers/jira.py:1609-1618` accepts `attachments` as a JSON array or comma-separated list of file paths.\n- `src/mcp_atlassian/servers/jira.py:1648-1674` parses those file paths and adds them to the update payload.\n- `src/mcp_atlassian/jira/issues.py:1132-1137` forwards `attachments` to `upload_attachments`.\n- `src/mcp_atlassian/jira/attachments.py:372-389` converts relative paths to absolute, checks existence, opens the path, and passes it to `jira.add_attachment`.\n\nExisting controls do not authorize the upload source path:\n\n- `src/mcp_atlassian/utils/decorators.py:45-72` blocks writes only when read-only mode is enabled.\n- `src/mcp_atlassian/servers/main.py:276-279` filters write tools out of listing only in read-only mode.\n- `src/mcp_atlassian/utils/toolsets.py:158-183` currently enables all toolsets when `TOOLSETS` is unset.\n- `docs/advanced/docker-production.mdx:109-119` documents `READ_ONLY_MODE=true` as an optional production hardening setting, not a default.\n- `src/mcp_atlassian/confluence/attachments.py:217-223` and `src/mcp_atlassian/jira/attachments.py:37-43` show `validate_safe_path` exists for download destinations, but no equivalent upload-source containment is applied.\n\n## Root cause\n\nThe codebase already has a path-containment primitive (`validate_safe_path`) and applies it to download destinations to prevent writes outside a configured base directory \u2014 that is, it correctly defends the filesystem-write side of the boundary. But the upload-source side of the same boundary is not defended at all: the Confluence and Jira attachment paths convert caller-supplied paths to absolute, check that the file exists, open it, and stream the bytes to Atlassian, with no equivalent \"must resolve inside an upload base directory\" check. The authorization model implicitly treats \"the MCP process can read this file\" as equivalent to \"the MCP caller is authorized to upload this file,\" which is correct only for single-user stdio mode. For HTTP/SSE multi-user mode (which the project documents as first-class and ships with `HOST=0.0.0.0`), it is not \u2014 caller identity and process filesystem-read capability are different boundaries. The structural fix is to apply the existing `validate_safe_path` containment primitive to upload-source paths under a separate `UPLOAD_BASE_DIR` configuration, and to disable server-local upload tools by default in HTTP transport mode unless that base directory is configured.\n\n## Auth boundary violated\n\n**Boundary:** Per-user resource ownership (in HTTP/SSE multi-user mode, an authenticated MCP caller\u0027s tool surface should expose only files the caller is authorized to upload \u2014 not arbitrary files in the MCP process\u0027s filesystem view, including operator-mounted secrets and other tenants\u0027 data).\n\n**Respected at:** `src/mcp_atlassian/confluence/attachments.py:217-223` and `src/mcp_atlassian/jira/attachments.py:37-43` (`validate_safe_path` is correctly applied to download-destination paths to prevent writes outside a base directory).\n\n**Violated at:** `src/mcp_atlassian/confluence/attachments.py:62-70,77-80,477` (Confluence upload path: relative-to-absolute conversion, existence check, then `open(file_path)`, with no `validate_safe_path` call against an upload base directory) and `src/mcp_atlassian/jira/attachments.py:372-389` (Jira upload path: identical pattern). The boundary is silently dropped: the same containment primitive that defends the download side is not invoked on the upload side.\n\n## Reproduction\n\nObserved:\n\n```text\nCONFLUENCE_SINK content_id=attacker-visible-page-id filename=mcp-atlassian-poc-secret.txt\nCONFLUENCE_EXFIL_MARKER=FAKE_SECRET_MARKER_DO_NOT_PUBLISH_REAL_SECRET\nCONFLUENCE_RESULT={\u0027success\u0027: True, \u0027filename\u0027: \u0027mcp-atlassian-poc-secret.txt\u0027}\nJIRA_SINK issue_key=ATTACKER-1 filename=mcp-atlassian-poc-secret.txt\nJIRA_EXFIL_MARKER=FAKE_SECRET_MARKER_DO_NOT_PUBLISH_REAL_SECRET\nJIRA_RESULT={\u0027success\u0027: True, \u0027filename\u0027: \u0027mcp-atlassian-poc-secret.txt\u0027}\n```\n\nThe PoC uses fake upload sinks and does not contact Atlassian. It demonstrates the vulnerable behavior: a caller-provided absolute server-local path is accepted, read, and delivered to the attachment sink.\n\n## Known Issue / Dupe Checks\n\nKnown advisories are different:\n\n- `GHSA-xjgw-4wvw-rgm4`: arbitrary file write through unconstrained Confluence download path.\n- `GHSA-7r34-79r5-rcc9`: SSRF through unvalidated Atlassian URL headers.\n\nClosest public non-security overlap:\n\n- issue `#618`: usability report that upload requires server-side paths.\n- issue `#1163`: unrelated upload failure on Data Center.\n- PRs `#987` / `#949`: download-path hardening, not upload-source path containment.\n\nNo public issue/PR/advisory found for upload-side arbitrary local file read.\n\n## Suggested Fix\n\nAdd an explicit upload source policy, for example:\n\n- require `MCP_ATLASSIAN_UPLOAD_BASE_DIR` for server-local upload tools in HTTP/SSE/streamable mode\n- reject absolute paths unless they resolve inside that configured base directory\n- apply `validate_safe_path(path, base_dir=upload_base_dir)` before existence checks or reads\n- consider disabling server-local upload tools by default in HTTP mode unless an upload directory is configured\n\nAdd regression tests for both Confluence and Jira upload paths:\n\n- reject `/etc/passwd`\n- reject `../../../etc/passwd`\n- reject symlinks escaping the upload base\n- accept a file inside the configured upload directory\n- verify `READ_ONLY_MODE=true` still blocks the write independently",
  "id": "GHSA-mrq8-fv7v-hhjg",
  "modified": "2026-09-22T20:34:58Z",
  "published": "2026-09-22T20:34:58Z",
  "references": [
    {
      "type": "WEB",
      "url": "https://github.com/sooperset/mcp-atlassian/security/advisories/GHSA-mrq8-fv7v-hhjg"
    },
    {
      "type": "WEB",
      "url": "https://github.com/sooperset/mcp-atlassian/pull/1448"
    },
    {
      "type": "WEB",
      "url": "https://github.com/sooperset/mcp-atlassian/commit/b041733473f95119dd539542a43c280737a8e460"
    },
    {
      "type": "PACKAGE",
      "url": "https://github.com/sooperset/mcp-atlassian"
    },
    {
      "type": "WEB",
      "url": "https://github.com/sooperset/mcp-atlassian/releases/tag/v0.22.0"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "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",
      "type": "CVSS_V4"
    }
  ],
  "summary": "MCP Atlassian: HTTP upload tools accept arbitrary server-local file paths"
}

CVE-2026-77257 (GCVE-0-2026-77257)

Vulnerability from cvelistv5 – Published: 2026-09-22 18:08 – Updated: 2026-09-23 14:37

Title

MCP Atlassian: HTTP upload tools accept arbitrary server-local file paths

Summary

MCP Atlassian is a Model Context Protocol (MCP) server for Atlassian products (Confluence and Jira). Prior to 0.22.0, HTTP-exposed Jira and Confluence upload tools pass a caller-provided file_path to local file operations without restricting it to the workspace. A remote MCP caller with tool access can cause the server to read sensitive local files and upload them as Atlassian attachments. The advisory traces the vulnerable input and processing flow through streamable-http, upload_attachment, and file_path, which identify the affected entry points, controls, and code paths. This issue is fixed in version 0.22.0.

Severity

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

SSVC

Exploitation: none Automatable: no Technical Impact: partial

CISA Coordinator · CISA-ADP (v2.0.3)

Decision recorded 2026-09-22 19:09 UTC

CWE

CWE-22 - Improper Limitation of a Pathname to a Restricted Directory ('Path Traversal')

Assigner

GitHub_M mitre root Scorecard

References

4 references

URL	Tags
https://github.com/sooperset/mcp-atlassian/securi…	x_refsource_CONFIRM
https://github.com/sooperset/mcp-atlassian/pull/1448	x_refsource_MISC
https://github.com/sooperset/mcp-atlassian/commit…	x_refsource_MISC
https://github.com/sooperset/mcp-atlassian/releas…	x_refsource_MISC

Impacted products

1 product

Vendor	Product	Version
sooperset	mcp-atlassian	Affected: < 0.22.0

Show details on NVD website

JSON

To clipboard

{
  "containers": {
    "adp": [
      {
        "metrics": [
          {
            "other": {
              "content": {
                "id": "CVE-2026-77257",
                "options": [
                  {
                    "Exploitation": "none"
                  },
                  {
                    "Automatable": "no"
                  },
                  {
                    "Technical Impact": "partial"
                  }
                ],
                "role": "CISA Coordinator",
                "timestamp": "2026-09-22T19:09:46.956170Z",
                "version": "2.0.3"
              },
              "type": "ssvc"
            }
          }
        ],
        "providerMetadata": {
          "dateUpdated": "2026-09-23T14:37:52.861Z",
          "orgId": "134c704f-9b21-4f2e-91b3-4a467353bcc0",
          "shortName": "CISA-ADP"
        },
        "title": "CISA ADP Vulnrichment"
      }
    ],
    "cna": {
      "affected": [
        {
          "product": "mcp-atlassian",
          "vendor": "sooperset",
          "versions": [
            {
              "status": "affected",
              "version": "\u003c 0.22.0"
            }
          ]
        }
      ],
      "descriptions": [
        {
          "lang": "en",
          "value": "MCP Atlassian is a Model Context Protocol (MCP) server for Atlassian products (Confluence and Jira). Prior to 0.22.0, HTTP-exposed Jira and Confluence upload tools pass a caller-provided file_path to local file operations without restricting it to the workspace. A remote MCP caller with tool access can cause the server to read sensitive local files and upload them as Atlassian attachments. The advisory traces the vulnerable input and processing flow through streamable-http, upload_attachment, and file_path, which identify the affected entry points, controls, and code paths. This issue is fixed in version 0.22.0."
        }
      ],
      "metrics": [
        {
          "cvssV4_0": {
            "attackComplexity": "LOW",
            "attackRequirements": "NONE",
            "attackVector": "NETWORK",
            "baseScore": 8.3,
            "baseSeverity": "HIGH",
            "privilegesRequired": "LOW",
            "subAvailabilityImpact": "NONE",
            "subConfidentialityImpact": "HIGH",
            "subIntegrityImpact": "NONE",
            "userInteraction": "NONE",
            "vectorString": "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",
            "version": "4.0",
            "vulnAvailabilityImpact": "NONE",
            "vulnConfidentialityImpact": "HIGH",
            "vulnIntegrityImpact": "NONE"
          }
        }
      ],
      "problemTypes": [
        {
          "descriptions": [
            {
              "cweId": "CWE-22",
              "description": "CWE-22: Improper Limitation of a Pathname to a Restricted Directory (\u0027Path Traversal\u0027)",
              "lang": "en",
              "type": "CWE"
            }
          ]
        }
      ],
      "providerMetadata": {
        "dateUpdated": "2026-09-22T18:08:48.501Z",
        "orgId": "a0819718-46f1-4df5-94e2-005712e83aaa",
        "shortName": "GitHub_M"
      },
      "references": [
        {
          "name": "https://github.com/sooperset/mcp-atlassian/security/advisories/GHSA-mrq8-fv7v-hhjg",
          "tags": [
            "x_refsource_CONFIRM"
          ],
          "url": "https://github.com/sooperset/mcp-atlassian/security/advisories/GHSA-mrq8-fv7v-hhjg"
        },
        {
          "name": "https://github.com/sooperset/mcp-atlassian/pull/1448",
          "tags": [
            "x_refsource_MISC"
          ],
          "url": "https://github.com/sooperset/mcp-atlassian/pull/1448"
        },
        {
          "name": "https://github.com/sooperset/mcp-atlassian/commit/b041733473f95119dd539542a43c280737a8e460",
          "tags": [
            "x_refsource_MISC"
          ],
          "url": "https://github.com/sooperset/mcp-atlassian/commit/b041733473f95119dd539542a43c280737a8e460"
        },
        {
          "name": "https://github.com/sooperset/mcp-atlassian/releases/tag/v0.22.0",
          "tags": [
            "x_refsource_MISC"
          ],
          "url": "https://github.com/sooperset/mcp-atlassian/releases/tag/v0.22.0"
        }
      ],
      "source": {
        "advisory": "GHSA-mrq8-fv7v-hhjg",
        "discovery": "UNKNOWN"
      },
      "title": "MCP Atlassian: HTTP upload tools accept arbitrary server-local file paths"
    }
  },
  "cveMetadata": {
    "assignerOrgId": "a0819718-46f1-4df5-94e2-005712e83aaa",
    "assignerShortName": "GitHub_M",
    "cveId": "CVE-2026-77257",
    "datePublished": "2026-09-22T18:08:48.501Z",
    "dateReserved": "2026-08-20T19:02:23.417Z",
    "dateUpdated": "2026-09-23T14:37:52.861Z",
    "state": "PUBLISHED"
  },
  "dataType": "CVE_RECORD",
  "dataVersion": "5.2"
}

PYSEC-2026-4098

Vulnerability from pysec - Published: 2026-10-01 16:38 - Updated: 2026-10-01 17:10

Details

sooperset/mcp-atlassian: HTTP upload tools can attach arbitrary server-local files

Date: 2026-05-05 Target: sooperset/mcp-atlassian Commit: d8bc78698a63cb6b321c7ca796d6329d448f7f6d

Summary

This is distinct from the prior download-path advisory: that issue was an arbitrary file write sink. This path is upload-source local file disclosure.

Impact

The issue is bounded by tool access and Atlassian permissions: the attacker needs an MCP call path to a write tool and an issue/page where the attachment can be written. It is not direct RCE.

Severity is Medium-to-High depending on deployment:

Medium for single-user/local stdio usage or tightly scoped tokens.
High where HTTP/streamable deployments are shared, write tools are exposed, and the server has access to secrets or broad filesystem mounts.

Source Evidence

HTTP/multi-user deployment is first-class:

docs/http-transport.mdx:1-7 describes running as a persistent HTTP service for multi-user and remote deployment.
docs/http-transport.mdx:10-13 lists SSE and streamable-http endpoints.
docs/http-transport.mdx:88-90 says both HTTP transports support per-request authentication.
docs/advanced/docker-production.mdx:25-37 shows Docker deployment with .env, exposed ports, and HOST=0.0.0.0.
docs/advanced/docker-production.mdx:91-103 shows Atlassian credentials stored in .env.
src/mcp_atlassian/__init__.py:359-363 defaults HTTP host to 0.0.0.0 unless overridden.

The Confluence upload path reads caller-chosen server-local files:

src/mcp_atlassian/servers/confluence.py:1290-1315 exposes file_path and explicitly accepts absolute or relative paths.
src/mcp_atlassian/servers/confluence.py:1356-1363 passes file_path to confluence_fetcher.upload_attachment.
src/mcp_atlassian/confluence/attachments.py:62-70 only converts relative paths to absolute and checks existence.
src/mcp_atlassian/confluence/attachments.py:77-80 passes the path to _upload_attachment_direct.
src/mcp_atlassian/confluence/attachments.py:477 opens file_path for the multipart upload.

The Jira update path can also upload caller-chosen server-local files:

src/mcp_atlassian/servers/jira.py:1564-1568 exposes jira_update_issue as a write tool in toolset:jira_issues.
src/mcp_atlassian/servers/jira.py:1609-1618 accepts attachments as a JSON array or comma-separated list of file paths.
src/mcp_atlassian/servers/jira.py:1648-1674 parses those file paths and adds them to the update payload.
src/mcp_atlassian/jira/issues.py:1132-1137 forwards attachments to upload_attachments.
src/mcp_atlassian/jira/attachments.py:372-389 converts relative paths to absolute, checks existence, opens the path, and passes it to jira.add_attachment.

Existing controls do not authorize the upload source path:

src/mcp_atlassian/utils/decorators.py:45-72 blocks writes only when read-only mode is enabled.
src/mcp_atlassian/servers/main.py:276-279 filters write tools out of listing only in read-only mode.
src/mcp_atlassian/utils/toolsets.py:158-183 currently enables all toolsets when TOOLSETS is unset.
docs/advanced/docker-production.mdx:109-119 documents READ_ONLY_MODE=true as an optional production hardening setting, not a default.
src/mcp_atlassian/confluence/attachments.py:217-223 and src/mcp_atlassian/jira/attachments.py:37-43 show validate_safe_path exists for download destinations, but no equivalent upload-source containment is applied.

Root cause

Auth boundary violated

Reproduction

Observed:

CONFLUENCE_SINK content_id=attacker-visible-page-id filename=mcp-atlassian-poc-secret.txt
CONFLUENCE_EXFIL_MARKER=FAKE_SECRET_MARKER_DO_NOT_PUBLISH_REAL_SECRET
CONFLUENCE_RESULT={'success': True, 'filename': 'mcp-atlassian-poc-secret.txt'}
JIRA_SINK issue_key=ATTACKER-1 filename=mcp-atlassian-poc-secret.txt
JIRA_EXFIL_MARKER=FAKE_SECRET_MARKER_DO_NOT_PUBLISH_REAL_SECRET
JIRA_RESULT={'success': True, 'filename': 'mcp-atlassian-poc-secret.txt'}

Known Issue / Dupe Checks

Known advisories are different:

GHSA-xjgw-4wvw-rgm4: arbitrary file write through unconstrained Confluence download path.
GHSA-7r34-79r5-rcc9: SSRF through unvalidated Atlassian URL headers.

Closest public non-security overlap:

issue #618: usability report that upload requires server-side paths.
issue #1163: unrelated upload failure on Data Center.
PRs #987 / #949: download-path hardening, not upload-source path containment.

No public issue/PR/advisory found for upload-side arbitrary local file read.

Suggested Fix

Add an explicit upload source policy, for example:

require MCP_ATLASSIAN_UPLOAD_BASE_DIR for server-local upload tools in HTTP/SSE/streamable mode
reject absolute paths unless they resolve inside that configured base directory
apply validate_safe_path(path, base_dir=upload_base_dir) before existence checks or reads
consider disabling server-local upload tools by default in HTTP mode unless an upload directory is configured

Add regression tests for both Confluence and Jira upload paths:

reject /etc/passwd
reject ../../../etc/passwd
reject symlinks escaping the upload base
accept a file inside the configured upload directory
verify READ_ONLY_MODE=true still blocks the write independently

Severity

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

Impacted products

Name	purl
mcp-atlassian	pkg:pypi/mcp-atlassian

Aliases

JSON

To clipboard

{
  "affected": [
    {
      "package": {
        "ecosystem": "PyPI",
        "name": "mcp-atlassian",
        "purl": "pkg:pypi/mcp-atlassian"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            },
            {
              "fixed": "0.22.0"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ],
      "versions": [
        "0.1.1",
        "0.1.10",
        "0.1.11",
        "0.1.12",
        "0.1.13",
        "0.1.14",
        "0.1.15",
        "0.1.16",
        "0.1.2",
        "0.1.3",
        "0.1.4",
        "0.1.6",
        "0.1.7",
        "0.1.8",
        "0.1.9",
        "0.10.0",
        "0.10.1",
        "0.10.2",
        "0.10.3",
        "0.10.4",
        "0.10.5",
        "0.10.6",
        "0.11.0",
        "0.11.1",
        "0.11.10",
        "0.11.11",
        "0.11.12",
        "0.11.2",
        "0.11.2a2",
        "0.11.3",
        "0.11.4",
        "0.11.5",
        "0.11.6",
        "0.11.7",
        "0.11.8",
        "0.11.9",
        "0.12.0",
        "0.13.0",
        "0.13.1",
        "0.14.0",
        "0.14.1",
        "0.14.2",
        "0.14.3",
        "0.15.0",
        "0.16.0",
        "0.16.1",
        "0.17.0",
        "0.18.0",
        "0.18.1",
        "0.19.0",
        "0.2.0",
        "0.2.1",
        "0.2.2",
        "0.2.3",
        "0.2.4",
        "0.2.5",
        "0.2.6",
        "0.20.0",
        "0.20.1",
        "0.21.0",
        "0.21.1",
        "0.3.0",
        "0.3.1",
        "0.4.0",
        "0.5.0",
        "0.6.0",
        "0.6.1",
        "0.6.2",
        "0.6.3",
        "0.6.4",
        "0.6.5",
        "0.7.0",
        "0.7.1",
        "0.8.0",
        "0.8.1",
        "0.8.2",
        "0.8.3",
        "0.8.4",
        "0.9.0"
      ]
    }
  ],
  "aliases": [
    "CVE-2026-77257",
    "GHSA-mrq8-fv7v-hhjg"
  ],
  "details": "# sooperset/mcp-atlassian: HTTP upload tools can attach arbitrary server-local files\n\nDate: 2026-05-05\nTarget: `sooperset/mcp-atlassian`\nCommit: `d8bc78698a63cb6b321c7ca796d6329d448f7f6d`\n\n## Summary\n\n`mcp-atlassian` supports HTTP/SSE deployment for persistent, remote, and multi-user use. In that mode, write-capable Jira and Confluence attachment flows accept caller-controlled server-local file paths and read those paths without an upload-source allowlist or base directory restriction.\n\nAn authenticated caller, or a prompt-injected agent with tool-call capability, can cause the MCP server process to read a local file it can access and attach that file into a Jira issue or Confluence page using configured Atlassian credentials.\n\nThis is distinct from the prior download-path advisory: that issue was an arbitrary file write sink. This path is upload-source local file disclosure.\n\n## Impact\n\nImpact is local file disclosure through an authenticated Atlassian attachment write. In Docker/Kubernetes deployments that mount `.env` or token material into the service, exposed files may include API tokens, OAuth credentials, service configuration, or other local secrets readable by the MCP process.\n\nThe issue is bounded by tool access and Atlassian permissions: the attacker needs an MCP call path to a write tool and an issue/page where the attachment can be written. It is not direct RCE.\n\nSeverity is Medium-to-High depending on deployment:\n\n- Medium for single-user/local stdio usage or tightly scoped tokens.\n- High where HTTP/streamable deployments are shared, write tools are exposed, and the server has access to secrets or broad filesystem mounts.\n\n## Source Evidence\n\nHTTP/multi-user deployment is first-class:\n\n- `docs/http-transport.mdx:1-7` describes running as a persistent HTTP service for multi-user and remote deployment.\n- `docs/http-transport.mdx:10-13` lists SSE and streamable-http endpoints.\n- `docs/http-transport.mdx:88-90` says both HTTP transports support per-request authentication.\n- `docs/advanced/docker-production.mdx:25-37` shows Docker deployment with `.env`, exposed ports, and `HOST=0.0.0.0`.\n- `docs/advanced/docker-production.mdx:91-103` shows Atlassian credentials stored in `.env`.\n- `src/mcp_atlassian/__init__.py:359-363` defaults HTTP host to `0.0.0.0` unless overridden.\n\nThe Confluence upload path reads caller-chosen server-local files:\n\n- `src/mcp_atlassian/servers/confluence.py:1290-1315` exposes `file_path` and explicitly accepts absolute or relative paths.\n- `src/mcp_atlassian/servers/confluence.py:1356-1363` passes `file_path` to `confluence_fetcher.upload_attachment`.\n- `src/mcp_atlassian/confluence/attachments.py:62-70` only converts relative paths to absolute and checks existence.\n- `src/mcp_atlassian/confluence/attachments.py:77-80` passes the path to `_upload_attachment_direct`.\n- `src/mcp_atlassian/confluence/attachments.py:477` opens `file_path` for the multipart upload.\n\nThe Jira update path can also upload caller-chosen server-local files:\n\n- `src/mcp_atlassian/servers/jira.py:1564-1568` exposes `jira_update_issue` as a write tool in `toolset:jira_issues`.\n- `src/mcp_atlassian/servers/jira.py:1609-1618` accepts `attachments` as a JSON array or comma-separated list of file paths.\n- `src/mcp_atlassian/servers/jira.py:1648-1674` parses those file paths and adds them to the update payload.\n- `src/mcp_atlassian/jira/issues.py:1132-1137` forwards `attachments` to `upload_attachments`.\n- `src/mcp_atlassian/jira/attachments.py:372-389` converts relative paths to absolute, checks existence, opens the path, and passes it to `jira.add_attachment`.\n\nExisting controls do not authorize the upload source path:\n\n- `src/mcp_atlassian/utils/decorators.py:45-72` blocks writes only when read-only mode is enabled.\n- `src/mcp_atlassian/servers/main.py:276-279` filters write tools out of listing only in read-only mode.\n- `src/mcp_atlassian/utils/toolsets.py:158-183` currently enables all toolsets when `TOOLSETS` is unset.\n- `docs/advanced/docker-production.mdx:109-119` documents `READ_ONLY_MODE=true` as an optional production hardening setting, not a default.\n- `src/mcp_atlassian/confluence/attachments.py:217-223` and `src/mcp_atlassian/jira/attachments.py:37-43` show `validate_safe_path` exists for download destinations, but no equivalent upload-source containment is applied.\n\n## Root cause\n\nThe codebase already has a path-containment primitive (`validate_safe_path`) and applies it to download destinations to prevent writes outside a configured base directory \u2014 that is, it correctly defends the filesystem-write side of the boundary. But the upload-source side of the same boundary is not defended at all: the Confluence and Jira attachment paths convert caller-supplied paths to absolute, check that the file exists, open it, and stream the bytes to Atlassian, with no equivalent \"must resolve inside an upload base directory\" check. The authorization model implicitly treats \"the MCP process can read this file\" as equivalent to \"the MCP caller is authorized to upload this file,\" which is correct only for single-user stdio mode. For HTTP/SSE multi-user mode (which the project documents as first-class and ships with `HOST=0.0.0.0`), it is not \u2014 caller identity and process filesystem-read capability are different boundaries. The structural fix is to apply the existing `validate_safe_path` containment primitive to upload-source paths under a separate `UPLOAD_BASE_DIR` configuration, and to disable server-local upload tools by default in HTTP transport mode unless that base directory is configured.\n\n## Auth boundary violated\n\n**Boundary:** Per-user resource ownership (in HTTP/SSE multi-user mode, an authenticated MCP caller\u0027s tool surface should expose only files the caller is authorized to upload \u2014 not arbitrary files in the MCP process\u0027s filesystem view, including operator-mounted secrets and other tenants\u0027 data).\n\n**Respected at:** `src/mcp_atlassian/confluence/attachments.py:217-223` and `src/mcp_atlassian/jira/attachments.py:37-43` (`validate_safe_path` is correctly applied to download-destination paths to prevent writes outside a base directory).\n\n**Violated at:** `src/mcp_atlassian/confluence/attachments.py:62-70,77-80,477` (Confluence upload path: relative-to-absolute conversion, existence check, then `open(file_path)`, with no `validate_safe_path` call against an upload base directory) and `src/mcp_atlassian/jira/attachments.py:372-389` (Jira upload path: identical pattern). The boundary is silently dropped: the same containment primitive that defends the download side is not invoked on the upload side.\n\n## Reproduction\n\nObserved:\n\n```text\nCONFLUENCE_SINK content_id=attacker-visible-page-id filename=mcp-atlassian-poc-secret.txt\nCONFLUENCE_EXFIL_MARKER=FAKE_SECRET_MARKER_DO_NOT_PUBLISH_REAL_SECRET\nCONFLUENCE_RESULT={\u0027success\u0027: True, \u0027filename\u0027: \u0027mcp-atlassian-poc-secret.txt\u0027}\nJIRA_SINK issue_key=ATTACKER-1 filename=mcp-atlassian-poc-secret.txt\nJIRA_EXFIL_MARKER=FAKE_SECRET_MARKER_DO_NOT_PUBLISH_REAL_SECRET\nJIRA_RESULT={\u0027success\u0027: True, \u0027filename\u0027: \u0027mcp-atlassian-poc-secret.txt\u0027}\n```\n\nThe PoC uses fake upload sinks and does not contact Atlassian. It demonstrates the vulnerable behavior: a caller-provided absolute server-local path is accepted, read, and delivered to the attachment sink.\n\n## Known Issue / Dupe Checks\n\nKnown advisories are different:\n\n- `GHSA-xjgw-4wvw-rgm4`: arbitrary file write through unconstrained Confluence download path.\n- `GHSA-7r34-79r5-rcc9`: SSRF through unvalidated Atlassian URL headers.\n\nClosest public non-security overlap:\n\n- issue `#618`: usability report that upload requires server-side paths.\n- issue `#1163`: unrelated upload failure on Data Center.\n- PRs `#987` / `#949`: download-path hardening, not upload-source path containment.\n\nNo public issue/PR/advisory found for upload-side arbitrary local file read.\n\n## Suggested Fix\n\nAdd an explicit upload source policy, for example:\n\n- require `MCP_ATLASSIAN_UPLOAD_BASE_DIR` for server-local upload tools in HTTP/SSE/streamable mode\n- reject absolute paths unless they resolve inside that configured base directory\n- apply `validate_safe_path(path, base_dir=upload_base_dir)` before existence checks or reads\n- consider disabling server-local upload tools by default in HTTP mode unless an upload directory is configured\n\nAdd regression tests for both Confluence and Jira upload paths:\n\n- reject `/etc/passwd`\n- reject `../../../etc/passwd`\n- reject symlinks escaping the upload base\n- accept a file inside the configured upload directory\n- verify `READ_ONLY_MODE=true` still blocks the write independently",
  "id": "PYSEC-2026-4098",
  "modified": "2026-10-01T17:10:31.102600Z",
  "published": "2026-10-01T16:38:35.260800Z",
  "references": [
    {
      "type": "WEB",
      "url": "https://github.com/sooperset/mcp-atlassian/security/advisories/GHSA-mrq8-fv7v-hhjg"
    },
    {
      "type": "WEB",
      "url": "https://github.com/sooperset/mcp-atlassian/pull/1448"
    },
    {
      "type": "WEB",
      "url": "https://github.com/sooperset/mcp-atlassian/commit/b041733473f95119dd539542a43c280737a8e460"
    },
    {
      "type": "PACKAGE",
      "url": "https://github.com/sooperset/mcp-atlassian"
    },
    {
      "type": "WEB",
      "url": "https://github.com/sooperset/mcp-atlassian/releases/tag/v0.22.0"
    },
    {
      "type": "PACKAGE",
      "url": "https://pypi.org/project/mcp-atlassian"
    },
    {
      "type": "ADVISORY",
      "url": "https://github.com/advisories/GHSA-mrq8-fv7v-hhjg"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-77257"
    }
  ],
  "severity": [
    {
      "score": "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",
      "type": "CVSS_V4"
    }
  ],
  "summary": "MCP Atlassian: HTTP upload tools accept arbitrary server-local file paths"
}

Sightings

Author	Source	Type	Date	Other

Nomenclature

Seen: The vulnerability was mentioned, discussed, or observed by the user.
Confirmed: The vulnerability has been validated from an analyst's perspective.
Published Proof of Concept: A public proof of concept is available for this vulnerability.
Exploited: The vulnerability was observed as exploited by the user who reported the sighting.
Patched: The vulnerability was observed as successfully patched by the user who reported the sighting.
Not exploited: The vulnerability was not observed as exploited by the user who reported the sighting.
Not confirmed: The user expressed doubt about the validity of the vulnerability.
Not patched: The vulnerability was not observed as successfully patched by the user who reported the sighting.

The MITRE ATT&CK techniques below are AI-generated suggestions, inferred from the description of the vulnerability by the CIRCL/vulnerability-attack-technique-classification-roberta-base model, served locally by ML-Gateway. They have not been verified by an analyst and are provided for guidance only.
The approach is described in our paper Mapping CVEs to MITRE ATT&CK Techniques: A Curated Gold-Set Classifier and the Limits of LLM-Assisted Label Expansion.
Browse all ATT&CK techniques and the vulnerabilities related to each.

Related by attack behaviour

Vulnerabilities whose description is nearest to this one in the vector space of the CIRCL/vulnerability-attack-technique-biencoder model. This is a similarity search over the bi-encoder space (plain cosine), not a classification, and it has no measured accuracy.

Action not permitted

GHSA-MRQ8-FV7V-HHJG

sooperset/mcp-atlassian: HTTP upload tools can attach arbitrary server-local files

Summary

Impact

Source Evidence

Root cause

Auth boundary violated

Reproduction

Known Issue / Dupe Checks

Suggested Fix

CVE-2026-77257 (GCVE-0-2026-77257)

PYSEC-2026-4098

sooperset/mcp-atlassian: HTTP upload tools can attach arbitrary server-local files

Summary

Impact

Source Evidence

Root cause

Auth boundary violated

Reproduction

Known Issue / Dupe Checks

Suggested Fix

Tags

Sightings

Nomenclature

Related by attack behaviour