GHSA-489g-7rxv-6c8q: MCP Atlassian DNS-rebinding TOCTOU Bypass Of The Vulnerability

MODERATE
CVSS 6.5
CWE-918
Published
Advisory Summary

GHSA-489g-7rxv-6c8q is a MODERATE (CVSS 6.5) dns-rebinding toctou bypass of the vulnerability (CWE-918: Server-Side Request Forgery (SSRF)) affecting MCP Atlassian libraries in the PyPI ecosystem. The issue involves dns-rebinding toctou bypass of the ssrf fix (cve-2026-27826). Remediation is available by upgrading affected packages to version 0.22.0.

GHSA-489g-7rxv-6c8q at a Glance

CVE Identifier N/A
GHSA Identifier GHSA-489g-7rxv-6c8q
Severity MODERATE
CVSS v3.1 Base Score 6.5
CWE Classification CWE-918: Server-Side Request Forgery (SSRF)
Affected Product MCP Atlassian
Package Ecosystem PyPI
Published Date
Last Updated

Security Impact

CVSS: 6.5

The security impact metrics below are parsed directly from the CVSS v3.1 vector string (CVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:U/C:H/I:L/A:N).

Attack Vector Network (AV:N)
Attack Complexity High (AC:H)
Privileges Required None (PR:N)
User Interaction None (UI:N)
Scope Unchanged (S:U)
Confidentiality High (C:H)
Integrity Low (I:L)
Availability None (A:N)

How to Fix GHSA-489g-7rxv-6c8q

To remediate this vulnerability, upgrade all affected MCP Atlassian dependencies to a patched release. Both direct and transitive dependencies should be checked, as frameworks or security libraries may pull in vulnerable versions transitively.

mcp-atlassian fixed: 0.22.0
pip install mcp-atlassian>=0.22.0
Verify Direct and Transitive Dependencies

Run the following command in your project directory to verify that all resolved dependencies use the patched release:

pip show mcp-atlassian

How to Check if You Are Affected

To determine whether your Python environment is affected by GHSA-489g-7rxv-6c8q, inspect your installed packages using pip:

pip show mcp-atlassian

Analyze the terminal output to locate any version of MCP Atlassian in your dependency tree. If any resolved version matches the vulnerable ranges listed in the table below (for example, versions earlier than 0.22.0), your application is affected.

Note: The pip show mcp-atlassian command checks currently installed packages in your active Python environment.

Technical Details

Vulnerability Mechanism & Technical Analysis

This vulnerability is classified under CWE-918: Server-Side Request Forgery (SSRF), where 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. In MCP Atlassian, software state validation or input boundaries are circumvented during processing. Review the official source advisory statement below for specific affected components, classes, and reproduction details.

Source Advisory Statement

### 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`.

GHSA-489g-7rxv-6c8q Affected MCP Atlassian Versions

1 component(s)
Fixed Versions:
0.22.0
Product / Package Ecosystem Affected Versions Fixed Version
mcp-atlassian
PyPI
< 0.22.0
0.22.0

References

Frequently Asked Questions

What is GHSA-489g-7rxv-6c8q?
GHSA-489g-7rxv-6c8q is a security vulnerability in MCP Atlassian involving DNS-rebinding TOCTOU bypass of the SSRF fix (CVE-2026-27826) under CWE-918: Server-Side Request Forgery (SSRF).
Which MCP Atlassian versions are affected?
Affected versions include releases prior to 0.22.0 across affected packages: mcp-atlassian.
What version fixes GHSA-489g-7rxv-6c8q?
Upgrading to 0.22.0 (or the latest patched release for your respective branch) resolves the vulnerability.
Is mcp-atlassian affected?
Yes, mcp-atlassian is affected in releases prior to 0.22.0. Upgrade your dependency to 0.22.0 or later.
What is the CVSS score of GHSA-489g-7rxv-6c8q?
GHSA-489g-7rxv-6c8q has a CVSS v3.1 base score of 6.5 (MODERATE) with vector string CVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:U/C:H/I:L/A:N.
What CWE is associated with GHSA-489g-7rxv-6c8q?
GHSA-489g-7rxv-6c8q is classified under 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.).
How can I check PyPI dependencies for GHSA-489g-7rxv-6c8q?
Run the dependency tree command: 'pip show mcp-atlassian'. This command lists direct and transitive dependencies in your build configuration so you can verify if a vulnerable version is resolved.
Machine-readable OSV JSON OSV v1.5 Schema
Normalized schema output
{
  "schema_version" : "1.4.0",
  "id" : "GHSA-489g-7rxv-6c8q",
  "modified" : "2026-07-10T18:01:22Z",
  "published" : "2026-07-10T18:01:22Z",
  "aliases" : [ ],
  "summary" : "MCP Atlassian: DNS-rebinding TOCTOU bypass of the SSRF fix (CVE-2026-27826)",
  "details" : "### Summary\nGHSA-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.\n\n### Relationship to CVE-2026-27826 / GHSA-7r34-79r5-rcc9 (incomplete fix — please read first)\nThis 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).\n\n### Affected\n`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).\n\n### Vulnerable code\n`utils/urls.py` `validate_url_for_ssrf` (≈184-205) resolves + validates, then returns a **string verdict, not a pinned IP**:\n```python\ndef validate_url_for_ssrf(url: str) -> str | None:   # returns an error string or None — NO IP is pinned\n    ...\n    # resolves the host, checks each resolved IP is global, then DISCARDS the IP\n```\n`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.\n\n### PoC (executed — boundary demonstration)\nThe 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`:\n```\n[CHECK ] validate_url_for_ssrf('http://rebind.attacker.example') -> None        (getaddrinfo#1 = 93.184.216.34 global -> guard PASSED)\n[CONNECT] getaddrinfo call #2 returned 169.254.169.254 -> the socket connects HERE\n[PROOF ] guard validated IP 93.184.216.34 but connection targets 169.254.169.254  => SSRF on the PATCHED build\n[CONTROL] if guard SAW 169.254.169.254 at check time -> blocks it correctly\n[PIN   ] validate_url_for_ssrf returns a verdict (None), NOT an IP; dependencies.py builds url=raw hostname -> NO pin\nALL PoC ASSERTIONS PASSED — DNS-rebind TOCTOU bypass demonstrated.\n```\n**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.\n\n### Impact\nSame 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.\n\n### Severity\n**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.\n\n### Remediation\nPin 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.\n\n### Dedup / freshness (re-verified live 2026-06-27)\nAdvisories `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`.",
  "severity" : [ {
    "type" : "CVSS_V3",
    "score" : "CVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:U/C:H/I:L/A:N"
  } ],
  "affected" : [ {
    "package" : {
      "ecosystem" : "PyPI",
      "name" : "mcp-atlassian"
    },
    "ranges" : [ {
      "type" : "ECOSYSTEM",
      "events" : [ {
        "introduced" : "0"
      }, {
        "fixed" : "0.22.0"
      } ]
    } ]
  } ],
  "references" : [ {
    "type" : "WEB",
    "url" : "https://github.com/sooperset/mcp-atlassian/security/advisories/GHSA-489g-7rxv-6c8q"
  }, {
    "type" : "PACKAGE",
    "url" : "https://github.com/sooperset/mcp-atlassian"
  } ],
  "database_specific" : {
    "cwe_ids" : [ "CWE-918" ],
    "severity" : "MODERATE",
    "github_reviewed" : true,
    "github_reviewed_at" : "2026-07-10T18:01:22Z",
    "nvd_published_at" : null
  }
}