MCP Server SSRF to Cloud Metadata: The mcp-atlassian Case

What happened with the mcp-atlassian server?

mcp-atlassian is an open source MCP server for Jira and Confluence. According to the CVE record, before version 0.17.0 an unauthenticated attacker who could reach its HTTP endpoint could force the server process to make outbound requests to a URL the attacker controlled. The maintainers' advisory GHSA-7r34-79r5-rcc9 traces it to middleware that took the Jira or Confluence address from request headers and used it without checking private IP ranges, URL schemes or the address in the server's own configuration.

The advisory lists three kinds of impact: probing internal services that outsiders cannot reach, handing the AI agent crafted tool results that carry instructions, and, in its words, that "any network-reachable attacker can potentially steal the server's IAM role credentials via the instance metadata service." The second one matters for AI features: text that comes back from an attacker's address lands in the model's context as if Jira had sent it. The chatbot self-test covers how to limit what that kind of text can trigger.

One detail deserves care. The CVSS vector marks the attack as adjacent-network, while the impact text speaks of anyone who can reach the server over a network. Do not pick the milder reading for your own host. Which one applies depends on who can reach the port, and that is a question you answer by looking at your firewall.

How does an unauthenticated MCP endpoint reach cloud metadata?

Server-side request forgery (SSRF) means a server makes a request on behalf of a stranger, from the server's own position on the network. Cloud hosts keep a metadata service at a link-local address, 169.254.169.254, that answers only the machine it belongs to. Microsoft's documentation says Azure's service can only be accessed from within the VM, and Google's says requests and responses never leave the physical host. A stranger on the internet cannot ask it anything. A server on that machine can, and if the server fetches addresses a stranger supplies, the stranger borrows its position.

The same mechanism shows up in the protocol itself. The MCP security best practices list cloud metadata endpoints among the targets of SSRF and tell implementers to block private, loopback and link-local ranges, including 169.254.0.0/16. They also warn against writing the IP check by hand, because encoding tricks defeat custom parsers. RFC 9728 section 7.7 gives the same advice for clients that fetch metadata from servers they have not met.

Three things must line up for the metadata step to matter: the endpoint answers without a login, the server follows an address it was handed, and the host carries a role with real permissions. Break any one and the damage shrinks. That is why the checks below work on all three, and why a patch for one program does not finish the job.

If you build an app with Newly, the phone app is a React Native and Expo project and does not run an MCP server. The risk sits in whatever you or a helper run on a server around it. You can download your project code or connect your own repository, so search it for MCP server start commands and for the words streamable-http and sse.

Do cloud metadata protections stop this?

They narrow it. Each provider asks for something extra before it answers, and what that extra is differs. Whether it blocks a given SSRF depends on what the vulnerable request is able to send, which you cannot assume from outside.

The AWS post explains why the token flow is stronger than a static header: many SSRF flaws let the attacker set headers, and the two-step session is harder to imitate. Even so, OWASP's SSRF prevention cheat sheet calls IMDSv2 a defense-in-depth mechanism that mitigates some instances of SSRF, and says to migrate to it and disable the old IMDSv1. It also says deny-lists are bypass-prone and allowlists are preferred, and that network segregation is highly recommended to block illegitimate calls at the network level.

What should I check in my own setup?

Five checks, in the order that removes the most risk first. Write down what you find, because the self-test below asks for evidence.

1. Is mcp-atlassian installed, and which version?

Look in every place it could run: a developer laptop, a container image, a CI job, a small server. pip show mcp-atlassian prints the installed version, and a lock file or image tag shows what a build will install. Anything below 0.17.0 is in the affected range. If you never installed it, mark this item confirmed only after you searched the repository and the hosts, not after remembering.

2. Does the endpoint ask for a login?

Any MCP server you start on an HTTP transport deserves the same question, whatever it connects to. The MCP authorization specification makes authorization optional, and a server that returns the 401 response with a WWW-Authenticate header that points to its resource metadata is following it. A server that answers a call with no credentials is not. The authorization checklist walks through what to configure.

3. Who can reach the port?

Read the firewall or security group rule for the MCP port. A rule that allows the whole internet, or a server bound to every network interface, widens who can send the request. Bind to localhost or a private address when only your own tools call it. Our page on exposed MCP servers and the one on exposed self-hosted AI endpoints cover how to test this from outside.

4. Can the server call internal addresses?

The fix in 0.17.0 blocks private IPs, DNS rebinding and redirects to internal targets, per the fix commit. You can add the same limit around any server with an egress rule or an outbound proxy. The MCP best practices name egress proxies as a control, and they say to disable automatic redirects or check each hop.

5. What can the host's role do?

Open the policy attached to the machine that runs the server. List each permission and ask whether the MCP server needs it. A server that reads Jira has no use for permission to read storage buckets or create machines. A smaller role limits what a successful request to the metadata service can return.

Where do you stand?

Mark each item. Everything starts as unknown, which is what an unchecked item is. Move one to confirmed only when you hold the evidence listed under it.

An outside scan reads what answers a public request. The version of an MCP server, the role on its host and its outbound rules usually do not show from outside, so no scan, ours included, moves those items from unknown to confirmed.

What if an old version was reachable?

Upgrading closes the hole going forward. It does not tell you whether anything used it before. Work through these in order:

• Read your cloud provider's audit log for use of the host's role from addresses that are not yours, and for actions the MCP server has no reason to perform.
• If your proxy logs request headers, look for calls that carry a Jira or Confluence address header from callers you do not know.
• Replace every long-lived key or token the host could read, such as Jira tokens, AI provider keys and database passwords. Our rotation guide for app teams and the red.run.cloud guide to rotating secrets after a breach list the order.
• Re-read what your AI agent returned during the window, since the advisory notes that tool results can come from an attacker's server.

None of this proves a compromise happened. It gives you evidence either way, which is the difference between unknown and confirmed. Other 2026 server advisories and their fixed versions are in the MCP server CVE roundup, and the 15-minute app check covers the rest of what sits around your app.

Frequently asked questions

Sources

All sources opened on October 24, 2026.

1. GHSA-7r34-79r5-rcc9: SSRF via unvalidated X-Atlassian URL headers, GitHub Security Advisories, sooperset/mcp-atlassian
2. CVE-2026-27826, NIST National Vulnerability Database
3. CVE-2026-27826 record, CVE Program
4. CVE-2026-27826 (aliases GHSA-7r34-79r5-rcc9, PYSEC-2026-2621), OSV
5. SSRF protection commit for GHSA-7r34-79r5-rcc9, GitHub, sooperset/mcp-atlassian
6. Release v0.17.0, GitHub, sooperset/mcp-atlassian
7. MCP Authorization, specification 2026-07-28, modelcontextprotocol.io
8. Security Best Practices: Server-Side Request Forgery, modelcontextprotocol.io
9. RFC 9728 section 7.7, Server-Side Request Forgery, IETF
10. Server-Side Request Forgery Prevention Cheat Sheet, OWASP Cheat Sheet Series
11. Add defense in depth against open firewalls, reverse proxies, and SSRF vulnerabilities with enhancements to the EC2 Instance Metadata Service, AWS Security Blog
12. About VM metadata, Google Cloud documentation
13. Azure Instance Metadata Service for virtual machines, Microsoft Learn