In my personal experience as someone who has spent the last 6 years of his career in the security industry, almost nobody actually uses CVSS the way it is intended, they just almost arbitrarily tweak the CVSS inputs to produce an output they like.

You are correct that the attack complexity probably shouldn't be high in this case. But presumably the person calculating the CVSS score thought it was too high if attack complexity wasn't set to high.

CVSS has other issues, like people trying to apply it to things that are not vulnerabilities. I would ignore most CVSS scores you see and just read what the issue is instead and make your own judgement call.

To be fair, doing even the most basic task in Entra as an authenticated user is also "high complexity", so the difficulty of attacking it can only go up from there.

"1.1 18 Sep 2025 The CVSS score for this vulnerability has been updated to reflect a change in the Attack Complexity metric from High to Low."

https://msrc.microsoft.com/update-guide/vulnerability/CVE-20...

"really all you need is basic admin knowledge of Entra ID"

> Yes, because any "basic user of Entra ID with basic knowledge of it" has found undocumented types of tokens, and stringed them with another Graph API vulnerability, to impersonate users...

Basic Entra ID users don't even know what an Entra ID token is exactly.

lol. So much coffee found the way through my nose... :D

It's even worse: "Because of the nature of these Actor tokens, they are not subject to security policies like Conditional Access". This goes against all principles of good security design. A token that gives root access instead of specifying a particular action allowed just invites misuse, erroneous or malicious.

I would expect these tokens to be like JWT or macaroons, carrying specific permissions within specific bounds / tenants. Alas.

It's the standard naming for the services. Multi-tenancy is a thing, but landlords are not in this naming context.

Microsoft also forced to keep these legacy code tbh

You see, most enterprise client with big enough contract can force to do this and MS need to support this customer until they migrate or if they ever be at all

I may argue for any big legacy enterprise software, its easier to rewrite the damn whole thing than to support the legacy code forever but they cant do that even if they have motivation/resource

My NSL detector is off the charts here.

> impersonation tokens, called “Actor tokens”, that Microsoft uses in their backend for service-to-service (S2S)

Literally every single "security" framework uses God-mode long-lived tokens for non-human identities.

(Except for SPIFFE, but that's a niche thing and used only for Kubernetes bullshit.)

The whole field of "security" is a farce staffed by clowns.

One of the bigger issues is the double-hop problem. It's both an important security boundary, and one of the biggest butt-pains about the protocol.

https://techcommunity.microsoft.com/blog/askds/understanding...

It works great within a single organization hierarchy, but becomes pretty painful for anything we'd consider "SaaS"

Kerberos doesn't have a good monthly recurring revenue "story".

Kerberos doesn't work well on the web.

> Just creating a tenant is a PITA and you get a default tenant you can't change without paying for Microsoft 365?

What exactly ist a PITA when creating a tenant? It's straightforward.

And what do you mean by default tenant that you cannot change unless you pay? Nothing comes to mind where that would be the case.

Are you sure you're not just using it wrong?

There ist a whole industry clustered around this FUBAR that makes its living by helping companies navigate this shit. It has small and big players and they have no incentive to tell you that there is anything else you could use. The monthly Service fee is too tasty.

It takes like two minutes to create a tenant. Click Next a bunch, enter a credit card, you're done.

And yes they have different types of accounts and methods of billing. Their customer base is probably in the hundreds of millions. People are going to want options. I don't really see the issue there.

You could get into Microsoft's tenant with any Entra account.

That's because Microsoft's own fucking developers don't even understand how Entra authentication/authorization works, and that in some/most scenarios you'll need to check if a account is actually authorized to enter a protected resource post-login (which you need to do within the Oauth login flow in the resource being accessed, nobody will do it for you).

Something I already discovered by accident (and fixed, ofcourse!) in my own SaaS service at the time (with support for Entra B2B authentication) even before this researcher discovered the same at Microsoft:

https://research.eye.security/consent-and-compromise/

HN discussion thread: https://news.ycombinator.com/item?id=44850681