<?xml version='1.0' encoding='UTF-8'?>
<?xml-stylesheet href="/static/style.xsl" type="text/xsl"?>
<feed xmlns="http://www.w3.org/2005/Atom" xml:lang="en">
  <id>https://vulnerability.circl.lu/rss/recent/all/10</id>
  <title>Most recent entries from all</title>
  <updated>2026-10-08T09:34:36.774352+00:00</updated>
  <author>
    <name>Vulnerability-Lookup</name>
    <email>info@circl.lu</email>
  </author>
  <link href="https://vulnerability.circl.lu" rel="alternate"/>
  <generator uri="https://lkiesow.github.io/python-feedgen" version="1.0.0">python-feedgen</generator>
  <subtitle>Contains only the most 10 recent entries.</subtitle>
  <entry>
    <id>https://vulnerability.circl.lu/vuln/brew-mcp-atlassian-ghsa-489g-7rxv-6c8q</id>
    <title>BREW-mcp-atlassian-GHSA-489g-7rxv-6c8q — MCP Atlassian is a Model Context Protocol (MCP): DNS-rebinding TOCTOU bypass of the SSRF fix (CVE-2026-27826): unauthen…</title>
    <updated>2026-10-08T09:34:36.776312+00:00</updated>
    <content type="xhtml">
      <div xmlns="http://www.w3.org/1999/xhtml"><p><strong>Affected:</strong> Homebrew: mcp-atlassian</p>
<p>MCP Atlassian is a Model Context Protocol (MCP) server for Atlassian products (Confluence and Jira). From 0.17.0 until 0.22.0, validate_url_for_ssrf resolves the attacker-controlled X-Atlassian-Jira-Url and X-Atlassian-Confluence-Url header host once at middleware time, but the outbound request is built with the raw hostname and resolves it again at connection time with no IP pinning. An attacker-controlled DNS-rebinding name can return a public IP during validation and 169.254.169.254 or another internal IP during connection, enabling unauthenticated server-side requests to cloud metadata or internal services. The flaw spans src/mcp_atlassian/utils/urls.py, src/mcp_atlassian/servers/main.py, and src/mcp_atlassian/servers/dependencies.py; validate_url_for_ssrf returns only a verdict rather than a pinned IP, UserTokenMiddleware processes the attacker-controlled headers before fetcher creation, and the Jira and Confluence fetchers use the raw hostname. This issue is fixed in version 0.22.0.</p></div>
    </content>
    <link href="https://vulnerability.circl.lu/vuln/brew-mcp-atlassian-ghsa-489g-7rxv-6c8q"/>
  </entry>
  <entry>
    <id>https://vulnerability.circl.lu/vuln/cve-2026-73497</id>
    <title>CVE-2026-73497 — MCP Atlassian is a Model Context Protocol (MCP): DNS-rebinding TOCTOU bypass of the SSRF fix (CVE-2026-27826): unauthen…</title>
    <updated>2026-10-08T09:34:36.776406+00:00</updated>
    <content type="xhtml">
      <div xmlns="http://www.w3.org/1999/xhtml"><p><strong>Affected:</strong> sooperset mcp-atlassian</p>
<p>MCP Atlassian is a Model Context Protocol (MCP) server for Atlassian products (Confluence and Jira). From 0.17.0 until 0.22.0, validate_url_for_ssrf resolves the attacker-controlled X-Atlassian-Jira-Url and X-Atlassian-Confluence-Url header host once at middleware time, but the outbound request is built with the raw hostname and resolves it again at connection time with no IP pinning. An attacker-controlled DNS-rebinding name can return a public IP during validation and 169.254.169.254 or another internal IP during connection, enabling unauthenticated server-side requests to cloud metadata or internal services. The flaw spans src/mcp_atlassian/utils/urls.py, src/mcp_atlassian/servers/main.py, and src/mcp_atlassian/servers/dependencies.py; validate_url_for_ssrf returns only a verdict rather than a pinned IP, UserTokenMiddleware processes the attacker-controlled headers before fetcher creation, and the Jira and Confluence fetchers use the raw hostname. This issue is fixed in version 0.22.0.</p></div>
    </content>
    <link href="https://vulnerability.circl.lu/vuln/cve-2026-73497"/>
  </entry>
</feed>
