Entra CVSS 10.0: Audit Your Tenant After CVE-2026-69836

4 min read cybersecurity, Development

Microsoft assigned CVE-2026-69836 a 10.0. The class is CWE-502. Entra deserialized untrusted data, and an unauthorized caller could execute code over the network. The service is hosted, so there is no package to upgrade on your side. Microsoft says the fix shipped before the CVE went public. After a correction, they report no evidence of exploitation. That is their telemetry. Your tenant still needs an audit.

A 10.0 on the identity plane can mint tokens, attach credentials to service principals, and grant Graph permissions. Most tenants will skip the work because the advisory says they can. That is how a control-plane bug becomes persistence two months later. If you run Entra, treat the disclosure week as an audit window.

Deserialization of untrusted data in Microsoft Entra allows an unauthorized attacker to execute code over the network.

Pull directory audit events into a file you control. The portal is a view, not an archive.

az rest --method GET --url "https://graph.microsoft.com/v1.0/auditLogs/directoryAudits?$top=50" --output json

Checklist

  • Read the MSRC page, then the correction: the first public writeups repeated an exploited flag of Yes. Microsoft later set that field to No and said they found no evidence of use. Both versions circulated. Archive the advisory, the CVE record, and the date of the correction. If your IR playbook keys off CISA KEV or an exploited flag, record which flag you acted on and when it changed.
  • Export directory audit logs for August: pull directoryAudits and sign-in logs covering at least two weeks before the CVE date. Look for credential adds on service principals, new app registrations, admin consent, role assignments, and federation changes. Save the export. If you only scroll the Entra portal, you will not have a record when the UI pages away.
  • List service principal credentials: an identity-plane process can add a password or certificate to an existing app and walk away. Dump every service principal, its keyCredentials and passwordCredentials, and who created them. Anything issued in the disclosure window with no matching change ticket is a revoke candidate. Do this before you rotate, so you know what you destroyed.
  • Review admin consent and Graph grants: application permissions on Microsoft Graph survive password resets. List oauth2PermissionGrants and appRoleAssignments. Watch Mail.Read, Directory.ReadWrite.All, RoleManagement.ReadWrite.Directory, and Application.ReadWrite.All. A grant that appeared without a documented admin consent event is the incident. The CVE number is only the reason you looked.
  • Check privileged role activations: Global Administrator, Privileged Role Administrator, Application Administrator, and Cloud Application Administrator can finish what an RCE starts. If you use PIM, export activations for the same window. If you do not use PIM, that is a finding: standing admin roles are how a short cloud compromise becomes a tenant you no longer own.
  • Diff federation and domain settings: look for new identity providers, changed issuer URIs, added domains, and altered federation metadata. These objects are small and rarely touched, which makes a surprise write easy to spot. Compare against a known-good export if you have one. If you do not, start taking them now.
  • Hunt for new app registrations: filter applications by createdDateTime. Open each new record and read requiredResourceAccess. An empty-looking app with a client secret and Application-type Directory.ReadWrite.All is persistence, not a developer experiment. Delete it, then rotate anything it could have touched.
  • Rotate secrets that were live during the unpatched window: Microsoft’s no-customer-action line refers to the Entra binary. Your client secrets still need rotation. Rotate application passwords, SAML signing certs you control, and long-lived Graph tokens you issued. Workload identity federation beats a secret that sat in a config file through a 10.0.
  • Confirm Conditional Access coverage: legacy protocols, excluded break-glass accounts, and named trusted locations are the usual holes. A stolen token is less useful if token lifetime and sign-in frequency policies actually apply to admins. Test with a non-prod admin. A screenshot of the policy list is not a test.
  • Keep the ticket open past the vendor statement: the first bulletin said exploited. The second said it was not. Either way, a 10.0 on the control plane of your SSO stack needs a written closeout: logs pulled, grants reviewed, secrets rotated, owners named. Close it when those steps are done, not when a headline says no action required.

If you write software that accepts serialized objects from the network, this CVE is also a code review prompt. JSON with an explicit schema is boring. Pickle, default YAML load, Java ObjectInputStream, and .NET BinaryFormatter are how CWE-502 keeps showing up in products that already knew better. Refuse those formats at the trust boundary.

Press Cmd K to search