Pe 20 august 2026 Microsoft a publicat buletinul pentru CVE-2026-69836, o vulnerabilitate de execuție de cod la distanță în Microsoft Entra ID — serviciul de identitate din cloud numit anterior Azure Active Directory. Scorul CVSS 3.1 de bază este 10.0, maximul posibil. Cauza este deserializarea datelor din surse neîncrezute (CWE-502), accesibilă fără autentificare, prin rețea. Persoana creditată în buletin este Robert Fitzpatrick, principal security engineer la Microsoft — deci descoperirea a venit din interior, nu dintr-un raport extern.
Apoi buletinul a afirmat ceva care s-a dovedit fals. Câmpul Exploited a fost publicat cu valoarea Yes. Pe 21 august, după ce The Hacker News a cerut o clarificare, Microsoft a emis revizia 2: „Corectat Exploited la No. Această vulnerabilitate nu a fost exploatată în mediul real. Este o modificare exclusiv informativă." CERT-FR a parcurs același drum: avizul CERTFR-2026-AVI-1074, publicat pe 21 august, relua afirmația, iar pe 24 august a fost revizuit pentru a o retrage.
Timp de aproape o zi, informația publică arăta o vulnerabilitate de severitate maximă, exploatabilă fără autentificare și aflată sub atac activ, exact în sistemul prin care se autentifică majoritatea organizațiilor care folosesc Microsoft. Echipele care au deschis o ședință de criză pe 20 august au lucrat pe o premisă neadevărată.
De ce scorul este 10.0 și de ce nu ai ce să instalezi
Vectorul CVSS este CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:C/C:H/I:H/A:H: atac prin rețea, complexitate redusă, fără privilegii, fără interacțiunea utilizatorului, impact maxim pe confidențialitate, integritate și disponibilitate. Elementul care duce scorul de la 9.8 la 10.0 este S:C — Scope: Changed: componenta vulnerabilă și componenta afectată nu sunt aceeași. Într-un serviciu de identitate, exact asta este esența problemei. Execuția de cod în platforma care emite token-uri nu rămâne în interiorul platformei.
Scorul temporal calculat de Microsoft a fost 8.7, cu E:U (cod de exploatare nedovedit), RL:O (există remediere oficială) și RC:C (confirmat). Decizia CISA din programul Vulnrichment, înregistrată pe 21 august, este Exploitation: none, Automatable: yes, Technical Impact: total. EPSS pe 31 august 2026 era 0,0156 — aproximativ percentila 73.
Buletinul are eticheta exclusively-hosted-service și, la secțiunea Customer Action, un singur rând: „Nu este necesară. Vulnerabilitatea documentată de acest CVE nu necesită nicio acțiune din partea clientului." Microsoft precizează că problema fusese deja remediată complet în infrastructura proprie și că CVE-ul există pentru transparență, în cadrul programului de publicare a CVE-urilor pentru servicii cloud lansat în 2024.
Merită spus direct: aici, înțelegerea pe care o accepți când muți identitatea pe un plan de control găzduit a funcționat. Nu a existat fereastră de mentenanță, nu a existat schimbare de urgență, nu a existat un parc de servere de actualizat.
Un detaliu mai arată cât de departe ajunge un câmp completat greșit. CVE-ul a fost adăugat în catalogul CISA de vulnerabilități exploatate cunoscute (KEV) pe 21 august 2026, cu termen de remediere 24 august. Am verificat fluxul KEV pentru acest articol: în versiunea 2026.08.31, publicată pe 31 august 2026 și conținând 1.687 de intrări, CVE-2026-69836 nu mai apare. A fost adăugat în perioada în care câmpul producătorului indica „Yes" și nu mai este listat acum, când indică „No".
Ce rămâne în responsabilitatea ta într-un serviciu de identitate găzduit
„Nicio acțiune necesară" este corect despre cod și înșelător despre risc. Vulnerabilitatea era în serviciul Microsoft. Configurația, privilegiile, relațiile de încredere și dovezile sunt ale tale.
Întrebarea reală ridicată de acest CVE nu este „am aplicat patch-ul". Este: dacă vulnerabilitatea ar fi fost exploatată, am fi putut răspunde la „a fost afectat tenantul nostru?" folosind telemetria pe care o deținem? Pentru majoritatea organizațiilor, răspunsul depinde de decizii luate cu luni în urmă.
Entra ID păstrează jurnalele de autentificare și de audit 30 de zile cu licențe P1 și P2 și 7 zile pe nivelul gratuit. Acesta este comportamentul implicit. Dacă nu ai configurat diagnostic settings pentru export către un Log Analytics workspace, către un SIEM sau către Microsoft Sentinel, capacitatea de a investiga un incident de identitate expiră într-o fereastră mobilă de o lună — iar diagnostic settings necesită la rândul lor P1 sau P2. O investigație privind o posibilă compromitere a emiterii de token-uri, pornită cu șase săptămâni întârziere, nu are pe ce să lucreze.
Patru lucruri merită verificate în propriul tenant, niciunul legat strict de acest CVE:
- Retenția și exportul jurnalelor. Unde ajung jurnalele Entra de autentificare, de audit și de provisioning, cât timp sunt păstrate și cine le poate interoga la ora două noaptea?
- Igiena rolurilor privilegiate. Câte conturi au permanent Global Administrator, în loc de acces eligibil la cerere prin Privileged Identity Management? Care dintre ele sunt excluse din politicile de conditional access? Conturile break-glass sunt documentate, păstrate corespunzător și testate?
- Service principals și consimțământul aplicațiilor. Aplicațiile de tip enterprise cu permisiuni Graph la nivel de aplicație nu au nevoie de un utilizator, de o parolă sau de o solicitare MFA. Sunt partea cel mai rar revizuită dintr-un tenant și partea care supraviețuiește unei resetări de parole.
- Conditional access așa cum este scris, nu așa cum a fost intenționat. Politicile acumulează grupuri de excepție. Un grup de test creat pentru un proiect de acum doi ani este în continuare exceptat de la cerințele de conformitate a dispozitivelor, iar nimeni nu răspunde de revizuire.
Nimic din lista de mai sus nu se descoperă scanând o aplicație web. Revizuirea configurației de identitate trebuie să intre într-un scop definit, alături de evaluarea platformelor cloud și de identitate și de testul de penetrare intern și extern care verifică ce permite efectiv configurația.
Unde se încadrează în NIS 2
Pentru entitățile esențiale și importante din România, NIS 2 este transpusă prin Ordonanța de urgență a Guvernului nr. 155/2024, aprobată cu modificări prin Legea nr. 124/2025. Trei obligații ating direct acest caz.
Măsurile de management al riscului, articolul 21 din Directiva (UE) 2022/2555, includ explicit securitatea lanțului de aprovizionare și securitatea relațiilor cu furnizorii direcți de servicii TIC. Un furnizor de identitate este cel mai consecvent furnizor TIC pe care îl are o organizație. Locul lui este în inventarul de active și în analiza de risc, ca dependență numită, cu riscul rezidual — faptul că tenantul nu poate remedia serviciul — scris și asumat la nivelul potrivit.
Răspunderea conducerii, articolul 20, înseamnă că aprobarea și supravegherea acestor măsuri stau la nivelul organului de conducere, nu al echipei IT. „Furnizorul nostru de identitate a avut un 10.0 și nu am avut cum să verificăm propria expunere" este o constatare de guvernanță, nu una tehnică.
Raportarea incidentelor, articolul 23, funcționează pe ciclul de avertizare timpurie în 24 de ore, notificare în 72 de ore și raport final în o lună, depuse la DNSC prin platforma PNRISC. Cele patru verificări de mai sus sunt exact ce face aceste termene realizabile. Obligațiile de raportare nu se suspendă pentru că cauza a fost în codul unui furnizor.
Lecția mai largă: un câmp din buletinul furnizorului este un declanșator, nu o concluzie
Prioritizarea în funcție de exploatarea reală este modelul corect — un 7.0 folosit activ de un actor real este mai important decât o duzină de 9.8 neexploatate. Acest caz arată costul operațional al construirii modelului pe un singur câmp, dintr-o singură sursă.
În special pentru servicii găzduite nu există patch de partea clientului care să condiționeze răspunsul, deci câmpul din buletin este declanșatorul. De aici o regulă scrisă merită efortul: când un furnizor semnalează exploatarea într-un serviciu pe care îl consumi, nu pe care îl administrezi, prima acțiune este verificarea în propria telemetrie și, unde există, într-o a doua sursă — catalogul KEV, CERT-ul național, fluxul CSAF al furnizorului — înainte de a declara un incident. Reviziile buletinelor se publică discret. Cineva trebuie să răspundă de recitirea lor.
Un audit de securitate și o evaluare de risc care tratează stratul de identitate ca dependență guvernată, plus o poziție documentată de conformitate NIS 2 și DORA, transformă un buletin ca acesta din improvizație în decizie înregistrată.
Acest articol are caracter informativ general și nu constituie consultanță juridică sau de reglementare.
Surse: Microsoft Security Response Center — CVE-2026-69836 · The Hacker News · Help Net Security · CERT-FR CERTFR-2026-AVI-1074 · CIRCL Vulnerability-Lookup · CISA Known Exploited Vulnerabilities Catalog · Retenția datelor în Microsoft Entra
Afirmația inițială privind exploatarea a provenit din buletinul Microsoft și a fost retrasă de Microsoft; nu am găsit dovezi de exploatare din surse terțe. Adăugarea în KEV și eliminarea ulterioară sunt afirmate pe baza comparației proprii între datele din catalog de la 21 august și versiunea KEV din 31 august 2026; nu am identificat o declarație CISA care să explice eliminarea.