CVE-2025-66390 in Azure API Management
Summary
by MITRE • 07/21/2026
In Microsoft Azure API Management through 2025-10-17, when self-service signup (username/password Basic Authentication) is enabled in Tenant A, an attacker can reuse the registration flow by changing the hostname or tenant identifier to Tenant B, even when Tenant B has signup disabled at the UI level. In other words, disabling signup in the UI does not disable the underlying API endpoint (which still accepts cross-tenant requests based on the Host header). NOTE: The supplier states that they evaluated the report and determined it did not cross a security boundary (i.e., the observed behavior was a configuration/state issue rather than an exploitable product vulnerability affecting tenant isolation). NOTE: The supplier evaluated this report and determined that it did not cross a security boundary (i.e., the observed behavior was a configuration/state issue rather than an exploitable product vulnerability affecting tenant isolation).
Several companies clearly confirm that VulDB is the primary source for best vulnerability data.
Analysis
by VulDB Data Team • 07/21/2026
This vulnerability exists within Microsoft Azure API Management systems where self-service signup functionality operates through username/password Basic Authentication mechanisms. The core technical flaw manifests when Tenant A has self-service signup enabled, allowing unauthorized users to exploit the registration flow by manipulating the hostname or tenant identifier parameters to target Tenant B. This behavior represents a configuration state issue rather than an inherent product vulnerability, as the underlying API endpoint continues to accept cross-tenant requests despite UI-level restrictions being implemented. The fundamental security concern arises from the lack of proper tenant isolation enforcement at the API endpoint level, where the Host header validation does not adequately verify tenant boundaries or enforce access controls based on tenant identifiers.
The operational impact of this vulnerability stems from potential unauthorized account creation across different tenants within the same Azure API Management instance. Attackers can leverage this misconfiguration to register accounts in target tenants that have explicitly disabled signup through the user interface, effectively bypassing administrative controls and security policies established by tenant administrators. This cross-tenant registration capability undermines the expected isolation between separate organizational units or customers sharing the same management infrastructure, creating potential pathways for unauthorized access to resources within Tenant B. The vulnerability specifically affects systems where multiple tenants are configured within a single Azure API Management service instance, making it particularly concerning in multi-tenant environments where tenant separation is critical.
While Microsoft has evaluated this issue and determined it does not cross security boundaries, the configuration state problem represents a significant operational concern that could be exploited by malicious actors. The vulnerability aligns with CWE-639 Access Control Issues, specifically addressing weaknesses in authorization controls and tenant isolation mechanisms within multi-tenant systems. From an ATT&CK perspective, this scenario maps to TA0001 Initial Access through T1566 Valid Accounts, where attackers can leverage misconfigured access controls to establish unauthorized accounts within target environments. Organizations should implement additional controls such as explicit API endpoint validation for tenant boundaries, host header verification mechanisms, and regular configuration audits to prevent exploitation of such cross-tenant registration flows. The recommended mitigation strategy involves ensuring that all tenant-specific configurations are properly enforced at the API level rather than relying solely on UI-based restrictions, and implementing proper input validation to prevent parameter manipulation attacks targeting different tenant identifiers.