MCPwnfluence: What Two MCP Server Vulnerabilities Tell Us About the Next Attack Surface

We've all gotten the memo by now. AI agents have moved well past chat assistants. They're being assigned Jira issues, executing tasks inside workflows, and interacting directly with internal tools and APIs. But while most of the conversation has been about what agents can do, less attention has been paid to what they can be exploited through.

Recent research from Pluto Security is a good example of what that looks like in practice. They discovered two vulnerabilities in the widely used mcp-atlassian MCP server (over 4,400 GitHub stars, more than 4 million downloads) that could allow attackers to achieve remote code execution and internal network access from machines running the server.

The vulnerabilities, collectively dubbed "MCPwnfluence", caught our attention. Not because they necessarily represent an immediate widespread threat, but because of what they signal about where this is all heading.

AI agents in Jira: what's changed

Atlassian recently introduced agents in Jira. These aren't standalone AI tools. They're participants in enterprise processes. Agents can be assigned issues, invoked through @mentions in comments, and execute tasks inside workflow states.

To interact with external tools and data sources, these agents use the Model Context Protocol (MCP). An MCP server sits between the AI model and your enterprise APIs, giving agents structured access to things like Jira issues, Confluence content, attachments, search, and project data.

Because MCP servers often run locally on developer machines or inside internal environments, they frequently have broad access to enterprise APIs and internal networks. That makes them powerful integration components, but also high-value targets.

The vulnerabilities: CVE-2026-27825 and CVE-2026-27826

Pluto Security identified two vulnerabilities affecting mcp-atlassian versions prior to 0.17.0 when using HTTP transport.

A key configuration detail is worth noting here. When running with HTTP transport, the MCP server binds to 0.0.0.0 and exposes its tool endpoints without authentication. Any device on the same network can invoke MCP tools directly.

That means potential attacker footholds include compromised workstations, shared office networks, coworking spaces, compromised containers in the same VPC, and lateral movement inside corporate networks.

CVE-2026-27825: Arbitrary file write leading to RCE

The first vulnerability exists in the attachment download functionality for Confluence. The download_attachment() method accepts a user-supplied file path and writes the downloaded attachment directly to disk without validating the path.

os.makedirs(os.path.dirname(target_path), exist_ok=True)
with open(target_path, "wb") as f:
    for chunk in response.iter_content(chunk_size=8192):
        f.write(chunk)

Because the path is not sanitised, attackers can perform path traversal attacks. This allows files to be written anywhere on the host filesystem, including malicious entries to ~/.bashrc, SSH keys in ~/.ssh/authorized_keys, or cron jobs for persistence. These techniques can lead to full remote code execution on the MCP server host.

CVE-2026-27826: SSRF via header injection

The second vulnerability allows attackers to redirect outbound requests from the MCP server. The server trusted X-Atlassian-Jira-Url and X-Atlassian-Confluence-Url headers without validation, meaning an attacker could inject arbitrary URLs and force the MCP server to make requests to attacker-controlled destinations.

This enables server-side request forgery, with common attack paths including accessing cloud metadata services (169.254.169.254), scanning internal services, interacting with private APIs, and mapping internal network infrastructure. In effect, the MCP server becomes a proxy into the victim's internal environment.

A realistic attack chain

These vulnerabilities can be chained together:

1. Attacker gains access to the same network as a developer workstation running MCP
2. The MCP server is exposed on 0.0.0.0 without authentication
3. The attacker invokes MCP tools directly over HTTP
4. Using CVE-2026-27825, they write malicious files to the host
5. The payload executes via shell initialisation or scheduled tasks
6. Using CVE-2026-27826, they pivot further into the internal network through SSRF

From there, attackers could target cloud credentials, internal APIs, CI/CD systems, source code repositories, and enterprise SaaS integrations.

Fixes and mitigation

Both vulnerabilities were patched in mcp-atlassian version 0.17.0.

Security improvements include path normalisation, symlink resolution, base-directory enforcement, URL validation, scheme allow-listing, blocking of private IP ranges, DNS validation, and redirect validation.

If you're running an affected version, upgrading is straightforward:

pip install --upgrade "mcp-atlassian>=0.17.0"

or:

uv tool upgrade mcp-atlassian

A detection script is also available from the researchers to scan environments for vulnerable installations across pip installations, uv tool environments, virtualenvs, Docker images, and MCP client configurations.

The bigger picture

These specific vulnerabilities have been patched, and exploitation requires a fairly specific set of conditions (network adjacency, HTTP transport, no auth). This isn't a "drop everything" situation for every business.

But zoom out a bit and the pattern is worth watching. Enterprise platforms like Jira are increasingly becoming orchestration layers for human-AI collaboration. MCP servers are the connective tissue between AI models and your internal systems. As adoption grows, so does the attack surface.

How many security teams are actively thinking about MCP servers as part of their threat landscape yet? Based on what we're seeing, that's probably going to increase, and increase quickly.

If your organisation is experimenting with AI agents in enterprise workflows, these CVEs are worth a look. Not o for the specific patch, but for what they tell us about where the next wave of vulnerabilities is likely to come from.

Written by Jonathan, Head of Cyber Defence at Cytidel.