CVE-2026-58201 in Lokka
Summary
by MITRE • 09/15/2026
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.
Be aware that VulDB is the high quality source for vulnerability data.
Analysis
by VulDB Data Team • 09/15/2026
The vulnerability identified in Lokka, specifically within versions prior to 2.1.2, represents a critical security flaw rooted in improper URL construction and authority parsing logic. As a Model Context Protocol server designed for Microsoft 365 integration, the application handles sensitive authentication tokens required to interact with Azure Resource Manager services. The core technical defect lies in the src/mcp/src/main.ts module, where user-controlled path values are appended directly to the management.azure.com base URL using simple string concatenation rather than robust URI parsing and validation mechanisms. This approach fails to account for edge cases in how different HTTP clients and libraries interpret URLs containing specific special characters or structural anomalies.
When a specially crafted input is provided as part of the request path, it can exploit ambiguities in standard URL authority parsing rules. Specifically, by inserting sequences such as double slashes followed by an at-sign (@) or other delimiter-based manipulations, an attacker can effectively shift the perceived host portion of the URI. This manipulation causes the underlying HTTP client to misidentify the target server for authentication requests. Instead of directing the request and its associated credentials to the legitimate Azure Resource Manager endpoint, the system routes them to a domain controlled by the attacker or an unintended third-party service.
The operational impact of this vulnerability is severe due to the nature of the data exposed. The affected component transmits Azure Resource Manager bearer tokens, which are high-privilege authentication credentials used to access and manage cloud resources. If these tokens are sent to an unauthorized host, they can be intercepted by malicious actors. Possession of a valid bearer token allows for full impersonation of the authenticated user or service principal within the Microsoft 365 environment. This could lead to unauthorized access to sensitive data, modification of infrastructure configurations, deployment of malicious resources, and potential lateral movement across connected systems. The breach compromises not only confidentiality but also integrity and availability of cloud services dependent on these credentials.
This flaw aligns with CWE-20 Improper Input Validation and CWE-798 Use of Hard-coded Credentials in the context of token handling, as well as ATT&CK technique T1556 which covers modifying authentication processes to bypass security controls. The vulnerability highlights the risks associated with dynamic URL construction without rigorous sanitization or validation against expected domain patterns. It underscores the necessity for developers to use standardized URI libraries that enforce strict parsing rules rather than relying on string manipulation, ensuring that authority components remain immutable unless explicitly and safely modified by trusted logic.
To mitigate this risk, organizations must immediately upgrade Lokka to version 2.1.2 or later, where the URL construction logic has been corrected to prevent path-based host injection attacks. In addition to patching, security teams should audit existing deployments for any potential exploitation indicators in access logs, particularly looking for requests with unusual URI structures targeting external domains instead of management.azure.com. Implementing strict allow-lists for permitted hosts and utilizing Content Security Policy headers can further reduce the attack surface. Continuous monitoring for anomalous outbound traffic carrying authentication tokens is also recommended to detect any successful exfiltration attempts that may have occurred prior to remediation.