The Entra ID flaw and the OAuth campaigns are one finding

A maximum-severity Entra ID flaw and a wave of Russian OAuth phishing surfaced in the same week, and together they show why identity should be treated as infrastructure, not a checkbox control.

4 Min Read

Two stories broke on the same day at the end of last week, and together they describe one problem. Identity has stopped behaving like a control category and started behaving like infrastructure. A maximum-severity flaw in Microsoft’s identity platform and a wave of state-linked OAuth phishing sound unrelated. They aren’t.

What Microsoft disclosed about Entra ID

Microsoft disclosed CVE-2026-69836 in August 2026, a remote-code execution flaw in Entra ID, the identity and access management platform that used to be called Azure Active Directory, with a severity score of 10.0 out of 10, the maximum possible. Microsoft’s security bulletin says its own researchers found the flaw. Most maximum-severity findings in identity infrastructure surface through an external researcher or an incident already underway, not through the vendor’s internal team.

Microsoft says the flaw is fully mitigated and that no customer action is required. As Cybersecurity Dive reported, the bulletin briefly described the vulnerability as under active exploitation before Microsoft revised that language to say it wasn’t. Exploited or not, the flaw sits in the identity plane underneath most enterprise logins, not in one client’s line-of-business app. It’s the plumbing everybody shares.

What Google is tracking in the OAuth campaigns

The second story is a threat intelligence report Google’s Threat Intelligence Group published in August 2026, tracking several suspected Russian intelligence-linked groups running phishing campaigns against people in academia, aerospace, defense, government, and think tanks across the US and Europe. Google links part of the activity, with varying confidence, to APT29 and Russia’s foreign intelligence service.

The campaigns are small. Google told The Register that each one had fewer than 100 targets and under 10 victims, aimed at people who already know not to click a suspicious link.

What changed is the mechanism, not the target list. One tactic asks a target to complete a real login with a legitimate provider, then hand over the verification code that comes back afterward, and at that point the attacker has a valid, authenticated session without ever touching a password. Another tactic uses domains built to look like file-sharing sites, routes visitors through an actual Google OAuth consent screen, and captures the resulting token. The login is real, and the Multi-Factor Authentication (MFA) prompt clears like it’s supposed to, because nothing about the exchange is technically wrong. The person granted access. They just didn’t know what they were granting it to.

Why a patch note and a phishing report are the same finding

A flaw in shared identity infrastructure and a technique that defeats password-based authentication live in the same layer, and they fail the same way, all at once, rather than one client at a time. That’s the literal half of it. The other half is what the OAuth campaigns say about a control most of the industry treats as settled. A checkbox that says “MFA: yes” has functioned as the end of a risk conversation instead of the start of one. A control built on the assumption that an attacker needs a password doesn’t do much against a technique built specifically to avoid needing one. That doesn’t make MFA worthless. It still stops a large share of what shows up in a typical incident. But it does mean the checkbox answer is a thinner signal than it used to be, since a rollout that resists consent-phishing looks identical, on paper, to one that doesn’t.

Two disclosures broke on the same day, one out of Redmond and one out of Mountain View, describing the same exposure from two directions. The practical shift is in how much weight an MFA checkbox can carry on its own. Phishing-resistant methods, FIDO2 security keys or passkeys, don’t have a verification code or a consent screen for an attacker to intercept. That’s the gap the OAuth campaigns are built to exploit, and it’s the one worth closing first.

Common questions

What is Entra ID, and why does a flaw in it matter beyond one company? 

Entra ID is Microsoft’s identity and access management platform, the renamed successor to Azure Active Directory, and it functions as the login layer behind a large share of commercial environments. A flaw there is a shared infrastructure risk, not a single-company problem.

Was the Entra ID vulnerability exploited? 

Microsoft’s bulletin briefly said yes, then was revised to say no, without an explanation for the change. Microsoft hasn’t published an exploitation timeline or details on customer impact.

What is OAuth abuse, and how does it differ from ordinary phishing? 

Instead of stealing a password, the attacker gets a target to complete a real, legitimate login and then hand over the resulting access token or verification code. The authentication event looks normal because it is normal. Only the destination of the access is malicious.

Does multi-factor authentication still reduce risk if OAuth phishing exists? 

Yes, in most cases. MFA still blocks straightforward password-based attacks. It does less against OAuth consent phishing, because that technique is built to route around the password step rather than defeat it.

How many organizations were affected by the Russian-linked OAuth campaigns Google identified? 

Google told The Register that each campaign had fewer than 100 targets and fewer than 10 victims. The campaigns are narrow and targeted, aimed at people in academia, aerospace, defense, government, and think tanks rather than broad populations.

Nothing here should be taken as legal, financial, or security advice for your specific situation — see the full disclaimer at cyberresilience.com/disclaimer.