Lokka MCP Server URL Parsing Flaw Leads to Azure Bearer Token Leakage

Technical Analysis

The Lokka-Microsoft tool builds outbound requests to management.azure.com by string-concatenating a caller-supplied 'path' parameter rather than using safe URL construction or allow-listing. A path containing characters that alter authority parsing (e.g., '@', '\\', or scheme/host injection sequences) can cause the resulting URL to resolve to an attacker-controlled host while the client still attaches its Azure Resource Manager bearer token, which is normally scoped only for management.azure.com. Since MCP tool arguments are frequently populated from LLM output that may itself be influenced by prompt injection in upstream data (emails, tickets, documents processed by the agent), an attacker who can influence the agent's tool-call parameters gains a path to exfiltrate live ARM tokens without needing direct access to the MCP server or its host credentials. This crosses the boundary between the LLM/agent planning layer and the tool-execution layer, turning an input-validation bug into a credential theft primitive usable via agentic automation.

Affected Systems

Lokka MCP server; protocols: MCP

Detection Signatures

• Outbound HTTPS requests to management.azure.com carrying Authorization: Bearer headers followed by requests to unexpected/non-Azure hosts within the same tool invocation
• Tool call 'path' parameters containing '@', '\\', '%40', double-slashes, or embedded scheme indicators (http://, https://) unexpected in a relative resource path
• MCP server logs showing constructed request URLs whose host does not match management.azure.com despite an ARM-scoped token being attached
• Anomalous DNS resolutions or egress to non-Microsoft domains immediately following Lokka tool invocations

Remediation Steps

1. 1

   Upgrade Lokka MCP server

   Update to version 2.1.2 or later, which fixes the URL construction vulnerability.

2. 2

   Use safe URL construction

   Replace string concatenation with a proper URL builder/parser that validates the resolved authority matches management.azure.com before sending requests.

3. 3

   Enforce token scoping and egress controls

   Restrict outbound network egress from the MCP server host to only Microsoft Graph/Azure management endpoints via firewall or proxy allow-listing, independent of application-level validation.

4. 4

   Sanitize and validate agent-supplied path parameters

   Apply strict allow-list validation (character set, no scheme/authority indicators) on any path parameter before it is used in URL construction, regardless of whether it originates from an LLM or direct user input.

5. 5

   Monitor token usage anomalies

   Implement logging/alerting for ARM bearer token usage against unexpected hostnames to detect exploitation attempts or residual misconfigurations.