Skip to content
RESEARCH INDEX BREACHROAD / INTELLIGENCE NOTE

MCP Atlassian CVE-2026-73498: an AI agent can upload a local file to Confluence

Missing file_path validation in confluence_upload_attachment exposes every server-readable file. Prompt injection can activate the vulnerable flow.

PUBLIC RESEARCH
AUTHOR
/ Breachroad CEO · OSCP · PNPT
PUBLISHED
13 August 2026
READING TIME
14 min read
TOPIC
AI Security
MCP Atlassian CVE-2026-73498: an AI agent can upload a local file to Confluence

CVE-2026-73498, published on 13 August 2026, affects the MCP Atlassian server connecting AI agents to Jira and Confluence. Its confluence_upload_attachment tool accepted a file_path, opened that file and uploaded it to Confluence without verifying that the path remained inside an approved directory. An authenticated MCP client could therefore read any file accessible to the server process. When an agent was manipulated by issue or page content, prompt injection could cause the tool call without a deliberate operator decision.

Versions below 0.22.0 are vulnerable, and MCP Atlassian 0.22.0 contains the fix. GHSA-g5r6-gv6m-f5jv scores it 7.7 under CVSS 3.1: network access, low complexity, low privileges, no interaction, changed scope and high confidentiality impact. The source documents a technically confirmed prompt-injection path, but not a mass campaign against every deployment.

The missing boundary

Upload code passed the path directly to open(file_path, "rb"). A download function in the same module already used validate_safe_path, showing that a protection existed but was not applied symmetrically. The fixing commit adds that validation as part of broader server hardening.

This was not limited to classic ../ traversal. The tool accepted arbitrary absolute or relative paths, with the process’s operating-system permissions as the only boundary. In a container that may expose application files, ServiceAccount tokens, mounted secrets, the home directory and /proc/self/environ. A non-isolated host can expose more.

The exfiltration channel is the legitimate business function: the file becomes a Confluence attachment. An egress firewall allowing only Atlassian does not stop it. To the network, this is expected HTTPS to a trusted SaaS. Detection needs the file, tool and destination-page context.

How MCP changes the threat model

In a traditional application, a user with API access would deliberately submit a path. In an agent system, the model can generate the argument after reading untrusted content. A Jira issue, comment, bug description or Confluence page becomes data influencing a tool-use decision. The model is not an independent authorization control.

Prompt injection and path validation play different roles. The injection steers the agent and provides an intention to call the tool. The CVE lets the tool accept a resource outside its intended workspace. Remove either part and the chain may fail: a tightly constrained tool cannot read an arbitrary path, while a vulnerable API unavailable to untrusted actors has less reachability.

The fix cannot be “a stronger system prompt” alone. Model instructions may reduce unsafe actions but are not a security boundary. The tool server must independently validate path, identity, policy and destination even for an approved agent.

Which data could be read

Scope depends on deployment. In Docker, inspect mounts, environment and process UID. Kubernetes adds Secrets, ConfigMaps, projected ServiceAccount tokens and shared volumes. A local installation may expose SSH keys, user configuration, tool caches and repositories. The CVE does not prove each resource existed.

Likely secrets include CONFLUENCE_API_TOKEN, Jira credentials, application environment, cloud keys and database credentials. If a Confluence token is uploaded back to Confluence, the attacker still needs read access to the page or attachment. A manipulated agent can, however, select a page accessible to the person controlling the content.

Establish whether the integration account could create attachments in public spaces, cross-tenant spaces or pages visible to external guests. Atlassian permissions define the receiving channel, while filesystem rights define the source set.

What to do now

  1. Find every mcp-atlassian instance, including local processes, images, desktop integrations, team servers and experiments.
  2. Upgrade to 0.22.0 or later, replace pods and processes, and prove the runtime version.
  3. Disable the upload tool until updating when immediate replacement is impossible. A prompt forbidding paths is not a technical mitigation.
  4. Limit the process to one filesystem workspace using a read-only root, dedicated UID, minimum mounts and no automatic ServiceAccount token.
  5. Review attachments created by the integration identity: names, sizes, pages, caller and timing relative to content the agent read.
  6. Correlate MCP logs with Confluence audit, Jira history, EDR and file-access telemetry, looking for paths outside the approved workspace.
  7. Rotate plausibly readable secrets after fixing the vulnerability and removing access to malicious attachments.

Updates must include clients or agent configuration pinning an old image or Python package. A central server may be current while a desktop-launched local process remains vulnerable. An MCP inventory should record both the server and the tools exposed to each agent.

Investigating without spreading secrets

Do not open suspect attachments on a normal workstation or paste their contents into a ticket. Preserve metadata, permissions and a digest, then inspect them in isolation. If a file contains environment variables or a private key, every extra copy increases incident scope.

Build a timeline: content the agent read, model decision, tool call, path, attachment and later reads. Not every system-file attachment proves malicious prompting—an operator may have uploaded diagnostics legitimately. Strong evidence combines an out-of-workspace path, an unauthorized destination and earlier content directing the agent.

If MCP logs redact the argument, use filesystem telemetry and Atlassian audit. Future logging should retain a normalized resource identifier or relative path, never file contents. Alerts can identify absolute paths, .., /proc, home directories or key-like extensions, but a root allowlist remains the primary control.

Designing a safer agent file tool

The strongest API is not upload(file_path: string). Accept an opaque identifier for a file previously created inside a controlled workspace. Trusted server code maps the identifier to a path. After canonicalisation, the target must remain under one root, not resolve through an escaping symlink, and satisfy size and type policy.

A separate authorization decision should validate the Confluence page and caller. An agent reading an issue must not silently expand its authority into uploading a local secret. A high-risk operation can require human approval showing file name, source and destination. Approval must bind to exact arguments so the model cannot change them afterward.

Security tests should instrument file reads. Absolute paths, traversal, encoded separators, symbolic links and time-of-check/time-of-use races need rejection. Opening relative to a trusted directory handle with operating-system containment is stronger than string comparison alone.

Facts and conclusions

The missing validate_safe_path, server-side file read, Confluence upload, <0.22.0 range and confirmed prompt-injection variant are facts from the advisory. They do not establish exploitation of every installation. Data scope, rotation priority and safer API design are Breachroad analysis based on each worker’s effective rights.

CVE-2026-73498 shows that agent security extends beyond the model. Prompt, tool schema, server validation, sandbox, Atlassian permissions and logs form one path. We examine cases like this in our cybersecurity and AI security training. MCP architecture, permissions and data boundaries can be reviewed further through a secure AI implementation assessment.

SHARE / COPY