CVE-2026-65400: Screen Sharing pe macOS până la root
Pe 6 august 2026, Apple a lansat actualizări de urgență pentru macOS care închid CVE-2026-65400, o vulnerabilitate în serviciul Screen Sharing. Un atacator neautentificat, care are doar adresa IP a țintei, poate citi și scrie fișiere arbitrare și executa cod ca root.
Nu e o problemă teoretică: dovezi de concept funcționale, cu execuție de cod, sunt publice de pe 2 august. Iar scanările au găsit zeci de mii de gazde potențial vulnerabile la furnizorii de Mac-uri găzduite.
Versiunile și ce trebuie instalat
Dacă nu poți actualiza imediat, dezactivarea serviciului Screen Sharing elimină această suprafață de atac. E important de subliniat că măsurile obișnuite de întărire nu ajută aici: ștergerea conturilor de utilizator sau dezactivarea autentificării VNC nu blochează un atac care ocolește autentificarea din start.
- ▸macOS Tahoe 26.6 și anterioare — reparat în 26.6.1
- ▸macOS Sequoia 15.7.8 și anterioare — reparat în 15.7.9
- ▸macOS Sonoma 14.8.8 și anterioare — reparat în 14.8.9
- ▸Toate cele trei actualizări au fost lansate pe 6 august 2026
Bug-ul: un validator care spune „da" din inerție
Screen Sharing folosește Secure Remote Password, un protocol de autentificare proiectat tocmai ca parola să nu treacă niciodată prin rețea. Implementarea din serviciul screensharingd are însă o problemă în calea de validare a lungimii cadrelor.
Acea cale returnează o stare de succes rămasă din pasul anterior, în loc să evalueze cadrul curent. Conexiunea e tratată ca autentificată fără ca verificarea criptografică să fi avut loc. De acolo, sesiunea continuă în clar, fără protecțiile care ar fi trebuit să o acopere.
Merită reținut tiparul, pentru că se repetă în multe implementări: nu criptografia a cedat, ci codul din jurul ei. Un rezultat de validare care nu e reinițializat între pași e o eroare banală de programare cu efectul complet al unei ocoliri de autentificare.
De la fișiere la root
Cu autentificarea ocolită, atacatorul ajunge la componenta auxiliară SSFileCopySender, care moștenește permisiuni de acces complet la disc. Prin ea se obțin citiri și scrieri arbitrare de fișiere, ocolind și protecțiile TCC — mecanismul care în mod normal cere consimțământul utilizatorului pentru accesul la date sensibile.
Trecerea la execuție de cod urmează căi cunoscute: crearea unui LaunchDaemon sau modificarea fișierelor de pornire ale shell-ului. Ambele oferă și persistență, nu doar execuție de moment.
Rezultatul final e control ca root pe mașină, pornind de la nimic altceva decât o adresă IP accesibilă.
Cealaltă vulnerabilitate, din iulie
CVE-2026-65400 nu a apărut singură. Pe 27 iulie 2026, Apple reparase CVE-2026-43760, o problemă înrudită în operațiunile pe fișiere ale aceluiași serviciu.
Diferența dintre ele e exact granița care contează: CVE-2026-43760 cerea credențiale VNC valide și permitea unui utilizator autentificat să citească și să creeze fișiere ca root. CVE-2026-65400 elimină cerința de credențiale cu totul.
Dacă ai aplicat actualizarea din iulie și ai considerat subiectul închis, nu e închis. Sunt două probleme distincte, cu două patch-uri distincte, iar cea din august e cea gravă.
De ce expunerea e mai mare decât pare
Pe un Mac obișnuit, Screen Sharing e dezactivat implicit și trebuie pornit intenționat. Asta limitează mult populația afectată — dar nu uniform.
Serviciile de Mac-uri găzduite pe hardware dedicat livrează frecvent mașinile cu Screen Sharing deja activat, uneori pe porturi nestandard. Scanările Censys au identificat zeci de mii de gazde potențial vulnerabile în acest segment.
Aici e riscul concret pentru organizații: flotele de Mac-uri din cloud folosite pentru compilări iOS și testare automată. Sunt mașini care rulează neatinse luni de zile, cu acces la depozitele de cod și la certificatele de semnare, și pe care nimeni nu le tratează ca pe niște servere expuse.
Ce faci practic
- ▸Actualizează la 26.6.1, 15.7.9 sau 14.8.9, în funcție de ramura pe care ești
- ▸Până atunci, dezactivează Screen Sharing — e singura măsură care chiar oprește atacul
- ▸Inventariază Mac-urile găzduite și agenții de compilare din cloud; acolo serviciul e pornit fără ca cineva să fi decis asta
- ▸Nu expune niciodată Screen Sharing direct la internet; dacă e necesar accesul de la distanță, pune-l în spatele unui VPN
- ▸Verifică porturile nestandard, nu doar portul implicit — furnizorii de găzduire le schimbă frecvent
- ▸După actualizare, caută LaunchDaemon-uri create recent și modificări ale fișierelor de pornire ale shell-ului: acelea sunt mecanismele de persistență din lanțul demonstrat
Ce e confirmat și ce nu
Cronologia dovezilor de concept e publică: pe 29 iulie 2026, cercetătorul Pedro Vilaça a publicat o dovadă ofuscată, doar pentru citire. Până pe 2 august, bl4sty a inversat binarul și a publicat variante funcționale cu citire, scriere și execuție de cod.
Avizul Apple nu afirmă că vulnerabilitatea ar fi fost exploatată activ, iar analiza tehnică nu documentează exploatare observată în sălbăticie.
Distincția merită păstrată onest, dar nu schimbă urgența. O vulnerabilitate pre-autentificare, cu execuție de cod ca root, cu exploit funcțional public și zeci de mii de gazde identificate drept potențial vulnerabile nu are nevoie de confirmare de exploatare ca să justifice o actualizare în aceeași zi.
Leagă patch-ul de Mac-urile pe care chiar le rulezi
MONITOR AWARELY corelează vulnerabilitățile publice cu inventarul tău de active și versiunile instalate, astfel încât actualizarea urgentă să devină o sarcină verificabilă.