<?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-04T18:45:46.535619+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/fkie_cve-2026-58201</id>
    <title>fkie_cve-2026-58201</title>
    <updated>2026-10-04T18:45:46.574853+00:00</updated>
    <content type="xhtml">
      <div xmlns="http://www.w3.org/1999/xhtml">
        <p>Lokka is a Model Context Protocol server for Microsoft 365, including Microsoft Graph and other services. Prior to 2.1.2, the Lokka-Microsoft tool in src/mcp/src/main.ts uses direct URL string concatenation to append the user-controlled path value to the management.azure.com base URL. A specially crafted path can alter URL authority parsing and cause an Azure Resource Manager bearer token to be sent to an unintended host. This issue is fixed in version 2.1.2.</p>
      </div>
    </content>
    <link href="https://vulnerability.circl.lu/vuln/fkie_cve-2026-58201"/>
  </entry>
  <entry>
    <id>https://vulnerability.circl.lu/vuln/ghsa-g2gw-q38m-vjfc</id>
    <title>GHSA-g2gw-q38m-vjfc — Lokka: Azure Resource Manager URL path validation issue</title>
    <updated>2026-10-04T18:45:46.574957+00:00</updated>
    <content type="xhtml">
      <div xmlns="http://www.w3.org/1999/xhtml"><p><strong>Affected:</strong> npm: @merill/lokka</p>
<p>Lokka versions prior to 2.1.2 constructed Azure Resource Manager request URLs using direct string concatenation with user-controlled path input. Specially crafted path values could alter URL authority parsing and cause Azure Resource Manager bearer tokens to be sent to an unintended host. Version 2.1.2 fixes the issue by validating Azure paths before token acquisition and constructing Azure Resource Manager URLs with the standard URL API while preserving the expected management.azure.com host.</p>
<p>Reported by 정해창 &lt;haechang__@naver.com&gt;</p></div>
    </content>
    <link href="https://vulnerability.circl.lu/vuln/ghsa-g2gw-q38m-vjfc"/>
  </entry>
</feed>
