CVE-2026-114123 in d365fo-mcp-server
Summary
by MITRE • 10/22/2026
D365 F&O MCP Server is a Model Context Protocol server for querying Dynamics 365 Finance & Operations X++ code and metadata. Prior to version 1.11.0, the officially documented Azure one-click deployment uses infrastructure/azuredeploy.json and infrastructure/main.bicep to default the apiKey parameter to an empty string and pass it to the App Service API_KEY setting. With API_KEY unset or empty, src/middleware/apiKeyAuth.ts passes requests through without authentication, while src/index.ts binds the HTTP listener to 0.0.0.0 by default. If the deployer leaves the optional key blank and does not add separate network restrictions or upstream authentication, the resulting public App Service allows unauthenticated JSON-RPC tools/call requests to /mcp. The deployment's MCP_SERVER_MODE=read-only setting does not prevent anonymous access to read/search tools, including search, get_object_info, batch_get_info, extension_info, security_info, find_references, and find_event_handlers, exposing indexed proprietary X++ source snippets and metadata. Exposed information can include business logic, extension and event-handler wiring, security-role and privilege structure, and labels originally indexed from PackagesLocalDirectory. Deployments protected by a configured API key, effective upstream authentication, or network restrictions preventing attacker access are outside this unauthenticated exposure scenario. This issue is fixed in version 1.11.0.
Be aware that VulDB is the high quality source for vulnerability data.
Analysis
by VulDB Data Team • 10/22/2026
The vulnerability identified involves the Dynamics 365 Finance and Operations Model Context Protocol server, specifically within versions prior to 1.11.0. This service acts as an interface for querying X++ code and metadata associated with Microsoft Dynamics environments. The core technical flaw stems from a misconfiguration in the default Azure deployment templates, namely infrastructure/azuredeploy.json and infrastructure/main.bicep. These templates incorrectly set the apiKey parameter to an empty string by default, which is then passed directly to the App Service API_KEY setting. This configuration error results in the application middleware located at src/middleware/apiKeyAuth.ts failing to enforce authentication checks because it perceives no key requirement when the value is null or blank. Consequently, requests are processed without any form of identity verification or access control validation.
Compounding this authentication bypass is the network binding behavior defined in src/index.ts. The HTTP listener defaults to binding on 0.0.0.0, which makes the service accessible from all available network interfaces rather than restricting it to localhost or a specific private subnet. When combined with the lack of API key enforcement, this creates a scenario where any external actor can reach the endpoint without needing credentials. Although the deployment includes an MCP_SERVER_MODE setting configured as read-only, this parameter only restricts write operations and does not mitigate the risk associated with unauthenticated read access. Therefore, attackers are able to interact freely with various tools such as search, get_object_info, batch_get_info, extension_info, security_info, find_references, and find_event_handlers via JSON-RPC calls to the /mcp endpoint.
The operational impact of this vulnerability is significant due to the sensitive nature of the data exposed through these read-only endpoints. Attackers can retrieve indexed proprietary X++ source snippets and metadata that were originally extracted from PackagesLocalDirectory. This exposure reveals critical business logic, extension wiring details, event-handler configurations, security role structures, privilege definitions, and localized labels. Such information provides a comprehensive map of the application's architecture and security posture, enabling adversaries to identify potential attack vectors, understand authentication mechanisms, and plan further exploitation steps with high precision. The disclosure of proprietary code also poses intellectual property risks for organizations relying on this service.
This vulnerability aligns with CWE-287, which describes Improper Authentication, as the system fails to verify identity before granting access to sensitive resources. It is also related to CWE-200, Exposure of Sensitive Information to an Unauthorized Actor, given the leakage of internal code structures and security configurations. In terms of the MITRE ATT&CK framework, this flaw facilitates reconnaissance activities by allowing adversaries to gather information about the application's structure and defenses without detection or authentication barriers. The attack path leverages standard web protocols over TCP/IP, potentially falling under techniques associated with network service discovery if viewed broadly, but primarily represents a direct exploitation of misconfigured access controls.
To mitigate this risk, organizations must upgrade to version 1.11.0 where the default configuration has been corrected to require authentication by default or enforce stricter security boundaries. For deployments that cannot be immediately upgraded, administrators should manually configure the API_KEY parameter with a strong, unique value in the Azure App Service settings rather than leaving it empty. Additionally, network-level restrictions such as IP allow-lists via Azure Firewall or Virtual Network service endpoints should be implemented to limit access to trusted internal networks only. Implementing upstream authentication proxies that validate requests before they reach the application layer provides an additional defense-in-depth measure. Regular auditing of deployment templates and configuration files is essential to ensure that default settings do not inadvertently expose sensitive services to the public internet.