<?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-10-26T12:45:54.296186+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-58497</id>
    <title>fkie_cve-2026-58497</title>
    <updated>2026-10-26T12:45:54.307267+00:00</updated>
    <content type="xhtml">
      <div xmlns="http://www.w3.org/1999/xhtml">
        <p>Uni-CLI gives people and agents one command interface for websites, browsers, desktop applications, local tools, and MCP. Prior to version 0.225.2, Uni-CLI exposed the legacy JSON-RPC-over-HTTP MCP transport on loopback without validating browser Origin headers before routing requests. A malicious web page could send a CORS simple POST request, such as text/plain, to the local /mcp endpoint and deliver a JSON-RPC body to the dispatcher. If the user had started the local MCP HTTP transport, that page could drive tools/call requests against the user's local Uni-CLI server. The Streamable HTTP transport already enforced this browser-to-localhost boundary. The legacy stateless HTTP path did not, so the two HTTP transports had drifted. This issue is about the browser-to-localhost boundary; it does not change Uni-CLI's local-code-execution trust model. This issue has been patched in version 0.225.2.</p>
      </div>
    </content>
    <link href="https://db.gcve.eu/vuln/fkie_cve-2026-58497"/>
  </entry>
  <entry>
    <id>https://db.gcve.eu/vuln/ghsa-v3f4-w7r7-v3hm</id>
    <title>GHSA-v3f4-w7r7-v3hm — Uni-CLI: Legacy HTTP MCP transport accepted browser-originated localhost requests</title>
    <updated>2026-10-26T12:45:54.307359+00:00</updated>
    <content type="xhtml">
      <div xmlns="http://www.w3.org/1999/xhtml"><p><strong>Affected:</strong> npm: @zenalexa/unicli</p>
<p>## Impact</p>
<p>Uni-CLI versions before 0.225.2 exposed the legacy JSON-RPC-over-HTTP MCP transport on loopback without validating browser Origin headers before routing requests. A malicious web page could send a CORS simple POST request, such as text/plain, to the local /mcp endpoint and deliver a JSON-RPC body to the dispatcher. If the user had started the local MCP HTTP transport, that page could drive tools/call requests against the user's local Uni-CLI server.</p>
<p>The Streamable HTTP transport already enforced this browser-to-localhost boundary. The legacy stateless HTTP path did not, so the two HTTP transports had drifted. This issue is about the browser-to-localhost boundary; it does not change Uni-CLI's local-code-execution trust model.</p>
<p>## Patches</p>
<p>Version 0.225.2 fixes the issue by moving the Origin policy into a shared guard and applying it before routing in both HTTP transports. Non-loopback browser Origins are rejected with HTTP 403 before health, OAuth, or /mcp dispatch runs. Non-browser clients that omit Origin remain supported.</p>
<p>## Workarounds</p>
<p>Upgrade to 0.225.2 or later. If upgrading is not immediately possible, do not expose the legacy HTTP MCP transport to browser-originated traffic; use the default stdio transport or the Streamable HTTP transport instead.</p>
<p>## Credits</p>
<p>Reported privately by Ryan Vonbrubeck ([@dodge1218](https://github.com/dodge1218)).</p></div>
    </content>
    <link href="https://db.gcve.eu/vuln/ghsa-v3f4-w7r7-v3hm"/>
  </entry>
</feed>
