If your organization runs Microsoft Entra ID, any authenticated user in your tenant could obtain sign-in telemetry for the entire enterprise without holding a single role, group membership, or admin right. That telemetry includes user principal names, source IP addresses, geolocation, MFA status, application access patterns, and the Conditional Access policies applied to every sign-in, and the same broken API authorization flow affected 15 separate Entra services.

Unauthorized access to that data triggers breach notification obligations under most data protection regulations.

That bug existed in production until late April 2026. Microsoft has now fixed it. They have not told you about it or issued a CVE. They have not acknowledged the finding, and they have not given you the disclosure you would need to determine whether anyone in your tenant exploited the flaw before the fix quietly shipped.

“If Microsoft is short on bounty money, they can keep it. What they cannot do is close a critical finding as not a bug, ship the patch on the side, and leave every Entra tenant in the dark about a flaw that exposed all of their authentication telemetry to any low-privileged user in their environment.”

I reported the vulnerability to the Microsoft Security Response Center on April 8, 2026, as case VULN-181669. MSRC closed it on April 27 as "below the bar for immediate servicing," telling me the “API enforces permissions server side and returns 403 Forbidden”. Two days later I retested. The endpoint that previously returned 200 with a full data dump now returns Authentication_RequestFromUnsupportedUserRole. The fix that didn't exist on April 8 exists on April 29.

If Microsoft is short on bounty money, they can keep it. What they cannot do is close a critical finding, ship the patch on the side, and leave every Entra tenant in the dark about a flaw that exposed all of their authentication telemetry to any low-privileged user in their environment. They should notify all customers who were exposed, provide indicators of compromise, issue the CVE, and credit the research.

The Finding

The Entra admin portal sign-in logs page correctly returns HTTP 401 when accessed by an account without audit log read permissions. The portal rendering pipeline, however, loads the download UI before the server-side authorization response is processed and the access denied page is rendered. (This functionality still exists and has not been updated.) You can still see evidence of the UI render issue, simply login to Entra as a low-privileged user, use DevTools to throttle your traffic, and navigate to “Monitor and Health” -> “Sign-In Logs”. If you are not an authorized user, you will see the same rendering that I saw. You can even leverage this to click the Download button. However, with the API authorization silent patch, you should not be able to download the logs, but prior to the patch that is exactly what I was able to do.

During that render window, a single browser refresh and a click on the Download button dispatched a request to the underlying Graph Beta API. The Graph Beta endpoint did not enforce the same authorization check the portal did. It assumed that only authorized users could reach the download control through the UI. That assumption led to unenforced authorization for the Graph Beta API.

Identifying this required tracing how the Entra portal hands off authorization to the Graph Beta API across 15 separate surfaces, recognizing that the UI-layer access control was not backed by server-side enforcement, and confirming the pattern held wherever the same render-then-authorize pipeline appeared. Exploiting it, once identified, took a browser refresh and a click on the Download button.

The barrier to discovery sits at the level of expert API security research and the barrier to exploitation sits at the level of any low-privileged authenticated user with a mouse and keyboard.

The Scope

The same broken API authorization pattern affected 15 Entra services. I tested every Entra service I could enumerate.

Category	Services
Identity & Access	Sign-in logs (Interactive, Non-interactive, Service Principal, Managed Identity), Provisioning Logs, App registrations, Conditional Access, Authentication methods, Certificate Authorities, ID Protection
Tenant & Governance	Delegated Admin Partners, Tenant governance (preview), Domain Services, Lifecycle Workflows, Identity Secure Score
Monitoring	Health, Billing - Licenses - Audit Logs
Preview surfaces	Entra ID: Agent ID sign-in logs (preview)

A single export across the four sign-in log categories alone exposed:

User principal names for every active tenant account
Source IP addresses and geographic locations
Azure Object IDs and Tenant ID
MFA status and authentication method per sign-in
Application IDs and display names
Service principal identities and resource targets
Managed identity assignments
Device IDs
Conditional Access policy evaluation results
Legacy authentication protocol usage
Session correlation IDs

This is a goldmine to any adversary. With it, any insider could identify privileged accounts, map the application landscape, and time a credential stuffing run against accounts without MFA. I've seen organizations announce data leaks and breaches for much less.

It is not a tenant misconfiguration. It was a platform-level flaw in Microsoft Entra ID that affected every organization using the service.

The Timeline

Date	Events
Apr 8, 2026	Initial report submitted to MSRC. VULN-181669 assigned
Apr 8, 2026	Follow-up report identifying the same pattern in 11 additional Entra services.
Apr 8, 2026	Second follow-up identifying 3 more affected services. Total: 15.
Apr 9, 2026	MSRC opens Case 112752. Researcher portal communication only. Confidentiality requested.
Apr 23, 2026	MSRC unable to reproduce. Requests video proof of concept.
Apr 24, 2026	Confirmed video proof was already attached to the original submission.
Apr 27, 2026	Case closed. "API checks permissions server side and calls return with a 403 Forbidden response." Below the bar for immediate servicing. No bounty. No CVE.
Apr 29, 2026	Retest. The Graph Beta endpoint now returns Authentication_RequestFromUnsupportedUserRole. The role check that did not exist on April 8 now exists.

Same Endpoint, New Response

Here is the response from the same endpoint on April 29, 2026, after the case was closed:

Request URL:

https://graph.microsoft.com/beta/auditLogs/signIns?$filter=...&$top=150&$orderby=createdDateTime desc&source=kds

Request Method: GET

Response:

{

"error": {

"code": "Authentication_RequestFromUnsupportedUserRole",

"message": "User is not in the allowed roles",

"innerError": {

"date": "2026-04-29T16:26:07",

"request-id": "06978887-222d-42ef-9caf-51b04c48ada0"

}

This response did not exist when the disclosure was filed. The video evidence on file with MSRC shows the endpoint returning 200 with a full sign-in log dump from an account with no roles. That same request now returns a role check error.

The Question Microsoft Won't Help You Answer

Does your organization retain the logs needed to determine whether anyone in your tenant exploited this before the fix shipped?

The Graph Beta API calls used in this attack would appear in your sign-in logs as successful 200 responses to auditLogs/signIns and related Graph Beta endpoints, originating from users who should not have had read access to that data. I disclosed the flaw to Microsoft on April 8, 2026. Microsoft has not disclosed how long it existed before that. Entra users who want to investigate should assume the exposure window extends backward through their full retention period of Graph API and sign-in log telemetry.

Microsoft could have helped you look for indicators of compromise, but they chose not to.

This is the operational problem with a silent patch. Your incident response plan depends on knowing what to investigate. A vendor that ships a fix without a disclosure or a disclosed exposure window is a vendor that has decided you don't need to know how long you were exposed.

What MSRC Got Wrong

Here is the full response from MSRC on April 27 (Typos are Microsoft’s):

After careful investigation, this case does not meet Microsoft's bar for immediate servicing. We have verfiied that our API checks permissions server side and calls return with a 403 Forbidden response. MSRC prioritizes vulnerabilities that are assessed as an Important or Critical severity. Since this case was below the bar for immediate servicing, it is not eligible for bounty, and no CVE will be issued. MSRC will not be tracking this issue further, and no additional updates will be provided.

When I checked two days later, the API in question began the new role-check response.

They asked for video, then closed on different grounds. On April 23, MSRC said they could not reproduce the issue and requested video proof of concept. The video was already attached to the original submission. After I confirmed this on April 24, the April 27 close did not return to the reproducibility question. It pivoted to a different dismissal: that the API enforces permissions server side and returns 403 Forbidden. MSRC asked for video, got it, and closed the case on grounds that had nothing to do with reproducibility.

“They patched it silently. Closing a finding as not a bug and then shipping the fix for it is the opposite of coordinated disclosure. No CVE. No advisory. No customer notification. ”

They closed it claiming server-side enforcement was working. The retest evidence contradicts this directly. The current Authentication_RequestFromUnsupportedUserRole response is the role check that the original endpoint did not have. Microsoft's own dismissal language describes the fix they shipped, not the state of the API at the time of disclosure.

They patched it silently. Closing a finding as not a bug and then shipping the fix for it is the opposite of coordinated disclosure. No CVE. No advisory. No customer notification.

Why This Matters to Your Organization

Silent patching pushes the cost of the vendor's mistake onto every customer. The vulnerability gets fixed in production, but the disclosure that would let your IR team investigate, your detection engineers write the rule, and your auditors document the exposure stays inside Microsoft. Microsoft got a clean public record but left their Entra customers exposed.

What Should Happen

Microsoft should notify affected customers. Every Entra tenant administrator should receive guidance on what API calls to look for in their logs and what indicators of compromise are consistent with exploitation. The patch is in, but the disclosure is missing.

MSRC should reopen VULN-181669, notify customers, and issue a CVE. Acknowledgment of the research is the smallest part of that and the easiest to deliver.

If you are a Microsoft customer, the platform-level fix is in. The flaw that exposed your sign-in logs (and 14 other Entra services) to every authenticated user in your tenant has been patched. Unfortunately, up to this point, you will not see this in any Microsoft advisory. You are seeing it here.

If you are MSRC and you are reading this, the case number is VULN-181669. The video can be found here. The before-and-after evidence is documented. The right move is the obvious one.

Corey Ball is the Head of Offensive Security for APIsec.ai, founder of hAPI Labs, and the author of Hacking APIs. The full disclosure timeline, video evidence, and Burp Suite request history for VULN-181669 are available.

Microsoft Silently Patched a Critical Entra Bug and Won't Tell You If You Were Breached.