If anyone from Microsoft security reads this, could you please do something about login.microsoftonline.com/XXX/v2.0/adminconsent?
The callback you're redirecting the user to at the end of that flow is forgeable if an attacker knows an azure tenant ID of a different customer, and putting a "Never use the tenant ID value of the tenant parameter to authenticate or authorize users" warning in the docs is only helpful as long as a way to authenticate users exists.
They'll see it, tell a manager, it'll get added as a ticket to an Azure Devops board under the initiative for this month under the epic for employee suggestions, which will be reviewed & prioritised by Copilot and sent to a different middle manager as a weekly summary email and then automatically closed when no human ever interacts with the ticket after three months.
I'm sure one of the 60,000 employees who have been told they're welcome not to work there anymore, because the line must go up infinitely, will be chomping at the bit to do so.
That's me. But I don't understand your comment. Could you expand on it, either in a reply or preferably by email or via an MSRC case? You can reply with the vuln number so I can fast route it.
> The callback you're redirecting the user to at the end of that flow is forgeable
The redirect_uri is checked against the app registration. There's a general OAuth problem called "open registration redirects" that applies here, about which we've [blogged](https://www.microsoft.com/en-us/security/blog/2026/03/02/oau...) - but frankly, none of the industry solves this well.
In general, "I can create a link that goes to malware via X endpoint" isn't very interesting - you can also just create a direct link to the malware. Web browsers won't reliably show you the real destination of a link anyhow and even if they did, it's mostly just us hackers who understand URLs at all.
> as long as a way to authenticate users exists.
I'm lost. Entra supports [OpenID Connect](https://learn.microsoft.com/en-us/entra/identity-platform/v2...) for authentication. Most portals that surface admin consent authenticate the user with an OpenID Connect request either immediately before or after the admin consent request.
Reaching an actual human at Microsoft isn't enough. You have to reach the correct humans which is a much harder task. For example, you might have an idea. What if azure devops had a field for date component only, not date time, just the date because it would help you in an internal project. Can you find out who to reach? Even if you work at Microsoft, I would bet you cannot. Even when you find a defect in an internal product you are using, getting to a human requires you to go through layers of nonsense. I distinctly remember my manager telling me to not even bother explaining myself to the first support chat and to simply ask them to escalate. I was impressed at how they managed to make security a part of your review though. I never thought getting buy-in to update Newtonsoft.Json would be as easy as it was but a CVE meant you had to update it to whatever made the security flags happy.
Once I could reach the actual engineering team to look at the internal tool to look at the bug I had to report though, they were very responsive. The tool for communicating was cumbersome and made me feel like a vendor / customer relationship even though you are supposed to be the same team but once they realized it was an actual defect and not some harebrained feature request, they fixed it relatively quickly.
Anyone that's had to deal with Microsoft will tell you this means nothing
If you can even get attention from someone, you'll be bounced between teams and people who barely know the products they are "supporting"
Don't get me started on the Azure and O365 management portals
The only worse support experience I've had was with Oracle where it could take days just to get the boilerplate "send us your logs" response on a Sev1 issue, despite the logs already being provided in the initial ticket
In both cases, this is while at F100 companies with millions of dollars of licensed software and premium support contracts
For us a big part is that they have data centers in our country. It makes for improved latency and also makes a lot of our customers sleep better (justifiably so or not).
Amazon doesn't and regardless nobody feels comfortable using Google, who knows when they'll discontinue a product we would rely on.
I do .NET full time, every shop I've worked at was on Azure. It makes the most sense for .NET developers, but I'd personally prefer to just rent dedicated servers at this point.
Their sales folks are very good with C level folks, from the meetings I've sat in on. They will give you substantial credits and hands on support to build for you, depending on vertical and predicted future spend, especially if you're already at another cloud provider they're trying to pull you from.
Really not surprising given the history of sloppy coding, elementary authentication mistakes, outsourced "support", and anecdotal reports of horrid internal culture over the past few years
God. I would hate to be the engineer forced to have enough Azure experience to be able to find these bugs and understand Azure’s infrastructure on this level.
Should have been addressed in the Geneva conventions.
Let’s see how their platform design holds up in the coming years, and if it can hold up to LLMs doing more of this same type of discovery and whether MSFT can fix it.
> Reporting “theoretical” issues with validation as an Employee
Microsoft still has employees ? ;)
(Sorry. Low bar. But in all honesty I thought they outsourced the majority of ops. I was surprised to hear in recent news that they actually had that many employees left)
If anyone from Microsoft security reads this, could you please do something about login.microsoftonline.com/XXX/v2.0/adminconsent?
The callback you're redirecting the user to at the end of that flow is forgeable if an attacker knows an azure tenant ID of a different customer, and putting a "Never use the tenant ID value of the tenant parameter to authenticate or authorize users" warning in the docs is only helpful as long as a way to authenticate users exists.
They'll see it, tell a manager, it'll get added as a ticket to an Azure Devops board under the initiative for this month under the epic for employee suggestions, which will be reviewed & prioritised by Copilot and sent to a different middle manager as a weekly summary email and then automatically closed when no human ever interacts with the ticket after three months.
speaking as a FTE at Microsoft... yup
6 replies →
I'm sure one of the 60,000 employees who have been told they're welcome not to work there anymore, because the line must go up infinitely, will be chomping at the bit to do so.
That's me. But I don't understand your comment. Could you expand on it, either in a reply or preferably by email or via an MSRC case? You can reply with the vuln number so I can fast route it.
> The callback you're redirecting the user to at the end of that flow is forgeable
The redirect_uri is checked against the app registration. There's a general OAuth problem called "open registration redirects" that applies here, about which we've [blogged](https://www.microsoft.com/en-us/security/blog/2026/03/02/oau...) - but frankly, none of the industry solves this well.
In general, "I can create a link that goes to malware via X endpoint" isn't very interesting - you can also just create a direct link to the malware. Web browsers won't reliably show you the real destination of a link anyhow and even if they did, it's mostly just us hackers who understand URLs at all.
> as long as a way to authenticate users exists.
I'm lost. Entra supports [OpenID Connect](https://learn.microsoft.com/en-us/entra/identity-platform/v2...) for authentication. Most portals that surface admin consent authenticate the user with an OpenID Connect request either immediately before or after the admin consent request.
I love that this is the most reliable way to actually contact an actual human working at Microsoft
Reaching an actual human at Microsoft isn't enough. You have to reach the correct humans which is a much harder task. For example, you might have an idea. What if azure devops had a field for date component only, not date time, just the date because it would help you in an internal project. Can you find out who to reach? Even if you work at Microsoft, I would bet you cannot. Even when you find a defect in an internal product you are using, getting to a human requires you to go through layers of nonsense. I distinctly remember my manager telling me to not even bother explaining myself to the first support chat and to simply ask them to escalate. I was impressed at how they managed to make security a part of your review though. I never thought getting buy-in to update Newtonsoft.Json would be as easy as it was but a CVE meant you had to update it to whatever made the security flags happy.
Once I could reach the actual engineering team to look at the internal tool to look at the bug I had to report though, they were very responsive. The tool for communicating was cumbersome and made me feel like a vendor / customer relationship even though you are supposed to be the same team but once they realized it was an actual defect and not some harebrained feature request, they fixed it relatively quickly.
When it comes to the amount of cross-tenant leaks Azure looks to be way ahead the competition. Makes me wonder why enterprises still flock there.
> Makes me wonder why enterprises still flock there
Well, when you're already paying Microsoft $/user/month for Intune, Teams&co. you might as well use Azure too.
Only one vendor relationship to manage, and I suspect you probably have to spend far less money than you do with AWS to get some personal attention.
> one vendor relationship to manage
Anyone that's had to deal with Microsoft will tell you this means nothing
If you can even get attention from someone, you'll be bounced between teams and people who barely know the products they are "supporting"
Don't get me started on the Azure and O365 management portals
The only worse support experience I've had was with Oracle where it could take days just to get the boilerplate "send us your logs" response on a Sev1 issue, despite the logs already being provided in the initial ticket
In both cases, this is while at F100 companies with millions of dollars of licensed software and premium support contracts
8 replies →
Must be convenient to get all your security bugs from one vendor...
Same reason as it was in 2002. “No one ever got fired for buying Microsoft.”
Lets get our Cloud...from the same guys who have been unable to provide a freeze screen feature in Teams for 10 years..should be a firing offense...
4 replies →
In 2026, it's also: "They have FedRAMP, and some "cyber" person told me we need GCC-High to pass an audit."
1 reply →
It pretty much applies to everything, going along the tide is always easier
Good time to start.
For us a big part is that they have data centers in our country. It makes for improved latency and also makes a lot of our customers sleep better (justifiably so or not).
Amazon doesn't and regardless nobody feels comfortable using Google, who knows when they'll discontinue a product we would rely on.
So not a lot left to choose from.
I do .NET full time, every shop I've worked at was on Azure. It makes the most sense for .NET developers, but I'd personally prefer to just rent dedicated servers at this point.
Their sales folks are very good with C level folks, from the meetings I've sat in on. They will give you substantial credits and hands on support to build for you, depending on vertical and predicted future spend, especially if you're already at another cloud provider they're trying to pull you from.
AI Agents are salivating at that level of incompetence....
1 reply →
Well they're clearly market leaders being that far ahead of the competition. Maybe that's why.
/s
Feels. AKA stupidity, ultimately.
maybe we should tag submissions with dates now?
[2026-10-02]
beginning of curent month feels like two years ago when multiple vulns drop daily
[06:00]
"… then put your little hand in mine…"
https://www.youtube.com/watch?v=XD2ZC11pPPQ
This guy must be the nightmare of Azure developers, kudos for the incredible work on finding these vulnerabilities!
We contract this company at work. They’re clearly capable.
Can confirm that we’re getting our money's worth. :D
Meanwhile they want to fire even more people there.
path traversal and IDOR..
likely been active since the inception of these capabilities
wonder if the recommendation to "add randomness to resource names" is because of this (unrelated security by obscurity lol)
Gotta put these backdoors somewhere.
Ok so.
Microsoft had an egregious cross-tenant vulnerability (really, how many cross-tenant vulnerabilities did other clouds have?).
Vulnerability was reported.
They fixed it - incorrectly. Reported again.
They fixed it this time... and broke the previous fix. So it's vulnerable again.
What a clown show.
Really not surprising given the history of sloppy coding, elementary authentication mistakes, outsourced "support", and anecdotal reports of horrid internal culture over the past few years
[2026] Erosion of Trust @ Azure
https://www.darkreading.com/cloud-security/microsoft-azure-c...
And this is just the Azure / O365 stuff - there's been thousands of Windows client/server and Office software exploits across the same time period
They keep forgetting to put "make no mistakes" in the copilot prompt!
God. I would hate to be the engineer forced to have enough Azure experience to be able to find these bugs and understand Azure’s infrastructure on this level.
Should have been addressed in the Geneva conventions.
The outsourcing of coding to LLMs is, in this case, a humanitarian measure.
“Go to the cloud!”, they said.
The cloud:
Let’s see how their platform design holds up in the coming years, and if it can hold up to LLMs doing more of this same type of discovery and whether MSFT can fix it.
Reporting cross-Tenant issues as an outsider with a vulnerability chain gets you $$$.
Reporting “theoretical” issues with validation as an Employee gets you a lot of questions as to why you were looking.
Oh well.
So MSFT discourages employees from reporting vulnerabilities?
That explains a lot.
> Reporting “theoretical” issues with validation as an Employee
Microsoft still has employees ? ;)
(Sorry. Low bar. But in all honesty I thought they outsourced the majority of ops. I was surprised to hear in recent news that they actually had that many employees left)
[flagged]
[flagged]
[flagged]
[flagged]
[flagged]