Cross-tenant Event Grid Privilege Escalation Vulnerability

While developing a new feature for The Collective’s Azure Managed Service, the Azure Team stumbled upon an Azure Event Grid System Topic vulnerability allowing us to view Event Subscriptions data for all tenants that had an Event Subscription configured due to a flaw in the filtering mechanism Microsoft used for displaying data to their customers. 

This vulnerability was disclosed through Microsoft Security Response Center as ‘VULN-162828’ which was classified as ‘Critical’ under the ‘Elevation of Privilege’ topic and later disclosed as ‘CVE-2025-59273’. As a trusted Microsoft partner, we wanted to ensure that Microsoft could take appropriate measures and get this flaw patched as soon as possible to safeguard our and most importantly, all customers. 

Azure Event Grid allows you to capture events for specific data providers such as Azure Policy, Azure Storage, and many others. This is an amazing mechanism to automatically get events as Microsoft bundles them in an event grid system topic, instead of having to gather the data yourself.  What we wanted to achieve was to capture all Azure Policy events at a management group level as this allows us to get notified when certain resources become noncompliant to our Azure Policy Baseline. This is a lot more efficient as opposed to capturing events at subscription level, as you would need an event grid system topic for each subscription, which is not very scalable. 

To act on these events, we need to configure an Azure Event Grid Subscription, this subscription allows us to send the data to a Function App, webhook, Storage Queue etc. We then capture these non-compliance events, as to create the necessary tickets in our ITSM tool, allowing for easier follow up. 

While developing and testing this feature we were creating, we configured multiple tenants with an Event Grid System Topic and the corresponding event subscription in the tenants. The first two tenants we onboarded were my own development tenant and our internal testing environment. Both had their own unique Management Group as the scope, so nothing was out of the ordinary yet. 

However, when we onboarded our internal testing tenant, after the creation of the Azure Event Grid System Topic, a team member noticed that there was already an event subscription present. At first, we thought they had made an error in the automated deployment mechanism and included a deployment for an event subscription. After reviewing and discussing with other colleagues, we concluded that this was in fact not the case, and we proceeded to investigate further. 

This Security Vulnerability has now been patched, it is no long possible to reproduce this issue, this is purely to give a complete and clear overview

The following steps show how the flaw was reproduced:  

• • In both tenants create a new management group or use an existing one eg ‘mg-eventgrid-vuln’, ensure that the id field is identical. 
  • In both tenants register resource providers on management group level using az cli: 
  • az provider register –namespace Microsoft.PolicyInsights -m mg-eventgrid-vuln 
  • az provider register –namespace Microsoft.EventGrid  -m mg-eventgrid-vuln 
  • In tenant A, create an Event Grid System Topic with the ‘Microsoft PolicyInsights’ provider and as source the Management Group we created previous. Wait for the resource to be deployed. 
  • In tenant A, create an Event Grid Subscription using the System Topic created in the previous step. 
  • In tenant B, also create an Grid System Topic with the ‘Microsoft PolicyInsights’ provider and as source the Management Group ‘mg-eventgrid-vuln’, 
  • In tenant B, you will now see the Event Subscription you created in Tenant A. 

Our investigation allowed us to gain various insights into other tenants’ configurations and usage of Azure Event Grid Subscriptions. But what seems to be the issue that has caused this vulnerability? Let’s get to the bottom of it. 

As stated previously, everything boils down to creating an Event Grid System Topic and, this is important, with the ‘Microsoft PolicyInsights’ Topic Provider. The Microsoft PolicyInsights topic provider allows us to choose a scope: either an Azure Subscription or Management group. The PolicyInsights topic provider is the only topic provider which allows you to configure a management group scope as the subject. 

Once the resource has been created, the source property will look something like this for subscription scoped Event Grids System Topics: 

/subscriptions/<SubscriptionId> 

And for Management groups scope: 

“/tenants/<TenantId>/providers/Microsoft.Management/managementGroups/<ManagementGroupId>” 

Again, nothing special yet. However, as you might know, a subscriptionId is globally unique. This means that the same Id cannot be used across customers and tenants. This is not the case for a Management Group id. When creating a new management group, you have the freedom to choose whichever value you want, for example: 

This means that one tenant can have a management group with the id ‘mg-eventgrid-vuln’, but so can other tenants. This again, is in no shape or form, an issue by itself. After all, this allows e.g. Cloud Service Providers to streamline their deployments and operations across customers to ensure homogenous environments for all their clients. 

The issue/vulnerability stems from the filtering options that Microsoft used to present data to their customers. For subscriptions, it is totally fine to only filter on the subscriptionId value, as this value is globally unique. However, as shown and stated above, this is not the case for management groups. This fatal flaw allowed us to realistically get insights into event subscriptions for all Management Groups and tenants where the same Management Group names were used. 

The cause of this vulnerability is not something super advanced or groundbreaking; however, it goes to show that simple things such as this can cause a lot of potential impact or allow threat actors to gain valuable insights into customer environments. 

We were able to get some insights from our testing environments into what was exposed via this vulnerability. If we were to create a vulnerable event grid scoped to a Management Group with the tenant id of another tenant, we would be able to identify which tenants are capturing Azure Policy events based on the fact that an Event Subscription exists. 

The vulnerability essentially exposed all information from the specific Event Subscriptions in other tenants to all tenants which have an Event Grid System Topic created for the same Management Group Id. This allowed us to view: 

• • How many events were sent, errors… 
  • Which Azure Policy Events they were capturing 
  • Delivery settings in the event subscription 
  • Delivery Endpoints such as webhook URLs, function apps endpoints, and any other options 
  • Any settings configured related to cross-tenant delivery 
  • Linked Identities to the event subscription 
  • Microsoft Entra Id delivery options such as Application Id and Tenant Id 

This is all very valuable information allowing Threat actors to gain insights into the environments of unsuspecting clients.  

An event grid subscription allows you to configure delivery properties; these are headers which are sent to the endpoint which receives the Azure Policy Events. What we showed the MSRC team, is that it would be possible to add an authentication header to the delivery properties with the Azure Function Key: 

There is an option to set this as secret, but this can be easily forgotten. In such cause, it would allow a threat actor to retreive the secret and compromise the webhook endpoint for example. 

A huge deal of this vulnerability is that there is no telemetry which would have provided insights into defenders that it was being abused. All configuration is done on the home tenant as there is no actual configuration or access to exposed tenants. There is no way to know if someone was actually watching tenants and event grids configured.  

Additionally, we have no idea how long this vulnerability existed or whether it was potentially exploited for, which is a scary thought. 

DISCLAIMER: We did not actively exploit the topics mentioned below, these are just for showing what could have happened and how this vulnerability could have been exploited by threat actors if this was not patched. 

The actual impact of this vulnerability is hard to state. Technically, all tenants were impacted. At least if they had an Event Grid Subscription. In theory, we can create a script that iterates every possible management group Id, then creates an event grid and checks if there are event subscriptions configured (coming from other tenants). 

But it does not even have to be that hard, let’s just look at the Cloud Adoption Framework’s recommendation for Management Groups: 

If we were to start checking some variations of these Management Groups (using the proposed naming convention), we would surely find some Event Grid Topics in other tenants. Something else that can be tested, is creating management groups with an Id that has the value of the tenant Id of other customers. We suspect most people capture events at Root management group level as this allows for the broadest scope of Azure Policy Events. As stated above, it is perfectly possible to create a management group in tenant A with the id of Tenant B. 

The actual impact? Because there is no telemetry to show that a tenant was compromised, it is hard to say. Combined with the fact that for a tenant to be vulnerable, they would have required an Event Grid System Topic listening on a management group; we reckon that the impact/reach of this vulnerability was rather low. However, we cannot say for certain, but this could have potentially exposed a lot of information to the wrong people. 

We want to thank MSRC for their professional and swift response to this matter. We understand that not everyone may have had this experience in the past, but working with them has been both pleasant and smooth. Only a few days passed between us reporting the vulnerability, and MSRC/Microsoft acknowledging the impact and patching/fixing it.