GHSA-489g-7rxv-6c8q: MCP Atlassian DNS-rebind

Q: Is GHSA-489g-7rxv-6c8q actively exploited?

No confirmed active exploitation of GHSA-489g-7rxv-6c8q has been reported, but organizations should still patch proactively.

Q: How to fix GHSA-489g-7rxv-6c8q?

1) Upgrade mcp-atlassian to 0.22.0+ and confirm the release notes/diff actually implement IP pinning (custom resolver or cached-getaddrinfo requests adapter) rather than repeating the discard-the-IP pattern in validate_url_for_ssrf — this specific bypass was still open as of HEAD ba72540 per the advisory. 2) Defense-in-depth regardless of patch status: block outbound requests from the mcp-atlassian host to 169.254.169.254 and RFC1918/loopback ranges at the network/firewall layer, and disable IMDSv1 / require IMDSv2 with hop-limit 1 on any cloud instance running this server. 3) Do not trust or forward the X-Atlassian-Jira-Url / X-Atlassian-Confluence-Url headers from untrusted callers if the deployment can avoid it — restrict which upstream clients may set these headers. 4) Detection: monitor for anomalous DNS answer changes (same qname, differing A records within seconds) and for outbound connections from the MCP host to link-local/metadata or RFC1918 addresses; alert on any 169.254.169.254 access from application service accounts.

Q: What systems are affected by GHSA-489g-7rxv-6c8q?

This vulnerability affects the following AI/ML architecture patterns: agent frameworks, MCP servers, tool integrations.

Q: What is the CVSS score for GHSA-489g-7rxv-6c8q?

GHSA-489g-7rxv-6c8q has a CVSS v3.1 base score of 6.5 (MEDIUM).

CISO Take

This is an incomplete-fix SSRF: mcp-atlassian's earlier patch for the attacker-controlled X-Atlassian-Url header validated the hostname once at middleware time but never pinned that validated IP to the actual outbound connection, so a DNS-rebinding attacker can pass the guard with a public IP and then have the real request land on 169.254.169.254 or an internal address — even on a build that already shipped the prior fix. There's no CISA KEV listing, no EPSS score, and no public exploit or Nuclei template, and the CVSS AC:H reflects that a live attack additionally needs an attacker-controlled fast-rebinding DNS responder to win the resolve-then-connect race, a step the researcher's own PoC explicitly stops short of demonstrating end-to-end. Still, mcp-atlassian is an MCP tool reachable by unauthenticated or low-privileged callers that talks to Atlassian on the organization's behalf, so a successful bypass means silent theft of cloud IAM credentials from the instance metadata service or a pivot into internal services — the blast radius that matters for SSRF regardless of the 0 tracked downstream dependents (package risk score 45/100). Upgrade to mcp-atlassian 0.22.0+, verify it actually pins the resolved IP rather than re-implementing the same discard-the-IP pattern, and in the meantime block outbound access to 169.254.169.254 and RFC1918 ranges at the network layer for any host running this server.

Sources: GitHub Advisory ATLAS CISA KEV

What is the risk?

Medium severity (CVSS 3.1 6.5, AV:N/AC:H/PR:N/UI:N/S:U/C:H/I:L/A:N) rather than critical: impact is high (confidentiality) but exploitability is gated by AC:H — the attacker needs a DNS name they control that can flip between a public IP and an internal/metadata IP inside the resolve-to-connect window (classic TOCTOU/rebinding race). No KEV listing, no EPSS score, no known public exploit or scanner template exist yet, and the submitted PoC is a structural boundary test, not a live end-to-end exploit against a running server. That said, it is a first-party code flaw (not a transitive dependency issue) in an unauthenticated-reachable code path, and it defeats a security control that was specifically shipped to close this exact class of bug — which raises confidence that a working exploit is feasible for a moderately resourced attacker running rebinding DNS infrastructure.

How does the attack unfold?

Initial access

Attacker sends a request to the mcp-atlassian MCP server with X-Atlassian-Jira-Url/X-Atlassian-Confluence-Url pointing to a DNS-rebinding domain they control.

AML.T0049

Validation bypass

The middleware-time SSRF guard resolves the hostname once, sees a public IP, and passes validation without pinning that IP to the connection.

Rebind and connect

The outbound fetcher re-resolves the raw hostname at connect time; the attacker's DNS now answers with 169.254.169.254 or an internal IP, and the socket connects there.

Impact

The unauthenticated SSRF reaches cloud metadata or internal services, enabling theft of IAM credentials or further internal reconnaissance.

AML.T0098

Initial access

Attacker sends a request to the mcp-atlassian MCP server with X-Atlassian-Jira-Url/X-Atlassian-Confluence-Url pointing to a DNS-rebinding domain they control.

AML.T0049

Validation bypass

The middleware-time SSRF guard resolves the hostname once, sees a public IP, and passes validation without pinning that IP to the connection.

Rebind and connect

The outbound fetcher re-resolves the raw hostname at connect time; the attacker's DNS now answers with 169.254.169.254 or an internal IP, and the socket connects there.

Impact

The unauthenticated SSRF reaches cloud metadata or internal services, enabling theft of IAM credentials or further internal reconnaissance.

AML.T0098

What systems are affected?

Package	Ecosystem	Vulnerable Range	Patched
MCP Atlassian	pip	< 0.22.0	`0.22.0`

Do you use MCP Atlassian? You're affected.

How severe is it?

CVSS 3.1

6.5 / 10

EPSS

N/A

Exploitation Status

No known exploitation

Sophistication

Advanced

What is the attack surface?

AV Network

AC High

PR None

UI None

S Unchanged

C High

I Low

A None

What should I do?

1 step

1) Upgrade mcp-atlassian to 0.22.0+ and confirm the release notes/diff actually implement IP pinning (custom resolver or cached-getaddrinfo requests adapter) rather than repeating the discard-the-IP pattern in validate_url_for_ssrf — this specific bypass was still open as of HEAD ba72540 per the advisory. 2) Defense-in-depth regardless of patch status: block outbound requests from the mcp-atlassian host to 169.254.169.254 and RFC1918/loopback ranges at the network/firewall layer, and disable IMDSv1 / require IMDSv2 with hop-limit 1 on any cloud instance running this server. 3) Do not trust or forward the X-Atlassian-Jira-Url / X-Atlassian-Confluence-Url headers from untrusted callers if the deployment can avoid it — restrict which upstream clients may set these headers. 4) Detection: monitor for anomalous DNS answer changes (same qname, differing A records within seconds) and for outbound connections from the MCP host to link-local/metadata or RFC1918 addresses; alert on any 169.254.169.254 access from application service accounts.

How is it classified?

Auth Bypass Data Extraction Agent Plugin AML.T0049 - Exploit Public-Facing Application AML.T0098 - AI Agent Tool Credential Harvesting AML.T0106 - Exploitation for Credential Access

Which compliance frameworks are affected?

This CVE is relevant to:

EU AI Act

Article 15 - Accuracy, robustness and cybersecurity

ISO 42001

A.6.2.3 - AI system security controls

NIST AI RMF

MEASURE 2.7 - AI system security and resilience is evaluated

OWASP LLM Top 10

LLM07 - Insecure Plugin Design

Frequently Asked Questions

What is GHSA-489g-7rxv-6c8q?

This is an incomplete-fix SSRF: mcp-atlassian's earlier patch for the attacker-controlled X-Atlassian-Url header validated the hostname once at middleware time but never pinned that validated IP to the actual outbound connection, so a DNS-rebinding attacker can pass the guard with a public IP and then have the real request land on 169.254.169.254 or an internal address — even on a build that already shipped the prior fix. There's no CISA KEV listing, no EPSS score, and no public exploit or Nuclei template, and the CVSS AC:H reflects that a live attack additionally needs an attacker-controlled fast-rebinding DNS responder to win the resolve-then-connect race, a step the researcher's own PoC explicitly stops short of demonstrating end-to-end. Still, mcp-atlassian is an MCP tool reachable by unauthenticated or low-privileged callers that talks to Atlassian on the organization's behalf, so a successful bypass means silent theft of cloud IAM credentials from the instance metadata service or a pivot into internal services — the blast radius that matters for SSRF regardless of the 0 tracked downstream dependents (package risk score 45/100). Upgrade to mcp-atlassian 0.22.0+, verify it actually pins the resolved IP rather than re-implementing the same discard-the-IP pattern, and in the meantime block outbound access to 169.254.169.254 and RFC1918 ranges at the network layer for any host running this server.

Is GHSA-489g-7rxv-6c8q actively exploited?

No confirmed active exploitation of GHSA-489g-7rxv-6c8q has been reported, but organizations should still patch proactively.

How to fix GHSA-489g-7rxv-6c8q?

1) Upgrade mcp-atlassian to 0.22.0+ and confirm the release notes/diff actually implement IP pinning (custom resolver or cached-getaddrinfo requests adapter) rather than repeating the discard-the-IP pattern in validate_url_for_ssrf — this specific bypass was still open as of HEAD ba72540 per the advisory. 2) Defense-in-depth regardless of patch status: block outbound requests from the mcp-atlassian host to 169.254.169.254 and RFC1918/loopback ranges at the network/firewall layer, and disable IMDSv1 / require IMDSv2 with hop-limit 1 on any cloud instance running this server. 3) Do not trust or forward the X-Atlassian-Jira-Url / X-Atlassian-Confluence-Url headers from untrusted callers if the deployment can avoid it — restrict which upstream clients may set these headers. 4) Detection: monitor for anomalous DNS answer changes (same qname, differing A records within seconds) and for outbound connections from the MCP host to link-local/metadata or RFC1918 addresses; alert on any 169.254.169.254 access from application service accounts.

What systems are affected by GHSA-489g-7rxv-6c8q?

This vulnerability affects the following AI/ML architecture patterns: agent frameworks, MCP servers, tool integrations.

What is the CVSS score for GHSA-489g-7rxv-6c8q?

GHSA-489g-7rxv-6c8q has a CVSS v3.1 base score of 6.5 (MEDIUM).

What is the AI security impact?

Affected AI Architectures

agent frameworksMCP serverstool integrations

MITRE ATLAS Techniques

AML.T0049 Exploit Public-Facing Application

AML.T0098 AI Agent Tool Credential Harvesting

AML.T0106 Exploitation for Credential Access

Compliance Controls Affected

EU AI Act: Article 15

ISO 42001: A.6.2.3

NIST AI RMF: MEASURE 2.7

OWASP LLM Top 10: LLM07

What are the technical details?

Original Advisory

### Summary GHSA-7r34-79r5-rcc9's fix added `validate_url_for_ssrf`, which resolves the attacker-controlled `X-Atlassian-{Jira,Confluence}-Url` header host **once at middleware time** and trusts the result. But the outbound request is later built with the **raw hostname** and **re-resolves at connect time with no IP pinning**. An attacker-controlled rebinding DNS name returns a public IP on the guard's lookup (validation passes) and `169.254.169.254` / an internal IP on the request's lookup (the socket connects there) → unauthenticated SSRF to cloud metadata / internal services on the **patched** build. ### Relationship to CVE-2026-27826 / GHSA-7r34-79r5-rcc9 (incomplete fix — please read first) This is an **incomplete-fix sibling** of the published `GHSA-7r34-79r5-rcc9` (the `X-Atlassian-*-Url` header SSRF). That fix (PR #986/#1005) added a single middleware-time resolve + allowlist DNS-skip, but **does not pin the validated IP to the connection** — the fetcher re-resolves the raw hostname at connect time, so the documented SSRF mitigation is incomplete against DNS-rebinding. The other advisory `GHSA-xjgw-4wvw-rgm4` (file-write) is unrelated. Verified live (2026-06-27): neither advisory, nor any open PR/issue (`rebind`/`TOCTOU`/`getaddrinfo`/`pin` → 0), covers connect-time re-resolution. Filing as an incomplete-fix of GHSA-7r34 (not a standalone fresh SSRF). ### Affected `src/mcp_atlassian/utils/urls.py` + `servers/main.py` + `servers/dependencies.py`, HEAD `ba72540` (PyPI `mcp-atlassian`, patched ≥0.17.0). **CWE-918** (SSRF) via **CWE-367** (TOCTOU). ### Vulnerable code `utils/urls.py` `validate_url_for_ssrf` (≈184-205) resolves + validates, then returns a **string verdict, not a pinned IP**: ```python def validate_url_for_ssrf(url: str) -> str | None: # returns an error string or None — NO IP is pinned ... # resolves the host, checks each resolved IP is global, then DISCARDS the IP ``` `servers/main.py:526,534` calls it once in middleware. `servers/dependencies.py:544-561` then builds the fetcher with `url = <raw header hostname>` (no pinned IP, no custom resolver / cached-getaddrinfo adapter), so the actual request re-resolves the name. ### PoC (executed — boundary demonstration) The PoC loads the **real** `urls.py` by path (`importlib`, `sha256` printed) and drives the genuine `validate_url_for_ssrf`, simulating the two resolutions via `getaddrinfo`: ``` [CHECK ] validate_url_for_ssrf('http://rebind.attacker.example') -> None (getaddrinfo#1 = 93.184.216.34 global -> guard PASSED) [CONNECT] getaddrinfo call #2 returned 169.254.169.254 -> the socket connects HERE [PROOF ] guard validated IP 93.184.216.34 but connection targets 169.254.169.254 => SSRF on the PATCHED build [CONTROL] if guard SAW 169.254.169.254 at check time -> blocks it correctly [PIN ] validate_url_for_ssrf returns a verdict (None), NOT an IP; dependencies.py builds url=raw hostname -> NO pin ALL PoC ASSERTIONS PASSED — DNS-rebind TOCTOU bypass demonstrated. ``` **Honest scope of the PoC:** this is a **boundary** demonstration — it proves the structural TOCTOU (the guard validates an IP it then discards; the connection re-resolves an unpinned hostname). It does **not** demonstrate a live end-to-end SSRF on a running server; that additionally requires an attacker-controlled fast-rebinding authoritative DNS responder winning the resolve→connect window. Flagging this explicitly rather than overclaiming. ### Impact Same as parent GHSA-7r34 (unauth read of cloud-metadata IAM creds / internal-service reach), reachable again on the patched version. The `X-Atlassian-*-Url` headers are processed in `UserTokenMiddleware` before fetcher creation, so an unauthenticated/low-priv caller controls the host. ### Severity **High — CVSS v3.1 `AV:N/AC:H/PR:N/UI:N/S:U/C:H/I:L/A:N` ≈ 7.x**, aligned to the parent (8.2) with `AC:H` for the rebinding-race precondition. Honest caveat (above): the executed PoC proves the missing IP-pin structurally; a live exploit additionally needs an attacker rebinding-DNS. Not Critical. ### Remediation Pin the connection to the IP that `validate_url_for_ssrf` validated: use a custom resolver / cached-`getaddrinfo` `requests`-adapter (or pass the validated IP with a `Host` header), so the connect cannot re-resolve to a different address. ### Dedup / freshness (re-verified live 2026-06-27) Advisories `GHSA-7r34-79r5-rcc9` (original header SSRF this bypasses) + `GHSA-xjgw-4wvw-rgm4` (file-write, unrelated). Neither covers connect-time re-resolution / rebinding. PR [#986](https://github.com/sooperset/mcp-atlassian/pull/986)/[#1005](https://github.com/sooperset/mcp-atlassian/pull/1005) (the fix) add a single middleware-time resolve + allowlist DNS-skip, no pinning. `gh search prs/issues` for rebind/TOCTOU/getaddrinfo/pin → 0. First-party code. **Fresh** at HEAD `ba72540`.

Exploitation Scenario

An attacker who can reach the mcp-atlassian MCP server endpoint (directly, or indirectly via an agent/tool chain that lets them influence the Jira/Confluence URL header) registers a domain on an authoritative DNS server they control configured for fast TTL flipping. They send a request with X-Atlassian-Jira-Url set to that domain. The SSRF guard in UserTokenMiddleware resolves the name once, gets back a public IP, and passes validation — but discards the IP instead of pinning it. Milliseconds later the actual HTTP fetcher builds its request from the raw hostname and triggers a second DNS resolution; the attacker's DNS server now answers with 169.254.169.254. The fetcher's socket connects to the cloud metadata service, and the response (which may include IAM role credentials) flows back through the MCP server into whatever the attacker can observe (agent output, error messages, or a follow-up exfil step), or the same technique is repointed at an internal-only service the attacker wants to reach.

Weaknesses (CWE)

CWE-918 Server-Side Request Forgery (SSRF) Primary

CWE-918 — Server-Side Request Forgery (SSRF): The web server receives a URL or similar request from an upstream component and retrieves the contents of this URL, but it does not sufficiently ensure that the request is being sent to the expected destination.

Source: MITRE CWE corpus.