„DuneSlide“: kaip nekaltas užklausimas „Cursor“ AI redaktoriuje galėjo virsti pilna kompiuterio kontrole

Įsivaizduok kasdienę situaciją: programuotojas dirba su populiariu AI kodo redaktoriumi „Cursor“, paprašo agento „susirask, kaip pataisyti šią klaidą“, o agentas pasidomi internete arba per prijungtą įrankį. Nieko neįtartino. Tačiau būtent šioje akimirkoje – be jokio papildomo paspaudimo ir be jokių leidimų – užpuolikas galėjo perimti visą kompiuterį.

Būtent tokį scenarijų liepos 1 d. atskleidė „Cato Networks“ tyrėjai (Cato AI Labs). Jie aprašė dvi kritines „Cursor“ spragas, kurias pavadino „DuneSlide“ – abi įvertintos maksimaliai artimu 9,8 iš 10 pavojingumo balu (CVE-2026-50548 ir CVE-2026-50549). Esmė paprasta ir kartu nerimą kelianti: kenkėjiškas tekstas, kurį AI agentas perskaito „tavo vardu“, gali virsti tikromis komandomis tavo mašinoje.

Kas nutiko

„Cato“ tyrėjai parodė, kaip abi spragos leidžia vadinamąjį zero-click („be paspaudimo“) prompt injection – atakos tipą, kuriam nereikia nei vartotojo teisių, nei jo veiksmų. Užtenka, kad naudotojas duotų visiškai nekaltą užklausą, o agentas jos vykdymo metu „prarytų“ užpuoliko paruoštą turinį iš nepatikimo šaltinio – pavyzdžiui, iš per „Model Context Protocol“ (MCP) prijungtos paslaugos arba iš interneto paieškos rezultatų puslapio.

Toliau tos paslėptos instrukcijos priverčia „Cursor“ agentą apeiti savo paties „smėlio dėžę“ (sandbox), įrašyti failus ten, kur neturėtų, ir galiausiai paleisti kodą jau be jokių apribojimų. „Cato“ tai vadina keliu nuo teksto iki pilnos nuotolinio kodo vykdymo (RCE) kontrolės – ir nuo lokalaus kompiuterio iki prie jo prijungtų debesijos darbo aplinkų.

Kas yra „Cursor“ ir kodėl tai svarbu

„Cursor“ – vienas populiariausių AI kodo redaktorių, sukurtas „VS Code“ pagrindu ir papildytas agentu, kuris pats rašo, keičia failus, leidžia komandas terminale ir naršo internete. Lietuvoje jį naudoja nemažai kūrėjų komandų, o pati „icecode.lt“ filosofija – AI-native darbas – remiasi būtent tokiais įrankiais.

Kad agentas būtų naudingas, jam suteikiama galių: skaityti failus, rašyti, vykdyti komandas. Kad tos galios nepakenktų, „Cursor“ turi apsauginį sluoksnį – sandbox’ą, kuris riboja, kur agentas gali rašyti ir ką vykdyti. „DuneSlide“ istorija būtent apie tai, kaip du logikos trūkumai leido šį sluoksnį apeiti.

Kaip veikia ataka

Pirmoji spraga (CVE-2026-50548) pasinaudoja tuo, kaip „Cursor“ tvarko darbinį katalogą. Įrankis run_terminal_cmd turi neprivalomą parametrą working_directory, o sandbox’as leidžia rašyti į tos komandos darbinį aplanką. Bėda ta, kad kai agentas nurodo ne numatytąjį kelią, „Cursor“ jį įtraukia į „leidžiama rašyti“ sąrašą be jokio patikrinimo. Paslėptos instrukcijos gali nukreipti šį kelią į sisteminį failą ir perrašyti net patį sandbox’o pagalbinį failą – cursorsandbox dvejetainį. Perrašius jį, apsauga tiesiog nustoja veikti.

Antroji spraga (CVE-2026-50549) apgauna saugumo patikrą. Prieš rašydamas failą, „Cursor“ išskleidžia simbolines nuorodas (symlink), kad įsitikintų, jog tikrasis kelias veda į projekto vidų. Problema slypi atsarginiame variante: jei šis patikrinimas nepavyksta – nes taikinys neegzistuoja arba užpuolikas atima teisę skaityti vieną iš kelio aplankų – „Cursor“ pasiduoda ir tiesiog patiki simbolinės nuorodos „projekto viduje“ esančiu keliu. Taip per nuorodą galima rašyti į failus už projekto ribų.

Rezultatas abiem atvejais tas pats – galimybė perrašyti svarbius sisteminius failus, paversti „saugias“ terminalo komandas visiškai nesaugiomis ir vykdyti bet kokį kodą. Kadangi tas pats kompiuteris dažnai prijungtas prie įmonės SaaS aplinkų, kompromituojama ne tik viena mašina, bet ir prieiga prie visos komandos darbo įrankių.

Kodėl tai didesnė istorija nei viena programa

Svarbiausia „DuneSlide“ pamoka – ne konkretus „Cursor“ trūkumas, o tendencija. Dideli kalbos modeliai iš prigimties yra pažeidžiami kenkėjiškų instrukcijų, paslėptų trečiųjų šalių turinyje. Kai AI agentai gauna prieigą prie naršyklės, API ir MCP paslaugų, jie pradeda „ryti“ nepatikimus duomenis – ir kiekvienas toks kanalas tampa nauju atakos paviršiumi.

Patys tyrėjai pabrėžia, kad tai nėra pavieniai atvejai: „Jei tai būtų buvę pavieniai kompromitavimo per prompt injection atvejai, galbūt būtume juos priskyrę konkrečioms spragoms.“ „Cato“ teigia atsakingai informuojanti apie panašias problemas ir kituose populiariuose kodo agentuose. Kitaip tariant, „prompt injection“ iš teorinės grėsmės virsta realiu nuotolinio kodo vykdymo vektoriumi – ir tai aktualu kiekvienam, kas šiandien diegia AI agentus.

Ką daryti dabar

Gera žinia – pataisos jau seniai išleistos. Abi spragos ištaisytos „Cursor 3.0“ versijoje (pirmoji – balandžio 2 d., antroji – birželio 1 d.), o visos senesnės nei 3.0 versijos yra pažeidžiamos. Praktiniai žingsniai komandoms:

• Atsinaujink „Cursor“ iki 3.0 ar naujesnės versijos ir įsitikink, kad visa komanda tai padarė.
• Traktuok agento „perskaitytą“ turinį kaip nepatikimą – web puslapius, MCP atsakymus, svetimus repozitorijus. Tai duomenys, ne komandos.
• RiboK agento galias: mažiausių privilegijų principas, atskiri katalogai, jokio nereikalingo priėjimo prie sistemos failų ar tinklo.
• Apsvarstyk patvirtinimo darbo eigas rizikingiems veiksmams – nors jos ir sukelia „patvirtinimų nuovargį“, jos lieka svarbiu saugikliu.
• Nekritiškai nepasitikėk sandbox’u – kaip parodė „DuneSlide“, apsauginis sluoksnis irgi gali turėti spragų.

AI agentai kūrėjų darbą pagreitina kartais dvigubai – bet kartu perkelia dalį pasitikėjimo į tekstą, kurį modelis perskaito. „DuneSlide“ primena, kad saugumo klausimai su AI įrankiais neišnyksta, o tik keičia formą. Kartais pavojingiausia komanda yra ta, kurios niekas sąmoningai neįvedė.