Summary
MCP Atlassian's Confluence attachment upload function can open a caller-selected local file without restricting access to the intended workspace. A permitted Confluence MCP caller may therefore upload readable server-local files as attachments and disclose sensitive data.
Affected context
The issue occurs in MCP Atlassian deployments where the Confluence attachment-upload capability is enabled and the server accepts a caller-controlled file path. Risk exists when the MCP server process can read files outside the intended workspace and the caller is permitted to invoke the upload operation.
Exploit preconditions
- Attack surface: Confluence attachment upload through the MCP server
- Required access: Permission to invoke the relevant Confluence MCP operation
- Trigger point: Processing of the caller-supplied
file_pathduring attachment upload - Why exploitation is possible: The selected path is opened without an effective restriction to an approved workspace or directory
Why this happens
The vulnerability results from trusting a caller-controlled filesystem path when opening an attachment. Without canonicalization, workspace-boundary enforcement, and an allowlisted file policy, path resolution may access files outside the intended directory. This behavior maps to CWE-22: Improper Limitation of a Pathname to a Restricted Directory ('Path Traversal').
Potential impact
- Sensitive server-local files may be disclosed through Confluence attachments
- Credentials, configuration data, or application secrets could be exposed
- Data readable by the MCP server process may be copied outside its intended location
- Exposed information could enable follow-on compromise of connected systems
General mitigation guidance
Mitigation generally focuses on treating file paths as untrusted input and enforcing a narrow file-access boundary.
Common defensive patterns include:
- Resolving candidate paths against a fixed workspace and rejecting paths outside its canonical boundary
- Preferencing opaque file identifiers or controlled upload handles over raw filesystem paths
- Applying an allowlist for permitted directories, file types, and file sizes
- Running the MCP server with a dedicated least-privilege account and minimal filesystem access
- Preventing access to secrets, runtime metadata, and other sensitive directories
- Logging file-selection decisions and attachment-upload activity for review
How teams detect issues like this
Organizations can look for:
- Static-analysis findings involving file-opening APIs that consume request or tool arguments
- Code-review signals such as direct use of caller-provided paths, string-based path concatenation, or missing canonical-boundary checks
- Tests that verify traversal attempts and symbolic-link escapes are rejected
- Runtime logs showing attachment requests targeting unexpected directories or sensitive file types
- Policy enforcement requiring workspace confinement and least-privilege filesystem permissions
Automated security review tools may help identify path-handling flows, but findings should be validated against deployment-specific access controls.
