High

A critical architectural weakness has been identified in Microsoft Azure’s Private Endpoint and Private Link implementation, enabling denial-of-service (DoS) conditions against production Azure resources without directly modifying the targeted service. The issue impacts more than 5% of Azure storage accounts and can disrupt essential services including Microsoft Azure Key Vault, Azure Cosmos DB, Azure Container Registry, Azure Functions, and Azure OpenAI Service. The flaw arises from DNS resolution behavior when Private Endpoints are deployed across multiple virtual networks (VNets), creating a scenario where legitimate services become unreachable even though their public endpoints remain operational.

According to researcher, the root cause lies in how Azure Private Link manages Private DNS zones. When a Private Endpoint for a storage account is created in one virtual network (e.g., VNET2), Azure automatically generates a Private DNS zone and links it to that network. If administrators link this DNS zone to another virtual network (e.g., VNET1), Azure forces all storage-related DNS queries in VNET1 to resolve via the Private DNS zone. If no corresponding DNS “A” record exists in that zone for the storage account within VNET1’s context, DNS resolution fails entirely. This results in a DoS condition where virtual machines cannot resolve the storage account hostname, despite the public endpoint remaining unchanged and accessible. The outage is therefore caused purely by DNS misconfiguration within Private Link not by service compromise or direct tampering.

The vulnerability manifests in three primary scenarios. First, accidental internal misconfiguration may occur when administrators deploy Private Endpoints to strengthen security but unintentionally introduce DNS conflicts. Second, third-party security vendors implementing Private Endpoints for scanning or monitoring purposes may inadvertently trigger service disruptions. Third, malicious actors with authorized access to the Azure environment can intentionally deploy Private Endpoints as a DoS vector. The broader operational impact can be severe: disruption of storage accounts can break Azure Functions and application deployment workflows, while DoS attacks against Key Vault instances can halt any process dependent on stored secrets potentially stopping critical business operations across entire organizations.

Microsoft has acknowledged the issue as a known limitation and offers two partial mitigations. The first allows administrators to enable a “fallback to internet” option when creating virtual network links, permitting DNS resolution to revert to public endpoints when no matching Private DNS record exists—though this undermines Private Link’s core design principle of routing traffic exclusively through Azure’s backbone network. The second mitigation requires manually creating DNS records within Private DNS zones for affected resources, a solution that introduces significant operational overhead and poor scalability in large environments. To detect exposure, defenders can use Azure Resource Graph Explorer queries to identify VNets linked to Private DNS zones and storage accounts that allow public endpoint access without Private Endpoint associations. Ultimately, organizations must carefully manage DNS configurations and fully understand Private Link’s binary resolution behavior to prevent unintended outages and potential DoS exploitation.