Two mcp-atlassian advisories landed the same day. Both exposed the same trust boundary.

[msaleme]

On July 10, 2026, two GitHub security advisories were published for mcp-atlassian < 0.22.0. Both were fixed in 0.22.0.

• GHSA-g5r6-gv6m-f5jv (CVSS 7.7, CWE-22): confluence_upload_attachment passed file_path directly to open() without confinement. An authenticated MCP client, or an agent manipulated through prompt injection, could cause the server to read and upload files such as /proc/self/environ or an SSH key to Confluence.

• GHSA-489g-7rxv-6c8q (CVSS 6.5, CWE-918): a DNS-rebinding TOCTOU bypass of the earlier SSRF fix. The guard resolved and checked the hostname once, discarded the approved IP, and then allowed the connection to resolve the hostname again. DNS could therefore return a public IP during validation and 169.254.169.254 during connection.

Neither July 10 advisory currently has its own CVE. The rebinding advisory is documented as an incomplete-fix sibling of CVE-2026-27826.

Immediate action: upgrade mcp-atlassian to 0.22.0 or later.

Why it matters

These are the same failure wearing two hats.

A path and a URL look like data. In a privileged tool, they are capabilities:

• A path selects what the server may read.
• A URL selects where the server may connect.

Schema validation can prove that an argument is a string. It cannot prove that the caller should possess the authority that string invokes.

The SSRF case is the sharper lesson. The server did validate the resolved IP, but it did not bind that decision to the connection. It checked one destination and potentially connected to another.

What our current tests cover

• MCP-015 and MCP-016 send internal and metadata-service destinations to tools exposing url, uri, or endpoint parameters.
• CREW-005 exercises sensitive-file access through path-taking tools.
• MCP-005 covers related resource-path traversal behavior.

Those tests cover the vulnerability classes. They do not yet reproduce both advisories exactly.

What they currently miss

The rebinding vulnerability enters through transport headers and middleware, not an MCP tool argument. MCP-015 also sends literal internal URLs; it does not operate a rebinding DNS server that returns a public IP during validation and a private IP during connection.

A server that blocks literal 169.254.169.254 but re-resolves an unpinned hostname could therefore pass MCP-015 and remain vulnerable.

That gives us two concrete additions:

1. Test security-sensitive transport headers and middleware inputs, not only declared tool arguments.
2. Add a DNS-rebinding case that verifies the destination approved during policy evaluation is the destination used by the connection.

That is a gap we are adding to the suite, not a pass we claim today.

The question for MCP implementers

If your server accepts a URL or path, are you merely validating its syntax, or constraining the authority it grants?

For URLs, are you checking a hostname once, or binding the approved IP to the connection that actually follows?

Those are different guarantees. These two advisories are the distance between them.