al-ice.ai

mcp-atlassian Let an Unauthenticated Caller Upload /etc/passwd to Their Own Server

AI Vulnerabilities & CVEs by al-ice.ai Editorial

An MCP server that bridges AI clients to Jira and Confluence sits between untrusted model context and an organization's collaboration data — and, when remotely deployed, exposes a server process, a filesystem, and an outbound network path. CVE-2026-77246, formalized as GitHub advisory GHSA-wv8v-v4c5-v75j (CVE-2026-77246) and cataloged on September 22, 2026, turned mcp-atlassian's attachment-upload tools into an unauthenticated file-exfiltration primitive: a remote caller with no account, no session, and no Authorization header could read any file the server process could read — /etc/passwd, ~/.env, SSH private keys, cloud credentials — and have the server deliver it to an attacker-controlled endpoint disguised as a Confluence upload. CVSS 3.1 rates it 7.4 High. Every release below 0.22.0 is affected; 0.22.0 is the fix.

The advisory is unusually well-evidenced: the flaw was confirmed through both static code analysis and a live Docker-based proof of concept, and the writeup traces the full seven-step data flow from HTTP middleware to the file-open sink. That traceability matters because the vulnerability is not one bug but three cooperating weaknesses — an authentication bypass, an SSRF-validation gap, and a missing path check — meeting at a single tool. Any one of them alone would have been a moderate finding. Together they are remote, unauthenticated exfiltration.

Three weaknesses, one upload

The chain starts at the HTTP layer. When mcp-atlassian runs in HTTP transport mode (streamable-http or sse), middleware extracts the Atlassian service headers X-Atlassian-Confluence-Url and X-Atlassian-Confluence-Personal-Token straight from the incoming request — and when no Authorization header is present but those service headers are, the server sets the authentication type to pat, effectively treating header possession as authentication. There is no account behind the headers. Anyone on the network can supply them.

The second weakness is the SSRF guardrail that was supposed to constrain where the configured Confluence URL may point. The validator blocks only localhost, RFC 1918 private ranges, and a small set of metadata hostnames — so any attacker-controlled public domain passes, as does an allow-listed Docker container hostname via MCP_ALLOWED_URL_DOMAINS. The attacker-supplied URL is then injected directly into the ConfluenceConfig, constructing a fetcher pointed at the attacker's server. SSRF validation that enumerates bad destinations instead of allow-listing good ones always converges on this outcome; the internet is larger than the blocklist.

The third weakness is the tool itself. The confluence_upload_attachment tool (and its Jira attachment variant) forwards the file_path argument to upload_attachment() without sanitization; the path is absolutized and checked for existence only. The codebase already has a validate_safe_path() routine — it is used on download paths — but it was never called on the upload path. The sink opens the file and sends it as multipart form data to the configured (attacker-controlled) URL. A download-path guard that was never applied to uploads is the kind of asymmetry that survives every review except the one that diffs the two call sites against each other.

Disclosed in September, fixed in July — read that as a warning

Here is the detail that changes the operational reading: the patched version is 0.22.0, released July 10 — the same coordinated hardening release this site covered in July as resolving 37 advisories across attachment handling, HTTP authentication, and SSRF. The formal advisory, CVE record, and fix commit (PR #1448) only surfaced publicly on September 22, more than two months later. Organizations that upgraded in July were protected without ever knowing this specific CVE existed; organizations that deferred the 0.22.0 upgrade because the release notes read like routine hardening sat exposed to a now-fully-documented unauthenticated exfiltration chain, complete with file paths and line numbers.

This is the recurring disclosure-lag hazard of consolidated security releases: a single version bump quietly closes dozens of holes, and each hole only gets its individual spotlight — and its scanner signature — weeks or months later. Version, not advisory date, determines exposure. Anyone whose patch prioritization keys off CVE publication dates spent the summer vulnerable to a fix that was already shipped.

What defenders should do now

  • Upgrade mcp-atlassian to 0.22.0 or later and verify the running artifact. The fix predates the disclosure by ten weeks; if you upgraded in July you are covered, but confirm the deployed version rather than assuming it.
  • Treat a remotely reachable pre-0.22.0 HTTP-mode deployment as potentially exfiltrated. Review server access logs for attachment-upload tool calls referencing absolute paths outside Confluence/Jira working directories, and for requests carrying X-Atlassian-* headers from untrusted sources.
  • Do not expose MCP HTTP transports without authentication in front of them. This CVE is the second 2026 reminder for this exact project — after March's unauthenticated RCE/SSRF pair CVE-2026-27825/27826 — that HTTP-mode MCP servers are network services first and agent accessories second. Bind to localhost, require authentication at the edge, or both.
  • Constrain the server process's filesystem view. Run with a dedicated service account, read-only root filesystem where possible, and no ambient cloud credentials or SSH keys mounted into the process. The advisory's file list — .env files, private keys, cloud credentials — is a description of what the process could see, which is a deployment choice.
  • Audit every tool argument that becomes a server-side path or URL. The upload/download asymmetry here is a pattern: wherever one direction was hardened, verify the other. Diff path-handling helpers across all tools that touch the filesystem or the network.
  • Reconcile patch posture against release versions, not advisory feeds. Build the inventory query as "which MCP server versions predate 0.22.0," not "which hosts match CVE-2026-77246," or the next consolidated release will blindside you the same way.

The weakness taxonomy tells the deeper story: CWE-200 (sensitive-information exposure), CWE-22 (path traversal), and CWE-441 (confused deputy) in a single advisory. The confused-deputy label is the right one — a privileged server carrying out file reads and network uploads on behalf of whoever asked, with no check that the asker was entitled to either. It pairs naturally with this week's LiteLLM MCP auth bypass: gateways and tool servers that accept identity material inside ordinary request headers keep converting header possession into authority. If your MCP infrastructure ingests caller-controlled headers anywhere in its auth path, that path is the next advisory.

Sources: