https://vulnerability.circl.lu Contains only the most 10 recent entries. http://www.rssboard.org/rss-specification python-feedgen en Tue, 29 Sep 2026 21:10:06 +0000 https://vulnerability.circl.lu/vuln/fkie_cve-2026-77261 <p>MCP Atlassian is a Model Context Protocol (MCP) server for Atlassian products (Confluence and Jira). Prior to 0.22.0, _make_ssrf_safe_hook is omitted from JiraFetcher and ConfluenceFetcher sessions created through the basic-auth and oauth_pat branches. If an attacker-controlled or compromised configured Atlassian instance returns a redirect to an internal address, those sessions can follow the redirect without revalidating its destination. This issue is fixed in version 0.22.0.</p> <p>MCP Atlassian is a Model Context Protocol (MCP) server for Atlassian products (Confluence and Jira). Prior to 0.22.0, _make_ssrf_safe_hook is omitted from JiraFetcher and ConfluenceFetcher sessions created through the basic-auth and oauth_pat branches. If an attacker-controlled or compromised configured Atlassian instance returns a redirect to an internal address, those sessions can follow the redirect without revalidating its destination. This issue is fixed in version 0.22.0.</p> https://vulnerability.circl.lu/vuln/fkie_cve-2026-77261 https://vulnerability.circl.lu/vuln/ghsa-6529-c226-h328 <p><strong>Affected:</strong> PyPI: mcp-atlassian</p> <p>### Summary</p> <p>`_make_ssrf_safe_hook()` blocks HTTP redirects to private/internal IPs by validating the `Location` header before the client follows a `3xx` response. The problem is that this hook is only attached in one of three authentication branches — the header-PAT path. Basic auth and OAuth branches skip it entirely, so if the connected Atlassian server returns a redirect to something like `http://169.254.169.254/`, the `requests` session follows it without complaint.</p> <p>This is an incomplete fix for GHSA-7r34-79r5-rcc9. The hook works fine when it&#39;s there — it just isn&#39;t there for most production auth configurations.</p> <p>### Details</p> <p>In `src/mcp_atlassian/servers/dependencies.py`, three branches construct a fetcher and call `_create_and_validate()`. Only Branch 1 passes `attach_ssrf_hook=True`:</p> <p>```python # Branch 1 (header PAT) — hook attached return _create_and_validate(request, spec, header_config, &#34;header_pat&#34;, attach_ssrf_hook=True)</p> <p># Branch 2 (basic auth) — hook missing return _create_and_validate(request, spec, user_config, &#34;basic&#34;, user_email=user_email)</p> <p># Branch 3 (OAuth/PAT) — hook missing return _create_and_validate(request, spec, user_config, &#34;oauth_pat&#34;, user_email=user_email) ```</p> <p>`attach_ssrf_hook` defaults to `False`, so branches 2 and 3 silently skip the protection. The hook itself (`_make_ssrf_safe_hook`) is straightforward — it checks `response.is_redirect`, grabs the `…</p> <p><strong>Affected:</strong> PyPI: mcp-atlassian</p> <p>### Summary</p> <p>`_make_ssrf_safe_hook()` blocks HTTP redirects to private/internal IPs by validating the `Location` header before the client follows a `3xx` response. The problem is that this hook is only attached in one of three authentication branches — the header-PAT path. Basic auth and OAuth branches skip it entirely, so if the connected Atlassian server returns a redirect to something like `http://169.254.169.254/`, the `requests` session follows it without complaint.</p> <p>This is an incomplete fix for GHSA-7r34-79r5-rcc9. The hook works fine when it&#39;s there — it just isn&#39;t there for most production auth configurations.</p> <p>### Details</p> <p>In `src/mcp_atlassian/servers/dependencies.py`, three branches construct a fetcher and call `_create_and_validate()`. Only Branch 1 passes `attach_ssrf_hook=True`:</p> <p>```python # Branch 1 (header PAT) — hook attached return _create_and_validate(request, spec, header_config, &#34;header_pat&#34;, attach_ssrf_hook=True)</p> <p># Branch 2 (basic auth) — hook missing return _create_and_validate(request, spec, user_config, &#34;basic&#34;, user_email=user_email)</p> <p># Branch 3 (OAuth/PAT) — hook missing return _create_and_validate(request, spec, user_config, &#34;oauth_pat&#34;, user_email=user_email) ```</p> <p>`attach_ssrf_hook` defaults to `False`, so branches 2 and 3 silently skip the protection. The hook itself (`_make_ssrf_safe_hook`) is straightforward — it checks `response.is_redirect`, grabs the `…</p> https://vulnerability.circl.lu/vuln/ghsa-6529-c226-h328