In Azure, most serious incidents do not start by “breaking” a firewall: they start by issuing or accepting a token that should not exist. That is why, when risk is concentrated in the Enterprise Security Token Service (ESTS)—the component responsible for issuing/validating tokens for Microsoft Entra ID (Azure AD)—the potential impact is disproportionate: any workload that trusts those tokens inherits the problem.
The CVE-2026-40379 vulnerability focuses precisely there: attacks that seek to impersonate identities (spoofing) at the token provider level. It is not “just another bug”; it is a reminder that, if the issuer or the issuance flow is altered or deceived, your company’s real perimeter becomes token validation in each service that consumes identity.
What went wrong: why spoofing in ESTS changes the trust model
In a typical corporate environment, many systems assume that “if the token is from Entra ID, it is valid.” That premise often translates into minimal validations in internal APIs, proxies, legacy apps migrated to OIDC/SAML, and automations that only check that the token “looks” correct. The problem with an ESTS spoofing scenario is that the attacker tries to attack the exact point where that trust originates: the service that issues or enables obtaining tokens.
With CVE-2026-40379, the operational concern is not only the flaw itself, but the pattern: if an attacker manages to make the ecosystem accept a token with a spoofed identity, the jump to high-impact actions is immediate: access to corporate applications, invocation of APIs with elevated permissions, or lateral movement using service identities. In companies with strong integration with Microsoft 365, the surface expands because identity is reused across the board.
The real consequence in a company usually looks like this: “valid” accesses (per token) appear to applications that nobody considers exposed, because in reality they trust the same issuer. The incident becomes confusing: there are no obvious stolen credentials, no failed MFA, no suspicious interactive login. There is “correct” authorization on an identity that, simply, should not have been able to authenticate that way.
How identity spoofing is attempted: mechanics of abuse at the token provider level
Spoofing attacks in this context seek to obtain a token with claims that represent another identity (user, service principal, workload) or force a flow where the validation/relationship between identity and token becomes weakened. In practical terms, the attacker does not need to “live” inside your tenant from minute one; it is enough to get a component that trusts ESTS to accept a token that represents someone with more privileges.
In real environments, attempts usually combine two elements: first, finding a consumption point (API, app, gateway) that validates loosely; second, forcing a token that passes those controls. Where this is seen most is in integrations done in a hurry: internal APIs behind an Application Gateway or a proxy that only check the “issuer” or the “audience” incompletely, or services that accept tokens from different clients/tenants without strict pinning.
There is a recurring trap in corporations with multiple teams: when the same validation library or a common middleware is reused without hardening it per application, any weakness replicates in a chain. A problem at the issuance/acceptance point becomes an impact multiplier, because the organization standardizes its dependence on tokens.
Early signals and artifacts: what is usually seen before it blows up
When abuse relies on “apparently valid” tokens, the initial symptoms are usually subtle: access from unusual locations or agents, calls to APIs with unusual patterns, or sessions that appear without a coherent trace of interactive authentication. In companies with a good level of observability, the first thing that “stands out” is the inconsistency between identity, application, and context, not an authentication error.
To guide the hunt, it helps to think in terms of “impossibles”: an app that receives tokens with a correct audience but from clients that had never used that app; an identity that consumes resources at times or volumes that do not fit; or a principal that starts requesting permissions or scopes that were not part of normal behavior. The value lies in correlating signals across Entra ID, app logs, and gateway/API management.
- Inconsistencies between the expected and observed flow
Realistic example: your API says it is consumed only by a corporate frontend, but direct traffic appears with valid OIDC tokens from scripts. If the token passes, the failure is usually in validation (or in excessive trust in the issuer) and not in the client app.
- Correct authorizations with “strange” identities for that resource
In large companies, certain service principals are used for specific tasks. If a principal intended for CI/CD starts calling a finance API, even if the token is valid, the event is anomalous and is usually high value for detection.
- Privilege jumps without visible prior administrative changes
When privileged activity is seen without a clear trace of role changes, consents, or elevations, it is worth suspecting a problem in the token plane: the system “believes” the identity, even if the path to obtain it is not consistent with internal control.
How to do it in practice: containment and validations that reduce impact
If you are managing the risk of CVE-2026-40379, the operational priority is twofold: reduce probability (applying vendor mitigations/patch paths when they exist) and, above all, reduce the blast radius assuming that some token could be suspicious. In corporations, this translates into hardening validation and narrowing trust per application.
Concrete actions that are usually feasible without breaking production if well planned: strict pinning of issuer and tenant, full validation of audience and expected algorithm/keys, and reducing the tokens accepted by each API to the minimum necessary. It is common to discover that an API accepts tokens intended for another, or from multiple tenants “for historical compatibility.” That is exactly what must be removed.
- Harden JWT validation in each API (not only at the gateway)
In practice: configure the library/middleware to validate iss, aud, signature, expiration, and to reject tokens with unexpected claims. If you rely only on a WAF/gateway, any internal bypass or direct route can bypass the control.
- Validate that the issuer and tenant are the expected ones (pinning)
This prevents accepting tokens issued for other contexts. In organizations with multiple tenants or B2B, explicitly define which tenants are allowed per application, and review integrations that “accept any Microsoft token” for convenience.
- Review trust configurations and consents
Operationally: audit registered applications, granted permissions, and admin consents. Even if the vector is spoofing, an attacker usually combines it with excessive permissions so that the “fake” token is actually useful.
Validation that it is working: when you apply these hardenings, explicitly test with tokens from other environments/tenants (in a lab) and confirm that the API rejects them. In production, monitor the rejection ratio due to validation and correlate it with specific endpoints: a localized spike usually indicates a consumer that depended on insecure behavior.
Recommendations for corporate environments
The risk introduced by an Azure ESTS spoofing scenario, such as the one associated with CVE-2026-40379, is not managed only by “waiting for the patch”: it is managed by reducing blind dependence on the issuer and strengthening how each application accepts and validates tokens. In companies, this makes the difference between a contained incident and one that crosses dozens of systems with the same spoofed identity.
Real operations involve inventorying token consumers, hardening validations (issuer/tenant/audience/signature), and improving detection by looking for context inconsistencies rather than login failures. If your organization has common proxies or middlewares, prioritize there, but do not replace controls in the app with controls “at the entrance”: what the final service does not validate ends up being security debt that is paid at the worst time.
Interested in Cloud Security?
Technical analysis, hands-on labs and real-world cloud security insights.