<?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://db.gcve.eu/rss/recent/all/10</id>
  <title>Most recent entries from all</title>
  <updated>2026-09-28T13:09:30.819533+00:00</updated>
  <author>
    <name>Vulnerability-Lookup</name>
    <email>info@gcve.eu</email>
  </author>
  <link href="https://db.gcve.eu" 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://db.gcve.eu/vuln/fkie_cve-2026-77244</id>
    <title>fkie_cve-2026-77244</title>
    <updated>2026-09-28T13:09:30.837875+00:00</updated>
    <content type="xhtml">
      <div xmlns="http://www.w3.org/1999/xhtml">
        <p>MCP Atlassian is a Model Context Protocol (MCP) server for Atlassian products (Confluence and Jira). Prior to 0.22.0, the HTTP transport accepts requests without a verified user identity and downstream fetcher construction falls back to the operator's globally configured Jira or Confluence credentials. A network client that can reach the MCP endpoint can invoke Atlassian tools as the operator, including read and write operations available to that account. The advisory traces the vulnerable input and processing flow through UserTokenMiddleware, AtlassianOpaqueTokenVerifier, _get_fetcher, and streamable-http, which identify the affected entry points, controls, and code paths. This issue is fixed in version 0.22.0.</p>
      </div>
    </content>
    <link href="https://db.gcve.eu/vuln/fkie_cve-2026-77244"/>
  </entry>
  <entry>
    <id>https://db.gcve.eu/vuln/ghsa-wrhw-j3f9-8vc6</id>
    <title>GHSA-wrhw-j3f9-8vc6 — [mcp-atlassian] Authentication bypass in HTTP transport: AtlassianOpaqueTokenVerifier accepts any non-empty token</title>
    <updated>2026-09-28T13:09:30.838067+00:00</updated>
    <content type="xhtml">
      <div xmlns="http://www.w3.org/1999/xhtml"><p><strong>Affected:</strong> PyPI: mcp-atlassian</p>
<p>**Description**</p>
<p>mcp-atlassian deploys in two common patterns:</p>
<p>Pattern A (single-user, server-side credentials): operator sets
    JIRA_USERNAME + JIRA_API_TOKEN (or CONFLUENCE_USERNAME + CONFLUENCE_API_TOKEN)
    in environment variables. Server uses these to call Jira/Confluence.
    This is the documented quickstart pattern.</p>
<p>Pattern B (multi-user, OAuth or per-request PAT): operator sets up OAuth
    proxy or accepts per-user tokens via Authorization or service headers.</p>
<p>The authentication mechanism in HTTP transport has two issues that combine
to permit unauthenticated access to Pattern A deployments:</p>
<p>1. AtlassianOpaqueTokenVerifier.verify_token() at
   `src/mcp_atlassian/utils/token_verifier.py` accepts any non-empty string
   as a valid token:</p>
<p>async def verify_token(self, token: str) -&gt; AccessToken | None:
           if not token:
               return None
           scopes = self.required_scopes or []
           return AccessToken(
               token=token,
               client_id="atlassian",
               scopes=scopes,
               expires_at=int(time.time()) + 86400 * 30,
           )</p>
<p>The docstring documents this: "we accept non-empty tokens and attach
   the required scopes."</p>
<p>2. The default deployment does NOT enable the OAuth proxy auth provider
   (OAUTH_PROXY_ENABLE_ENV defaults to false; main.py:726). When
   `_build_auth_provider()` returns None, FastMCP HTTP transport accepts
   requests with no authentication challenge.</p>
<p>3. `User…</p></div>
    </content>
    <link href="https://db.gcve.eu/vuln/ghsa-wrhw-j3f9-8vc6"/>
  </entry>
</feed>
