Vulnerabilitate 0day in Cursor — editorul AI executa cod malitios fara sa stii. Cum te protejezi in 2026

Cursor, unul dintre cele mai populare editoare de cod bazate pe AI din lume, are o vulnerabilitate critica de tip 0day care permite executia automata de cod malitios — fara nicio interactiune din partea ta. Vulnerabilitatea a fost raportata in decembrie 2025 si, la sapte luni distanta, ramane necorectata. Daca folosesti Cursor pentru programare, acest articol iti explica exact ce se intampla, de ce este periculos si ce masuri concrete poti lua pentru a te proteja.

Ce vei gasi in acest articol:

• Ce este vulnerabilitatea 0day din Cursor si cum functioneaza pas cu pas
• Cum a demonstrat Mindgard ca un simplu fisier poate compromite editorul
• Timeline-ul complet al descoperirii si incercarilor de remediere
• Masuri concrete de protectie pentru utilizatori individuali si companii
• Ce inseamna acest incident pentru increderea in tool-urile AI de coding

Ce este Cursor si de ce conteaza aceasta vulnerabilitate

Cursor este un editor de cod bazat pe inteligenta artificiala, construit pe baza VS Code (Microsoft). Spre deosebire de VS Code clasic, Cursor integreaza AI direct in fluxul de lucru — poti genera cod, repara bug-uri si interactiona cu un asistent AI direct din editor.

Cifrele arata cat de popular este Cursor:

• 7 milioane de utilizatori activi
• 1 milion de utilizatori zilnic
• 1 milion de utilizatori platitori
• Peste 50.000 de companii il folosesc
• Valoare de piata raportata: aproximativ 60 de miliarde de dolari

Cu aceste numere, o vulnerabilitate care permite executia automata de cod arbitrar nu este o problema tehnica minora — este un risc de securitate pentru milioane de dezvoltatori si companii din intreaga lume.

Daca esti interesat de securitatea tool-urilor de coding, poti citi si articolul nostru despre Alibaba care a interzis Claude Code angajatilor din cauza unui backdoor.

Cum functioneaza vulnerabilitatea — pas cu pas

Problema este in modul in care Cursor cauta si executa binarele Git. Cand deschizi un proiect in editor, acesta are nevoie de Git pentru a gestiona repository-ul — commit-uri, branch-uri, status si asa mai departe.

Iata ce se intampla:

1. Cursor cauta binarul Git in mai multe locatii cand deschizi un proiect. Aceasta este o functionalitate normala — orice editor de cod trebuie sa gaseasca Git pentru a functiona.

2. Problema: include si workspace-ul curent. Cursor cauta fisierul git.exe si in folderul proiectului pe care l-ai deschis, nu doar in locatiile de sistem unde Git ar trebui instalat normal.

3. Executie automata, fara avertisment. Daca gaseste un git.exe in radacina repository-ului, il executa automat. Nu iti cere aprobare, nu afiseaza un avertisment, nu iti permite sa decizi daca vrei sau nu sa executi acel fisier.

4. Executie repetata. Cursor continua sa re-execute fisierul malitios in mod repetat cat timp proiectul este deschis. Nu este o executie singulara — este o executie continua.

5. Rezultat: cod arbitrar cu privilegiile tale. Atacatorul poate rula orice cod cu aceleasi privilegii ca si utilizatorul care a deschis Cursor. Daca tu ai acces la date sensibile, chei de API, baze de date sau alte resurse, si codul malitios le poate accesa.

Ce inseamna asta in practica

Imagineaza-ti urmatorul scenariu: cineva planteaza un fisier git.exe malitios intr-un repository public pe GitHub. Tu clonezi acel repository sau il deschizi in Cursor. Fara sa faci absolut nimic — niciun click, nicio aprobare, nicio confirmare — Cursor executa automat acel fisier.

Mindgard, compania de securitate care a descoperit vulnerabilitatea, a demonstrat acest lucru cu un proof-of-concept simplu: au redenumit Windows Calculator in git.exe si l-au plasat in radacina unui repository. Cand au deschis proiectul in Cursor, editorul a executat automat Calculatorul si a continuat sa deschida instante noi in mod repetat.

Daca in loc de Calculator ar fi fost un keylogger, un ransomware sau un instrument de exfiltrare de date, consecintele ar fi fost mult mai grave.

Timeline-ul complet al vulnerabilitatii

Aceasta este cronologia completa a evenimentelor, de la descoperire pana la publicarea full disclosure:

De ce este acest lucru atat de grav

Vulnerabilitatea din Cursor este grava din mai multe motive care se suprapun:

1. Nu necesita nicio interactiune

Cele mai multe atacuri necesita macar un click sau o deschidere de fisier. Aici, simpla deschidere a unui proiect in Cursor este suficienta. Daca clonezi un repository de pe GitHub si il deschizi in editor, esti deja vulnerabil.

2. Executie automata si repetata

Cursor nu doar ca executa fisierul o data — il executa in mod repetat. Asta inseamna ca un atacator poate rula cod la intervale regulate, poate mentine accesul la sistem si poate exfiltra date continuu.

3. Afecteaza milioane de utilizatori

Cu 7 milioane de utilizatori activi si 50.000 de companii, suprafata de atac este masiva. Un singur repository popular compromis poate afecta mii de dezvoltatori simultan.

4. Cursor nu a corectat problema

Dupa 7 luni si peste 197 de versiuni, vulnerabilitatea ramane activa. Ultima verificare confirmata a fost pe 30 aprilie 2026, pe Cursor versiunea 3.2.16 pe Windows. Asta inseamna ca echipa Cursor stie de problema si nu a prioritizat rezolvarea ei.

5. Modelul de incredere este rupt

Cand folosesti un editor de cod, te astepti ca acesta sa nu execute automat fisiere necunoscute din proiect. Cursor incalca aceasta asteptare fundamentala de securitate.

Despre riscurile generate de tool-urile AI si nivelul de incredere pe care ar trebui sa il acordam, am scris in articolul despre cum companiile taie din AI din cauza costurilor si daca merita abonamentele in 2026.

Nu doar tool-urile de programare sunt vulnerabile — si chatbot-urile pe care le folosesti zilnic te pot expune. Vezi cum a fost exploatata memoria lui Claude pentru a scurge date personale printr-un site malitios care pacalea AI-ul sa-si dea utilizatorii de gol.

Cum te protejezi — masuri concrete

Daca folosesti Cursor, iata ce poti face concret pentru a te proteja:

Protectie pentru companii si administratori IT

Daca administrezi o echipa care foloseste Cursor, masurile trebuie sa fie mai stricte:

Daca vrei sa intelegi mai bine cum functioneaza vulnerabilitatile de tip zero-day si cum ajung sa fie exploatate, vezi articolul nostru despre Exploitarium si cine publica zero-day-uri pe GitHub.

Ce inseamna „full disclosure” si de ce s-a ajuns aici

In lumea securitatii informatice, exista mai multe moduri in care un cercetator poate raporta o vulnerabilitate:

1. Disclosure responsabil — raportezi producatorului, astepti sa corectezi, apoi publici. Este metoda standard si preferata.

2. Coordinated disclosure — lucrezi cu producatorul si stabiliti impreuna o data de publicare, de obicei dupa ce patch-ul este disponibil.

3. Full disclosure — publici toate detaliile vulnerabilitatii, inclusiv cum poate fi exploatata, fara sa astepti patch-ul. Este „optiunea nucleara” in domeniu.

Full disclosure este rezervata situatiilor in care toate celelalte cai au esuat. In cazul Cursor, Mindgard a incercat:

• Raport direct prin email (fara raspuns)
• Follow-up prin email (fara raspuns)
• Postare pe LinkedIn pentru a gasi un contact (CISO-ul a raspuns abia dupa o luna)
• Program privat HackerOne (raportul a fost initial inchis ca „out of scope”)
• Cereri repetate de actualizare timp de 5 luni (fara raspuns)

Dupa 7 luni de incercari, Mindgard a considerat ca utilizatorii Cursor au dreptul sa stie despre risc, mai ales ca nu exista nicio perspectiva de remediere.

Implicatii mai largi pentru industria AI

Aceasta vulnerabilitate nu este doar despre Cursor. Ridica intrebari fundamentale despre cum companiile AI gestioneaza securitatea si increderea utilizatorilor.

Companiile AI cer niveluri fara precedent de acces

Editoarele AI precum Cursor, Claude Code, GitHub Copilot si altele cer acces la codul sursa, repository-uri, terminale, variabile de mediu si deseori secrete (chei API, token-uri). Acest nivel de acces este necesar pentru functionalitate, dar creeaza si un risc semnificativ daca nu este gestionat corect.

Increderea trebuie castigata, nu acordata

Faptul ca un produs este util si popular nu inseamna automat ca este sigur. Cursor are 7 milioane de utilizatori si o valoare de 60 de miliarde de dolari, dar asta nu l-a impiedicat sa lase o vulnerabilitate critica necorectata timp de 7 luni.

Programele de bug bounty pot fi supraincarcate

HackerOne si platformele similare sunt instrumente valoroase, dar nu functioneaza daca producatorii nu raspund sau trateaza rapoartele cu seriozitate. Faptul ca raportul Mindgard a fost initial inchis ca „out of scope” si ca nimeni nu a raspuns timp de 5 luni ridica semne de intrebare despre angajamentul real al Cursor fata de securitate.

Pentru a intelege mai bine cum functioneaza atacurile prin AI si cum se poate compromite un sistem, poti citi articolul nostru despre prompt injection si cum te protejezi de atacurile prin AI. Si mai relevant: atacul The Memory Heist a demonstrat cum functia de memorie a lui Claude poate fi exploatata pentru a extrage date personale — un alt exemplu de cum instrumentele AI legitime pot fi transformate in arme.

Ce ar trebui sa faci acum

Iata un plan de actiune concret, in functie de situatia ta:

Intrebari frecvente