Vulnerabilitățile Zoom annotation: când simpla prezență într-o întâlnire devine suprafață de atac

Zoom a publicat pe 11 august 2026 trei buletine pentru vulnerabilități de memorie din funcția de adnotare a clienților săi. Compania confirmă că CVE-2026-53413 și CVE-2026-53415 pot permite unui participant să execute cod de la distanță pe dispozitivul altui participant, iar CVE-2026-53414 poate provoca un denial of service. Cercetătorii A Security descriu un scenariu mai amplu, denumit „Zoomsday”, în care participantul rău intenționat nu are nevoie de un clic sau de un mesaj vizibil pentru victimă.

Ce confirmă Zoom

Cele trei buletine Zoom separă clar impactul și severitatea. Toate descriu erori în funcția de adnotare și un atac lansat de un participant împotriva altui participant prin acces de rețea. Vectorii CVSS publicați de Zoom includ interacțiunea utilizatorului, în timp ce A Security susține că, în demonstrația sa, simpla participare la întâlnire a fost suficientă. Diferența dintre evaluări trebuie păstrată până când există date tehnice sau operaționale suplimentare.

• CVE-2026-53413 — buffer overwrite, CVSS 8.3, severitate High; Zoom spune că poate permite execuția de cod de la distanță pe dispozitivul altui participant.
• CVE-2026-53414 — buffer over-read, CVSS 6.5, severitate Medium; buletinul Zoom indică denial of service, nu execuție de cod sau furt de date.
• CVE-2026-53415 — use-after-free, CVSS 8.3, severitate High; Zoom spune că poate permite execuția de cod de la distanță pe dispozitivul altui participant.
• Zoom atribuie primele două raportări lui Idan Levcovich de la A Security, iar CVE-2026-53415 echipei Zoom Offensive Security.

Ce susține cercetarea „Zoomsday”

A Security spune că a urmărit traseul datelor de adnotare și a demonstrat posibilitatea ca persoana care distribuie ecranul să atace participanții care urmăresc, dar și ca un participant să atace prezentatorul. În descrierea cercetătorilor, victima nu trebuia să apese pe un link, să descarce un fișier sau să accepte o solicitare, iar atacul nu producea o indicație vizibilă în instrumentul de adnotare.

Aceasta este o demonstrație tehnică raportată responsabil, nu un raport de incident. Nu sunt publice dovezi că atacatori au folosit vulnerabilitățile împotriva unor organizații, nu există o listă de victime și nici cele trei identificatoare nu figurau în CISA KEV la verificarea din 12 august. De aceea, articolul nu folosește termenii „exploatat activ” sau „breșă Zoom”.

Versiunile pe care trebuie să le verifici

Buletinele oficiale definesc pragurile afectate pe familii de produse. O organizație trebuie să compare versiunea efectiv instalată cu ramura corespunzătoare și să prefere cea mai nouă versiune suportată, nu doar pragul minim din advisory.

• Zoom Workplace, pe toate platformele suportate: versiunile anterioare 7.1.5 și 7.0.6 în ramurile lor sunt afectate.
• Zoom Workplace VDI Client pentru Windows: versiunile anterioare 7.0.11 și 6.6.16 în ramurile lor sunt afectate.
• Pentru CVE-2026-53413 și CVE-2026-53414, Zoom Rooms și Meeting SDK pe toate platformele sunt afectate înainte de 7.1.0.
• Pentru CVE-2026-53415, Zoom Rooms și Meeting SDK pe toate platformele sunt afectate înainte de 7.1.5.
• Inventarul trebuie să includă VDI, sălile și aplicațiile care încorporează Meeting SDK; verificarea doar a laptopurilor angajaților lasă o parte din suprafață neacoperită.

Plan practic pentru administratori

• Inventariază Zoom Workplace, VDI, Rooms și Meeting SDK, inclusiv dispozitivele rar conectate și imaginile de desktop care pot reinstala o versiune veche.
• Aplică ultima versiune suportată și impune o versiune minimă prin instrumentele administrative disponibile organizației; actualizarea automată nu este dovada că toate endpointurile au ajuns la prag.
• Verifică după distribuire versiunea pornită, nu doar starea jobului de instalare, și tratează excepțiile cu owner și termen de expirare.
• Dacă actualizarea imediată nu este posibilă, restricționarea temporară a adnotării sau a participării neautentificate poate reduce expunerea, dar nu înlocuiește patch-ul.
• Caută în telemetrie crash-uri neobișnuite ale clientului Zoom și procese copil suspecte, corelate cu întâlniri; absența lor nu demonstrează că dispozitivul este reparat.
• Păstrează lista aplicațiilor interne sau ale furnizorilor care folosesc Meeting SDK și cere confirmarea versiunii incluse, deoarece utilizatorul poate să nu vadă marca Zoom.

Ce trebuie să știe participanții și gazdele

Acesta nu este un caz în care „nu da clic” rezolvă totul. Reflexul util este să menții clientul actualizat, să limitezi accesul la întâlnire și să raportezi comportamentul neobișnuit. O invitație legitimă și o gazdă cunoscută nu garantează că fiecare participant sau dispozitiv din întâlnire este de încredere.

• Gazda folosește waiting room, autentificare și lista participanților potrivit sensibilității întâlnirii și elimină persoanele care nu pot fi verificate.
• Drepturile de screen sharing și annotation sunt acordate doar când sunt necesare, fără a presupune că setarea înlocuiește actualizarea.
• Participantul raportează rapid un crash, o aplicație care pornește neașteptat sau o întâlnire cu persoane necunoscute și notează ora și meeting ID-ul pentru investigație.
• Help desk-ul nu cere dezactivarea protecțiilor endpoint sau instalarea unui client primit prin chat; distribuie actualizarea numai prin canalul aprobat.

Tabletop: întâlnirea fără clic suspect

Exercițiul poate reuni IT, SOC, help desk, proprietarul platformei de colaborare, echipa care administrează sălile și un reprezentant de business. Scopul este să testeze inventarul și deciziile, nu să reproducă exploitul.

• Inject 1 — Zoom publică buletinele, dar consola arată doar laptopurile gestionate. Cine găsește VDI, Rooms și implementările Meeting SDK?
• Inject 2 — un director raportează că Zoom s-a închis în timpul unei întâlniri externe. Ce date colectează help desk-ul fără să declare incidentul confirmat?
• Inject 3 — o sală critică nu poate fi actualizată înaintea unei ședințe. Cine aprobă restricțiile temporare, cine acceptă riscul și când expiră excepția?
• Inject 4 — un furnizor spune că aplicația sa folosește un SDK Zoom, dar nu poate confirma versiunea. Cine decide dacă serviciul rămâne disponibil?
• Inject 5 — distribuirea s-a încheiat, însă 7% dintre clienți nu au mai raportat inventar de 30 de zile. Sunt considerați remediați sau necunoscuți și cine îi urmărește?

Dovezile care închid acțiunea

• Acoperirea inventarului pe fiecare familie de produs și procentul endpointurilor cu versiune verificată după actualizare.
• Lista excepțiilor, ownerul, controlul temporar și data de expirare pentru fiecare dispozitiv sau integrare.
• Timpul dintre advisory, aprobarea remedierii și confirmarea versiunii pe activele expuse.
• Procentul participanților care raportează corect un crash sau o persoană necunoscută fără să inventeze o cauză.
• Rezultatul unui exercițiu în care echipa descoperă cel puțin un client VDI, o sală și o aplicație cu Meeting SDK.

Lecția pentru programul de awareness

Trainingul bazat exclusiv pe clicuri ratează incidentele în care vulnerabilitatea este în software-ul de colaborare. Lecția mai matură leagă trei comportamente: actualizare verificată de IT, controlul participanților de către gazdă și raportarea rapidă de către utilizator. Niciunul nu este perfect singur, dar împreună reduc timpul în care o eroare tehnică poate rămâne neobservată.

Learning Awarely poate transforma scenariul într-un modul scurt pentru utilizatori și într-un tabletop separat pentru echipele tehnice, cu răspunsuri și timpi măsurabili. Obiectivul nu este memorarea celor trei CVE-uri, ci construirea unui proces repetabil pentru instrumentele în care simpla participare poate deveni parte din suprafața de atac.