Vulnerability-Lookup

BREW-MCP-ATLASSIAN-CVE-2… (CVE-2026-77249)

Vulnerability from osv_homebrew – Published: 2026-10-05 19:49 – Updated: 2026-10-05 19:49 – Source website

Summary

MCP Atlassian: Incomplete fix for CVE-2026-27826: redirect-based SSRF via unhooked requests session in Jira user-permission lookup

Details

MCP Atlassian is a Model Context Protocol (MCP) server for Atlassian products (Confluence and Jira). Prior to 0.22.0, JiraUserMixin._lookup_user_by_permissions uses the module-level requests.get function instead of the fetcher's protected session. A caller-controlled public Jira URL can redirect that unhooked request to an internal address, bypassing the redirect checks added for CVE-2026-27826. The advisory traces the vulnerable input and processing flow through JiraUserMixin._lookup_user_by_permissions, requests.get, self.jira._session.get, and _make_ssrf_safe_hook, which identify the affected entry points, controls, and code paths. This issue is fixed in version 0.22.0.

Severity

5.3 (Medium)


                    
                      CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:L/I:N/A:N

References

URL

Type

	https://github.com/sooperset/mcp-atlassian/releas…	WEB
	https://github.com/CVEProject/cvelistV5/tree/main…	ADVISORY
	https://github.com/sooperset/mcp-atlassian/securi…	ADVISORY
	https://nvd.nist.gov/vuln/detail/CVE-2026-77249	ADVISORY
	https://github.com/sooperset/mcp-atlassian/commit…	FIX
	https://github.com/sooperset/mcp-atlassian/pull/1448	FIX

JSON

To clipboard

{
  "affected": [
    {
      "ecosystem_specific": {
        "fix": "bump",
        "range_state": "fixed",
        "upstream_fixed_in": "0.22.0"
      },
      "package": {
        "ecosystem": "Homebrew",
        "name": "mcp-atlassian",
        "purl": "pkg:brew/mcp-atlassian"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0.11.9"
            },
            {
              "fixed": "0.22.0"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "database_specific": {
    "confidence": "high",
    "source": "matched",
    "strategy": "git",
    "upstream_evidence": [
      {
        "ecosystem": "GIT",
        "key": "https://github.com/sooperset/mcp-atlassian",
        "name": "https://github.com/sooperset/mcp-atlassian",
        "strategy": "git",
        "subject_version": "0.23.1"
      },
      {
        "ecosystem": "PyPI",
        "key": "pkg:pypi/mcp-atlassian@0.23.1",
        "name": "mcp-atlassian",
        "strategy": "registry",
        "subject_version": "0.23.1"
      }
    ]
  },
  "details": "MCP Atlassian is a Model Context Protocol (MCP) server for Atlassian products (Confluence and Jira). Prior to 0.22.0, JiraUserMixin._lookup_user_by_permissions uses the module-level requests.get function instead of the fetcher\u0027s protected session. A caller-controlled public Jira URL can redirect that unhooked request to an internal address, bypassing the redirect checks added for CVE-2026-27826. The advisory traces the vulnerable input and processing flow through JiraUserMixin._lookup_user_by_permissions, requests.get, self.jira._session.get, and _make_ssrf_safe_hook, which identify the affected entry points, controls, and code paths. This issue is fixed in version 0.22.0.",
  "id": "BREW-mcp-atlassian-CVE-2026-77249",
  "modified": "2026-10-05T19:49:39Z",
  "published": "2026-10-05T19:49:39Z",
  "references": [
    {
      "type": "WEB",
      "url": "https://github.com/sooperset/mcp-atlassian/releases/tag/v0.22.0"
    },
    {
      "type": "ADVISORY",
      "url": "https://github.com/CVEProject/cvelistV5/tree/main/cves/2026/77xxx/CVE-2026-77249.json"
    },
    {
      "type": "ADVISORY",
      "url": "https://github.com/sooperset/mcp-atlassian/security/advisories/GHSA-v9m3-wfh8-5646"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-77249"
    },
    {
      "type": "FIX",
      "url": "https://github.com/sooperset/mcp-atlassian/commit/b041733473f95119dd539542a43c280737a8e460"
    },
    {
      "type": "FIX",
      "url": "https://github.com/sooperset/mcp-atlassian/pull/1448"
    }
  ],
  "schema_version": "1.7.3",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:L/I:N/A:N",
      "type": "CVSS_V3"
    }
  ],
  "summary": "MCP Atlassian: Incomplete fix for CVE-2026-27826: redirect-based SSRF via unhooked requests session in Jira user-permission lookup",
  "upstream": [
    "CVE-2026-77249",
    "GHSA-v9m3-wfh8-5646",
    "PYSEC-2026-4100"
  ]
}

CVE-2026-77249 (GCVE-0-2026-77249)

Vulnerability from cvelistv5 – Published: 2026-09-22 18:47 – Updated: 2026-09-22 19:36

Title

MCP Atlassian: Incomplete fix for CVE-2026-27826: redirect-based SSRF via unhooked requests session in Jira user-permission lookup

Summary

Severity

5.3 (Medium)


                        
                          CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:L/I:N/A:N

SSVC

Exploitation: none Automatable: yes Technical Impact: partial

CISA Coordinator · CISA-ADP (v2.0.3)

Decision recorded 2026-09-22 19:35 UTC

CWE

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

Assigner

GitHub_M mitre root Scorecard

References

4 references

URL	Tags
https://github.com/sooperset/mcp-atlassian/securi…	x_refsource_CONFIRM
https://github.com/sooperset/mcp-atlassian/pull/1448	x_refsource_MISC
https://github.com/sooperset/mcp-atlassian/commit…	x_refsource_MISC
https://github.com/sooperset/mcp-atlassian/releas…	x_refsource_MISC

Impacted products

1 product

Vendor	Product	Version
sooperset	mcp-atlassian	Affected: < 0.22.0

Show details on NVD website

JSON

To clipboard

{
  "containers": {
    "adp": [
      {
        "metrics": [
          {
            "other": {
              "content": {
                "id": "CVE-2026-77249",
                "options": [
                  {
                    "Exploitation": "none"
                  },
                  {
                    "Automatable": "yes"
                  },
                  {
                    "Technical Impact": "partial"
                  }
                ],
                "role": "CISA Coordinator",
                "timestamp": "2026-09-22T19:35:45.757999Z",
                "version": "2.0.3"
              },
              "type": "ssvc"
            }
          }
        ],
        "providerMetadata": {
          "dateUpdated": "2026-09-22T19:36:45.769Z",
          "orgId": "134c704f-9b21-4f2e-91b3-4a467353bcc0",
          "shortName": "CISA-ADP"
        },
        "title": "CISA ADP Vulnrichment"
      }
    ],
    "cna": {
      "affected": [
        {
          "product": "mcp-atlassian",
          "vendor": "sooperset",
          "versions": [
            {
              "status": "affected",
              "version": "\u003c 0.22.0"
            }
          ]
        }
      ],
      "descriptions": [
        {
          "lang": "en",
          "value": "MCP Atlassian is a Model Context Protocol (MCP) server for Atlassian products (Confluence and Jira). Prior to 0.22.0, JiraUserMixin._lookup_user_by_permissions uses the module-level requests.get function instead of the fetcher\u0027s protected session. A caller-controlled public Jira URL can redirect that unhooked request to an internal address, bypassing the redirect checks added for CVE-2026-27826. The advisory traces the vulnerable input and processing flow through JiraUserMixin._lookup_user_by_permissions, requests.get, self.jira._session.get, and _make_ssrf_safe_hook, which identify the affected entry points, controls, and code paths. This issue is fixed in version 0.22.0."
        }
      ],
      "metrics": [
        {
          "cvssV3_1": {
            "attackComplexity": "LOW",
            "attackVector": "NETWORK",
            "availabilityImpact": "NONE",
            "baseScore": 5.3,
            "baseSeverity": "MEDIUM",
            "confidentialityImpact": "LOW",
            "integrityImpact": "NONE",
            "privilegesRequired": "NONE",
            "scope": "UNCHANGED",
            "userInteraction": "NONE",
            "vectorString": "CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:L/I:N/A:N",
            "version": "3.1"
          }
        }
      ],
      "problemTypes": [
        {
          "descriptions": [
            {
              "cweId": "CWE-918",
              "description": "CWE-918: Server-Side Request Forgery (SSRF)",
              "lang": "en",
              "type": "CWE"
            }
          ]
        }
      ],
      "providerMetadata": {
        "dateUpdated": "2026-09-22T18:47:01.592Z",
        "orgId": "a0819718-46f1-4df5-94e2-005712e83aaa",
        "shortName": "GitHub_M"
      },
      "references": [
        {
          "name": "https://github.com/sooperset/mcp-atlassian/security/advisories/GHSA-v9m3-wfh8-5646",
          "tags": [
            "x_refsource_CONFIRM"
          ],
          "url": "https://github.com/sooperset/mcp-atlassian/security/advisories/GHSA-v9m3-wfh8-5646"
        },
        {
          "name": "https://github.com/sooperset/mcp-atlassian/pull/1448",
          "tags": [
            "x_refsource_MISC"
          ],
          "url": "https://github.com/sooperset/mcp-atlassian/pull/1448"
        },
        {
          "name": "https://github.com/sooperset/mcp-atlassian/commit/b041733473f95119dd539542a43c280737a8e460",
          "tags": [
            "x_refsource_MISC"
          ],
          "url": "https://github.com/sooperset/mcp-atlassian/commit/b041733473f95119dd539542a43c280737a8e460"
        },
        {
          "name": "https://github.com/sooperset/mcp-atlassian/releases/tag/v0.22.0",
          "tags": [
            "x_refsource_MISC"
          ],
          "url": "https://github.com/sooperset/mcp-atlassian/releases/tag/v0.22.0"
        }
      ],
      "source": {
        "advisory": "GHSA-v9m3-wfh8-5646",
        "discovery": "UNKNOWN"
      },
      "title": "MCP Atlassian: Incomplete fix for CVE-2026-27826: redirect-based SSRF via unhooked requests session in Jira user-permission lookup"
    }
  },
  "cveMetadata": {
    "assignerOrgId": "a0819718-46f1-4df5-94e2-005712e83aaa",
    "assignerShortName": "GitHub_M",
    "cveId": "CVE-2026-77249",
    "datePublished": "2026-09-22T18:47:01.592Z",
    "dateReserved": "2026-08-20T19:02:23.416Z",
    "dateUpdated": "2026-09-22T19:36:45.769Z",
    "state": "PUBLISHED"
  },
  "dataType": "CVE_RECORD",
  "dataVersion": "5.2"
}

GHSA-V9M3-WFH8-5646

Vulnerability from github – Published: 2026-09-22 20:36 – Updated: 2026-09-22 20:36

Summary

MCP Atlassian: Incomplete fix for GHSA-7r34-79r5-rcc9: redirect-based SSRF via unhooked requests session in Jira user-permission lookup

Details

Summary

The fix for the SSRF vulnerability tracked as GHSA-7r34-79r5-rcc9 / CVE-2026-27826 is incomplete. That fix added two defenses: validate_url_for_ssrf() on the per-request X-Atlassian-Jira-Url / X-Atlassian-Confluence-Url headers (blocking a directly-internal base URL), and a redirect-validation hook (_make_ssrf_safe_hook) attached to the fetcher's HTTP session so that an attacker-controlled public host cannot redirect outbound requests to an internal address.

However, one outbound request path does not go through the hooked session. JiraUserMixin._lookup_user_by_permissions issues its request with the module-level requests.get instead of self.jira._session.get, so the redirect-validation hook never runs for it. An unauthenticated attacker (in the HTTP / multi-tenant transport mode that binds 0.0.0.0 with no credentials) can therefore set a public base URL that passes validate_url_for_ssrf(), then have their own server return an HTTP redirect to an internal address. The bare requests.get follows that redirect with no validation, resulting in a blind server-side request to an arbitrary internal host and port.

Affected component

src/mcp_atlassian/jira/users.py, method _lookup_user_by_permissions (the requests.get(...) call):

url = f"{self.config.url}/rest/api/2/user/permission/search"
params = {"query": username, "permissions": "BROWSE"}
...
response = requests.get(           # module-level requests, NOT self.jira._session
    url,
    params=params,
    auth=auth,
    headers=headers,
    verify=self.config.ssl_verify,
)

For comparison, the equivalent non-standard-endpoint call in src/mcp_atlassian/jira/development.py correctly uses the hooked session (self.jira._session.get(...)), and the SSRF redirect hook is attached only to that session in src/mcp_atlassian/servers/dependencies.py (get_session=lambda f: f.jira._session). The bare requests.get in users.py is the one outbound path the hook does not cover.

Details — why the existing defenses do not apply here

self.config.url is attacker-controlled in the header-PAT branch of _get_fetcher (dependencies.py): header_config = spec.config_class(url=url_header_val, auth_type="pat", personal_token=token_header_val, ...).
The middleware validates that header URL with validate_url_for_ssrf() before storing it, so it must resolve to a public address. The attacker simply points it at a public server they control — this passes validation.
Credential validation (_create_and_validate → spec.validate_fn) runs against that same attacker-controlled server, so it returns success and no real Atlassian credentials are required.
The redirect-validation hook is attached to f.jira._session. _lookup_user_by_permissions does not use that session — it uses bare requests.get, which follows redirects (allow_redirects=True by default) with no SSRF check.

Proof of Concept

Preconditions: the server is running in HTTP transport (streamable-http or sse) multi-tenant mode, as described in the GHSA-7r34-79r5-rcc9 advisory (binds 0.0.0.0, per-request header auth, no server-side credentials).

Attacker stands up a public HTTP server http://attacker.example that:
responds to GET /rest/api/2/user/search (and the atlassian client's user-find call) with 200 [] — an empty user list, forcing the direct-lookup fallthrough;
responds to GET /rest/api/2/user/permission/search with 302 Location: http://169.254.169.254/latest/meta-data/ (or any internal host:port).
Attacker sends a tool call to the MCP HTTP endpoint with headers:
X-Atlassian-Jira-Url: http://attacker.example
X-Atlassian-Jira-Personal-Token: anything and invokes a tool that resolves an assignee — e.g. jira_create_issue / jira_update_issue with assignee set to a value that the direct lookup cannot match.
Flow: _get_account_id → _lookup_user_directly returns None (attacker returned []) → _lookup_user_by_permissions → requests.get("http://attacker.example/rest/api/2/user/permission/search?...") → attacker server returns 302 → bare requests follows the redirect to http://169.254.169.254/....

The server makes an outbound GET to the internal target, confirming SSRF.

Impact

Blind, unauthenticated server-side request forgery from the mcp-atlassian host. An attacker who can reach the HTTP transport endpoint can cause the server to issue GET requests to arbitrary internal hosts and ports (internal service reachability and port discovery, triggering of internal GET-actuated endpoints, reachability of cloud metadata endpoints). The response body is not reflected to the attacker except in the narrow case where an internal service returns a JSON object shaped like {"users": [...]}, so this is primarily a blind SSRF: weaker than the original CVE-2026-27826 (no general internal data exfiltration), but the redirect-based internal-reachability that GHSA-7r34-79r5-rcc9 intended to close remains exploitable through this code path in the latest release (v0.21.1).

Suggested Remediation

Route the request through the hooked session instead of the module-level requests, mirroring development.py:

response = self.jira._session.get(
    url,
    params=params,
    verify=self.config.ssl_verify,
)

(The session already carries the appropriate authentication, so the manual auth / Authorization handling can be dropped.) More generally, auditing for any remaining bare requests. / httpx. calls that use self.config.url and routing them through the SSRF-hooked session would prevent recurrence.

Coordinated Disclosure

This appears to be an incomplete fix for GHSA-7r34-79r5-rcc9 (CVE-2026-27826). If you agree, I would kindly ask you to consider requesting a CVE ID for this residual instance through this repository's Security Advisory "Request CVE ID" workflow once confirmed, so that downstream users and distributions can track the additional fix. The severity here is lower than the parent advisory — it is a blind, redirect-only SSRF gated on the HTTP multi-tenant deployment mode — so a Medium rating seems appropriate, and I defer to your judgment on the final score. Thank you very much for your time and for your work on this project.

Severity

5.3 (Medium)


                  
                    CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:L/I:N/A:N

Show details on source website

JSON

To clipboard

{
  "affected": [
    {
      "package": {
        "ecosystem": "PyPI",
        "name": "mcp-atlassian"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            },
            {
              "fixed": "0.22.0"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [
    "CVE-2026-77249"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-918"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2026-09-22T20:36:31Z",
    "nvd_published_at": null,
    "severity": "MODERATE"
  },
  "details": "Summary\n\nThe fix for the SSRF vulnerability tracked as GHSA-7r34-79r5-rcc9 / CVE-2026-27826 is incomplete. That fix added two defenses: validate_url_for_ssrf() on the per-request X-Atlassian-Jira-Url / X-Atlassian-Confluence-Url headers (blocking a directly-internal base URL), and a redirect-validation hook (_make_ssrf_safe_hook) attached to the fetcher\u0027s HTTP session so that an attacker-controlled public host cannot redirect outbound requests to an internal address.\n\nHowever, one outbound request path does not go through the hooked session. JiraUserMixin._lookup_user_by_permissions issues its request with the module-level requests.get instead of self.jira._session.get, so the redirect-validation hook never runs for it. An unauthenticated attacker (in the HTTP / multi-tenant transport mode that binds 0.0.0.0 with no credentials) can therefore set a public base URL that passes validate_url_for_ssrf(), then have their own server return an HTTP redirect to an internal address. The bare requests.get follows that redirect with no validation, resulting in a blind server-side request to an arbitrary internal host and port.\n\nAffected component\n\nsrc/mcp_atlassian/jira/users.py, method _lookup_user_by_permissions (the requests.get(...) call):\n\n    url = f\"{self.config.url}/rest/api/2/user/permission/search\"\n    params = {\"query\": username, \"permissions\": \"BROWSE\"}\n    ...\n    response = requests.get(           # module-level requests, NOT self.jira._session\n        url,\n        params=params,\n        auth=auth,\n        headers=headers,\n        verify=self.config.ssl_verify,\n    )\n\nFor comparison, the equivalent non-standard-endpoint call in src/mcp_atlassian/jira/development.py correctly uses the hooked session (self.jira._session.get(...)), and the SSRF redirect hook is attached only to that session in src/mcp_atlassian/servers/dependencies.py (get_session=lambda f: f.jira._session). The bare requests.get in users.py is the one outbound path the hook does not cover.\n\nDetails \u2014 why the existing defenses do not apply here\n\n1. self.config.url is attacker-controlled in the header-PAT branch of _get_fetcher (dependencies.py): header_config = spec.config_class(url=url_header_val, auth_type=\"pat\", personal_token=token_header_val, ...).\n2. The middleware validates that header URL with validate_url_for_ssrf() before storing it, so it must resolve to a public address. The attacker simply points it at a public server they control \u2014 this passes validation.\n3. Credential validation (_create_and_validate \u2192 spec.validate_fn) runs against that same attacker-controlled server, so it returns success and no real Atlassian credentials are required.\n4. The redirect-validation hook is attached to f.jira._session. _lookup_user_by_permissions does not use that session \u2014 it uses bare requests.get, which follows redirects (allow_redirects=True by default) with no SSRF check.\n\nProof of Concept\n\nPreconditions: the server is running in HTTP transport (streamable-http or sse) multi-tenant mode, as described in the GHSA-7r34-79r5-rcc9 advisory (binds 0.0.0.0, per-request header auth, no server-side credentials).\n\n1. Attacker stands up a public HTTP server http://attacker.example that:\n   - responds to GET /rest/api/2/user/search (and the atlassian client\u0027s user-find call) with 200 [] \u2014 an empty user list, forcing the direct-lookup fallthrough;\n   - responds to GET /rest/api/2/user/permission/search with 302 Location: http://169.254.169.254/latest/meta-data/ (or any internal host:port).\n2. Attacker sends a tool call to the MCP HTTP endpoint with headers:\n   - X-Atlassian-Jira-Url: http://attacker.example\n   - X-Atlassian-Jira-Personal-Token: anything\n     and invokes a tool that resolves an assignee \u2014 e.g. jira_create_issue / jira_update_issue with assignee set to a value that the direct lookup cannot match.\n3. Flow: _get_account_id \u2192 _lookup_user_directly returns None (attacker returned []) \u2192 _lookup_user_by_permissions \u2192 requests.get(\"http://attacker.example/rest/api/2/user/permission/search?...\") \u2192 attacker server returns 302 \u2192 bare requests follows the redirect to http://169.254.169.254/....\n\nThe server makes an outbound GET to the internal target, confirming SSRF.\n\nImpact\n\nBlind, unauthenticated server-side request forgery from the mcp-atlassian host. An attacker who can reach the HTTP transport endpoint can cause the server to issue GET requests to arbitrary internal hosts and ports (internal service reachability and port discovery, triggering of internal GET-actuated endpoints, reachability of cloud metadata endpoints). The response body is not reflected to the attacker except in the narrow case where an internal service returns a JSON object shaped like {\"users\": [...]}, so this is primarily a blind SSRF: weaker than the original CVE-2026-27826 (no general internal data exfiltration), but the redirect-based internal-reachability that GHSA-7r34-79r5-rcc9 intended to close remains exploitable through this code path in the latest release (v0.21.1).\n\nSuggested Remediation\n\nRoute the request through the hooked session instead of the module-level requests, mirroring development.py:\n\n    response = self.jira._session.get(\n        url,\n        params=params,\n        verify=self.config.ssl_verify,\n    )\n\n(The session already carries the appropriate authentication, so the manual auth / Authorization handling can be dropped.) More generally, auditing for any remaining bare requests.* / httpx.* calls that use self.config.url and routing them through the SSRF-hooked session would prevent recurrence.\n\nCoordinated Disclosure\n\nThis appears to be an incomplete fix for GHSA-7r34-79r5-rcc9 (CVE-2026-27826). If you agree, I would kindly ask you to consider requesting a CVE ID for this residual instance through this repository\u0027s Security Advisory \"Request CVE ID\" workflow once confirmed, so that downstream users and distributions can track the additional fix. The severity here is lower than the parent advisory \u2014 it is a blind, redirect-only SSRF gated on the HTTP multi-tenant deployment mode \u2014 so a Medium rating seems appropriate, and I defer to your judgment on the final score. Thank you very much for your time and for your work on this project.",
  "id": "GHSA-v9m3-wfh8-5646",
  "modified": "2026-09-22T20:36:31Z",
  "published": "2026-09-22T20:36:31Z",
  "references": [
    {
      "type": "WEB",
      "url": "https://github.com/sooperset/mcp-atlassian/security/advisories/GHSA-v9m3-wfh8-5646"
    },
    {
      "type": "WEB",
      "url": "https://github.com/sooperset/mcp-atlassian/pull/1448"
    },
    {
      "type": "WEB",
      "url": "https://github.com/sooperset/mcp-atlassian/commit/b041733473f95119dd539542a43c280737a8e460"
    },
    {
      "type": "PACKAGE",
      "url": "https://github.com/sooperset/mcp-atlassian"
    },
    {
      "type": "WEB",
      "url": "https://github.com/sooperset/mcp-atlassian/releases/tag/v0.22.0"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:L/I:N/A:N",
      "type": "CVSS_V3"
    }
  ],
  "summary": "MCP Atlassian:  Incomplete fix for GHSA-7r34-79r5-rcc9: redirect-based SSRF via unhooked requests session in Jira user-permission lookup"
}

PYSEC-2026-4100

Vulnerability from pysec - Published: 2026-10-01 16:38 - Updated: 2026-10-01 17:10

Details

Summary

Affected component

src/mcp_atlassian/jira/users.py, method _lookup_user_by_permissions (the requests.get(...) call):

url = f"{self.config.url}/rest/api/2/user/permission/search"
params = {"query": username, "permissions": "BROWSE"}
...
response = requests.get(           # module-level requests, NOT self.jira._session
    url,
    params=params,
    auth=auth,
    headers=headers,
    verify=self.config.ssl_verify,
)

Details — why the existing defenses do not apply here

self.config.url is attacker-controlled in the header-PAT branch of _get_fetcher (dependencies.py): header_config = spec.config_class(url=url_header_val, auth_type="pat", personal_token=token_header_val, ...).
The middleware validates that header URL with validate_url_for_ssrf() before storing it, so it must resolve to a public address. The attacker simply points it at a public server they control — this passes validation.
Credential validation (_create_and_validate → spec.validate_fn) runs against that same attacker-controlled server, so it returns success and no real Atlassian credentials are required.
The redirect-validation hook is attached to f.jira._session. _lookup_user_by_permissions does not use that session — it uses bare requests.get, which follows redirects (allow_redirects=True by default) with no SSRF check.

Proof of Concept

Attacker stands up a public HTTP server http://attacker.example that:
responds to GET /rest/api/2/user/search (and the atlassian client's user-find call) with 200 [] — an empty user list, forcing the direct-lookup fallthrough;
responds to GET /rest/api/2/user/permission/search with 302 Location: http://169.254.169.254/latest/meta-data/ (or any internal host:port).
Attacker sends a tool call to the MCP HTTP endpoint with headers:
X-Atlassian-Jira-Url: http://attacker.example
X-Atlassian-Jira-Personal-Token: anything and invokes a tool that resolves an assignee — e.g. jira_create_issue / jira_update_issue with assignee set to a value that the direct lookup cannot match.
Flow: _get_account_id → _lookup_user_directly returns None (attacker returned []) → _lookup_user_by_permissions → requests.get("http://attacker.example/rest/api/2/user/permission/search?...") → attacker server returns 302 → bare requests follows the redirect to http://169.254.169.254/....

The server makes an outbound GET to the internal target, confirming SSRF.

Impact

Suggested Remediation

Route the request through the hooked session instead of the module-level requests, mirroring development.py:

response = self.jira._session.get(
    url,
    params=params,
    verify=self.config.ssl_verify,
)

Coordinated Disclosure

Severity

5.3 (Medium)


                  
                    CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:L/I:N/A:N

Impacted products

Name	purl
mcp-atlassian	pkg:pypi/mcp-atlassian

Aliases

JSON

To clipboard

{
  "affected": [
    {
      "package": {
        "ecosystem": "PyPI",
        "name": "mcp-atlassian",
        "purl": "pkg:pypi/mcp-atlassian"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            },
            {
              "fixed": "0.22.0"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ],
      "versions": [
        "0.1.1",
        "0.1.10",
        "0.1.11",
        "0.1.12",
        "0.1.13",
        "0.1.14",
        "0.1.15",
        "0.1.16",
        "0.1.2",
        "0.1.3",
        "0.1.4",
        "0.1.6",
        "0.1.7",
        "0.1.8",
        "0.1.9",
        "0.10.0",
        "0.10.1",
        "0.10.2",
        "0.10.3",
        "0.10.4",
        "0.10.5",
        "0.10.6",
        "0.11.0",
        "0.11.1",
        "0.11.10",
        "0.11.11",
        "0.11.12",
        "0.11.2",
        "0.11.2a2",
        "0.11.3",
        "0.11.4",
        "0.11.5",
        "0.11.6",
        "0.11.7",
        "0.11.8",
        "0.11.9",
        "0.12.0",
        "0.13.0",
        "0.13.1",
        "0.14.0",
        "0.14.1",
        "0.14.2",
        "0.14.3",
        "0.15.0",
        "0.16.0",
        "0.16.1",
        "0.17.0",
        "0.18.0",
        "0.18.1",
        "0.19.0",
        "0.2.0",
        "0.2.1",
        "0.2.2",
        "0.2.3",
        "0.2.4",
        "0.2.5",
        "0.2.6",
        "0.20.0",
        "0.20.1",
        "0.21.0",
        "0.21.1",
        "0.3.0",
        "0.3.1",
        "0.4.0",
        "0.5.0",
        "0.6.0",
        "0.6.1",
        "0.6.2",
        "0.6.3",
        "0.6.4",
        "0.6.5",
        "0.7.0",
        "0.7.1",
        "0.8.0",
        "0.8.1",
        "0.8.2",
        "0.8.3",
        "0.8.4",
        "0.9.0"
      ]
    }
  ],
  "aliases": [
    "CVE-2026-77249",
    "GHSA-v9m3-wfh8-5646"
  ],
  "details": "Summary\n\nThe fix for the SSRF vulnerability tracked as GHSA-7r34-79r5-rcc9 / CVE-2026-27826 is incomplete. That fix added two defenses: validate_url_for_ssrf() on the per-request X-Atlassian-Jira-Url / X-Atlassian-Confluence-Url headers (blocking a directly-internal base URL), and a redirect-validation hook (_make_ssrf_safe_hook) attached to the fetcher\u0027s HTTP session so that an attacker-controlled public host cannot redirect outbound requests to an internal address.\n\nHowever, one outbound request path does not go through the hooked session. JiraUserMixin._lookup_user_by_permissions issues its request with the module-level requests.get instead of self.jira._session.get, so the redirect-validation hook never runs for it. An unauthenticated attacker (in the HTTP / multi-tenant transport mode that binds 0.0.0.0 with no credentials) can therefore set a public base URL that passes validate_url_for_ssrf(), then have their own server return an HTTP redirect to an internal address. The bare requests.get follows that redirect with no validation, resulting in a blind server-side request to an arbitrary internal host and port.\n\nAffected component\n\nsrc/mcp_atlassian/jira/users.py, method _lookup_user_by_permissions (the requests.get(...) call):\n\n    url = f\"{self.config.url}/rest/api/2/user/permission/search\"\n    params = {\"query\": username, \"permissions\": \"BROWSE\"}\n    ...\n    response = requests.get(           # module-level requests, NOT self.jira._session\n        url,\n        params=params,\n        auth=auth,\n        headers=headers,\n        verify=self.config.ssl_verify,\n    )\n\nFor comparison, the equivalent non-standard-endpoint call in src/mcp_atlassian/jira/development.py correctly uses the hooked session (self.jira._session.get(...)), and the SSRF redirect hook is attached only to that session in src/mcp_atlassian/servers/dependencies.py (get_session=lambda f: f.jira._session). The bare requests.get in users.py is the one outbound path the hook does not cover.\n\nDetails \u2014 why the existing defenses do not apply here\n\n1. self.config.url is attacker-controlled in the header-PAT branch of _get_fetcher (dependencies.py): header_config = spec.config_class(url=url_header_val, auth_type=\"pat\", personal_token=token_header_val, ...).\n2. The middleware validates that header URL with validate_url_for_ssrf() before storing it, so it must resolve to a public address. The attacker simply points it at a public server they control \u2014 this passes validation.\n3. Credential validation (_create_and_validate \u2192 spec.validate_fn) runs against that same attacker-controlled server, so it returns success and no real Atlassian credentials are required.\n4. The redirect-validation hook is attached to f.jira._session. _lookup_user_by_permissions does not use that session \u2014 it uses bare requests.get, which follows redirects (allow_redirects=True by default) with no SSRF check.\n\nProof of Concept\n\nPreconditions: the server is running in HTTP transport (streamable-http or sse) multi-tenant mode, as described in the GHSA-7r34-79r5-rcc9 advisory (binds 0.0.0.0, per-request header auth, no server-side credentials).\n\n1. Attacker stands up a public HTTP server http://attacker.example that:\n   - responds to GET /rest/api/2/user/search (and the atlassian client\u0027s user-find call) with 200 [] \u2014 an empty user list, forcing the direct-lookup fallthrough;\n   - responds to GET /rest/api/2/user/permission/search with 302 Location: http://169.254.169.254/latest/meta-data/ (or any internal host:port).\n2. Attacker sends a tool call to the MCP HTTP endpoint with headers:\n   - X-Atlassian-Jira-Url: http://attacker.example\n   - X-Atlassian-Jira-Personal-Token: anything\n     and invokes a tool that resolves an assignee \u2014 e.g. jira_create_issue / jira_update_issue with assignee set to a value that the direct lookup cannot match.\n3. Flow: _get_account_id \u2192 _lookup_user_directly returns None (attacker returned []) \u2192 _lookup_user_by_permissions \u2192 requests.get(\"http://attacker.example/rest/api/2/user/permission/search?...\") \u2192 attacker server returns 302 \u2192 bare requests follows the redirect to http://169.254.169.254/....\n\nThe server makes an outbound GET to the internal target, confirming SSRF.\n\nImpact\n\nBlind, unauthenticated server-side request forgery from the mcp-atlassian host. An attacker who can reach the HTTP transport endpoint can cause the server to issue GET requests to arbitrary internal hosts and ports (internal service reachability and port discovery, triggering of internal GET-actuated endpoints, reachability of cloud metadata endpoints). The response body is not reflected to the attacker except in the narrow case where an internal service returns a JSON object shaped like {\"users\": [...]}, so this is primarily a blind SSRF: weaker than the original CVE-2026-27826 (no general internal data exfiltration), but the redirect-based internal-reachability that GHSA-7r34-79r5-rcc9 intended to close remains exploitable through this code path in the latest release (v0.21.1).\n\nSuggested Remediation\n\nRoute the request through the hooked session instead of the module-level requests, mirroring development.py:\n\n    response = self.jira._session.get(\n        url,\n        params=params,\n        verify=self.config.ssl_verify,\n    )\n\n(The session already carries the appropriate authentication, so the manual auth / Authorization handling can be dropped.) More generally, auditing for any remaining bare requests.* / httpx.* calls that use self.config.url and routing them through the SSRF-hooked session would prevent recurrence.\n\nCoordinated Disclosure\n\nThis appears to be an incomplete fix for GHSA-7r34-79r5-rcc9 (CVE-2026-27826). If you agree, I would kindly ask you to consider requesting a CVE ID for this residual instance through this repository\u0027s Security Advisory \"Request CVE ID\" workflow once confirmed, so that downstream users and distributions can track the additional fix. The severity here is lower than the parent advisory \u2014 it is a blind, redirect-only SSRF gated on the HTTP multi-tenant deployment mode \u2014 so a Medium rating seems appropriate, and I defer to your judgment on the final score. Thank you very much for your time and for your work on this project.",
  "id": "PYSEC-2026-4100",
  "modified": "2026-10-01T17:10:31.317016Z",
  "published": "2026-10-01T16:38:36.437739Z",
  "references": [
    {
      "type": "WEB",
      "url": "https://github.com/sooperset/mcp-atlassian/security/advisories/GHSA-v9m3-wfh8-5646"
    },
    {
      "type": "WEB",
      "url": "https://github.com/sooperset/mcp-atlassian/pull/1448"
    },
    {
      "type": "WEB",
      "url": "https://github.com/sooperset/mcp-atlassian/commit/b041733473f95119dd539542a43c280737a8e460"
    },
    {
      "type": "PACKAGE",
      "url": "https://github.com/sooperset/mcp-atlassian"
    },
    {
      "type": "WEB",
      "url": "https://github.com/sooperset/mcp-atlassian/releases/tag/v0.22.0"
    },
    {
      "type": "PACKAGE",
      "url": "https://pypi.org/project/mcp-atlassian"
    },
    {
      "type": "ADVISORY",
      "url": "https://github.com/advisories/GHSA-v9m3-wfh8-5646"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-77249"
    }
  ],
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:L/I:N/A:N",
      "type": "CVSS_V3"
    }
  ],
  "summary": "MCP Atlassian:  Incomplete fix for GHSA-7r34-79r5-rcc9: redirect-based SSRF via unhooked requests session in Jira user-permission lookup"
}

Sightings

Author	Source	Type	Date	Other

Nomenclature

Seen: The vulnerability was mentioned, discussed, or observed by the user.
Confirmed: The vulnerability has been validated from an analyst's perspective.
Published Proof of Concept: A public proof of concept is available for this vulnerability.
Exploited: The vulnerability was observed as exploited by the user who reported the sighting.
Patched: The vulnerability was observed as successfully patched by the user who reported the sighting.
Not exploited: The vulnerability was not observed as exploited by the user who reported the sighting.
Not confirmed: The user expressed doubt about the validity of the vulnerability.
Not patched: The vulnerability was not observed as successfully patched by the user who reported the sighting.

The MITRE ATT&CK techniques below are AI-generated suggestions, inferred from the description of the vulnerability by the CIRCL/vulnerability-attack-technique-classification-roberta-base model, served locally by ML-Gateway. They have not been verified by an analyst and are provided for guidance only.
The approach is described in our paper Mapping CVEs to MITRE ATT&CK Techniques: A Curated Gold-Set Classifier and the Limits of LLM-Assisted Label Expansion.
Browse all ATT&CK techniques and the vulnerabilities related to each.

Related by attack behaviour

Vulnerabilities whose description is nearest to this one in the vector space of the CIRCL/vulnerability-attack-technique-biencoder model. This is a similarity search over the bi-encoder space (plain cosine), not a classification, and it has no measured accuracy.

Action not permitted

BREW-MCP-ATLASSIAN-CVE-2… (CVE-2026-77249)

CVE-2026-77249 (GCVE-0-2026-77249)

GHSA-V9M3-WFH8-5646

PYSEC-2026-4100

Tags

Sightings

Nomenclature

Related by attack behaviour