Open actionable advisories and recorded vendor fixes. This public package view has no inventory attached and cannot establish whether your deployment is affected. A vendor fix never resolves your finding; verify your installed version and the source guidance.
Open advisories
30 actionable advisories, newest first. Withdrawn advisories and news are excluded. Coverage is partial.
confluenceuploadattachment passes filepath directly to open(filepath, "rb") with no path validation. Any authenticated MCP client — or an AI agent manipulated via prompt injection — can read any file the server process can access and exfiltrate it to Confluence as an attachment. Details Root cause: src/mcpatlassian/confluence/attachments.py, uploadattachmentdirect(): The fix already exists in the same file. downloadattachment() calls validatesafepath(targetpath). The developer's intent was to validate paths — upload was missed. Proven by the codebase itself. One-line fix — add before the open() call: PoC Stage 1 — Direct API (confirmed): Uploaded C:\Windows\System32\drivers\etc\hosts (826 bytes) → HTTP 200. Uploaded ~/.ssh/ided25519 (SSH private key) → HTTP 200. Stage 2 — End-to-end MCP client (confirmed against v0.21.1): Server opens file and uploads to Confluence without validation. Stage 3 — Prompt injection, no MCP credentials required (confirmed 2026-07-10): Payload…
Recommended action: Upgrade to 0.22.0 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
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 filepath 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: -…
Recommended action: Upgrade to 0.22.0 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
GHSA-7r34-79r5-rcc9's fix added validateurlforssrf, which resolves the attacker-controlled X-Atlassian-{Jira,Confluence}-Url header host once at middleware time and trusts the result. But the outbound request is later built with the raw hostname and re-resolves at connect time with no IP pinning. An attacker-controlled rebinding DNS name returns a public IP on the guard's lookup (validation passes) and 169.254.169.254 / an internal IP on the request's lookup (the socket connects there) → unauthenticated SSRF to cloud metadata / internal services on the patched build. Relationship to CVE-2026-27826 / GHSA-7r34-79r5-rcc9 (incomplete fix — please read first) This is an incomplete-fix sibling of the published GHSA-7r34-79r5-rcc9 (the X-Atlassian--Url header SSRF). That fix (PR #986/#1005) added a single middleware-time resolve + allowlist DNS-skip, but does not pin the validated IP to the connection — the fetcher re-resolves the raw hostname at connect time, so the documented…
Recommended action: Upgrade to 0.22.0 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
The confluencedownloadattachment MCP tool accepts a downloadpath parameter that is written to without any directory boundary enforcement. An attacker who can call this tool and supply or access a Confluence attachment with malicious content can write arbitrary content to any path the server process has write access to. Because the attacker controls both the write destination and the written content (via an uploaded Confluence attachment), this constitutes for arbitrary code execution (for example, writing a valid cron entry to /etc/cron.d/ achieves code execution within one scheduler cycle with no server restart required). Details The tool parameter is defined in src/mcpatlassian/servers/confluence.py:~1275 without any path restriction: python downloadpath: Annotated str, Field( description=( "Full path where the file should be saved. Can be absolute or relative. " "Examples: './downloads/report.pdf', '/tmp/image.png', 'C:\\\\temp\\\\file.docx'. " "Parent directory will be…
Recommended action: Upgrade to 0.17.0 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
An unauthenticated attacker who can reach the mcp-atlassian HTTP endpoint can force the server process to make outbound HTTP requests to an arbitrary attacker-controlled URL by supplying two custom HTTP headers without an Authorization header. No authentication is required. The vulnerability exists in the HTTP middleware and dependency injection layer — not in any MCP tool handler - making it invisible to tool-level code analysis. In cloud deployments, this could enable theft of IAM role credentials via the instance metadata endpoint (169.254.169.254). In any HTTP deployment it enables internal network reconnaissance and injection of attacker-controlled content into LLM tool results. Details The server supports a multi-tenant HTTP authentication mode where clients supply per-request Jira/Confluence URLs via custom headers. The middleware (src/mcpatlassian/servers/main.py:436–448) extracts X-Atlassian-Jira-Url from the request and stores it in request state with no validation.…
Recommended action: Upgrade to 0.17.0 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.