Sandbox miał być twardą barierą, której prompt nie przekroczy. DuneSlide pokazuje, że agent potrafi nadpisać własne więzienie — bo klucz do niego leży w środku.

Przez cały czerwiec wracaliśmy do jednego zdania: jedyną twardą barierą dla agenta AI jest to, czego nie może zrobić, bo nie ma uprawnień — nie to, co obiecał, że zrobi. Zabezpieczenia wpisane w prompt zawodzą; liczy się sandbox, uprawnienie, twarda granica techniczna. 1 lipca Cato AI Labs pokazało, gdzie ta teza ma własną granicę. Bo jeśli sam sandbox ma błąd w walidacji, to agent — odpowiednio nakłoniony — potrafi go nadpisać. Nie ominąć. Nadpisać: skasować plik, który stanowi jego więzienie, i od tej chwili działać bez żadnych ścian.

Dwie luki w edytorze Cursor, nazwane wspólnie DuneSlide, robią dokładnie to. Obie mają ocenę 9,8 na 10. Obie pozwalają, by pojedynczy, niewinnie wyglądający prompt uciekł z sandboxa i uruchomił dowolne polecenie na komputerze programisty — bez kliknięcia, bez okna zgody. A Cursora, według jego twórców, używa ponad połowa firm z listy Fortune 500. To jest temat dla cyberflux nie dlatego, że to kolejna krytyczna luka, ale dlatego, że pokazuje, jak pęka bariera, którą sami nazwaliśmy ostatnią linią obrony.

Jak działa ucieczka z klatki

Zacznijmy od tego, co Cursor robi dobrze — bo to jest tło, na którym błąd staje się groźny. Od linii 2.x Cursor uruchamia polecenia terminalowe, które wydaje jego agent AI, wewnątrz sandboxa: zamkniętego pudełka, które ogranicza, czego te polecenia mogą dotknąć. Dzięki temu agent może działać bez pytania użytkownika o zgodę przy każdej komendzie, a błędna instrukcja — choćby wstrzyknięta przez atakującego — nie rozłoży maszyny. To jest właśnie ta „twarda bariera": nie ufamy temu, co model powie, ufamy temu, że sandbox go powstrzyma.

DuneSlide polega na wyjściu z tego pudełka. Punktem wejścia jest prompt injection — i tu warto podkreślić, jak cicho to działa. Atakujący nigdy nie dotyka twojego Cursora. Umieszcza instrukcje w czymś, co twój agent i tak przeczyta w twoim imieniu: w odpowiedzi z serwera MCP, do którego się podłączyłeś, albo na stronie zwróconej przez wyszukiwarkę. Ty wpisujesz zwykły, niewinny prompt. Agent w trakcie jego realizacji wciąga zatrutą treść — i wykonuje ukryte w niej polecenia. Żadnego kliknięcia, żadnego pliku do otwarcia. To jest atak zero-click w najczystszej postaci.

Pierwsza luka, CVE-2026-50548, nadużywa ustawienia. Narzędzie run_terminal_cmd ma opcjonalny parametr working_directory — katalog roboczy, który ustala sam model. Sandbox pozwala na zapis do tego katalogu, bo z założenia to „folder projektu". Ale gdy wstrzyknięta instrukcja każe agentowi ustawić ten parametr na ścieżkę spoza projektu, Cursor bez pytania dodaje ją do listy dozwolonych zapisów. Wystarczy wskazać plik systemowy. Na macOS celem jest sam pomocniczy plik sandboxa — cursorsandbox w zasobach aplikacji. Nadpisz go, a wszystkie kolejne polecenia w tej samej sesji biegną już bez żadnego sandboxa. Równie dobrze celem może być ~/.zshrc albo folder autostartu — pliki, które system i tak wczyta przy następnej komendzie.

Druga luka, CVE-2026-50549, nadużywa mechanizmu bezpieczeństwa. Zanim Cursor cokolwiek zapisze, rozwiązuje skróty — symlinki — żeby potwierdzić, że prawdziwy cel leży wewnątrz projektu. Błąd tkwi w tym, co się dzieje, gdy ta weryfikacja zawiedzie: gdy cel nie istnieje albo atakujący odbierze prawo odczytu do folderu na ścieżce, Cursor się poddaje i ufa ścieżce symlinka takiej, jaka jest — czyli tej „wewnątrz projektu". Efekt ten sam: obejście kontroli zapisu, nadpisanie tego samego pliku sandboxa, RCE z pełnymi uprawnieniami, bez udziału użytkownika.

Dlaczego to jest głębsze niż „kolejna luka w Cursorze"

Tu wchodzimy w pogłębienie, które jest właściwym sednem raportu Cato — i powodem, dla którego to nie jest historia o jednym edytorze.

Do tej pory prompt injection rozumieliśmy jako atak na warstwę modelu: napastnik manipuluje tym, co LLM powie albo zrobi w ramach swoich uprawnień. DuneSlide pokazuje coś innego. Tu prompt injection sięga poza warstwę LLM i wyzwala klasyczne luki w kodzie, który nikt nie traktował jako powierzchni ataku. Bo przyjrzyj się, czym te dwa błędy są naprawdę: pierwszy to niewystarczająca walidacja parametru, drugi to błąd w obsłudze symlinka. To są podręcznikowe, „stare" klasy podatności — takie, które audytuje się w każdym programie od dekad. Nowe jest to, że wyzwala je nie żądanie sieciowe czy złośliwy plik, lecz zdanie wpisane do agenta AI.

To przesuwa granicę tego, co trzeba zabezpieczać. Kod, który parsuje parametr narzędzia albo rozwiązuje ścieżkę pliku, nagle staje się częścią powierzchni ataku dostępnej przez prompt. Cato mówi to wprost i to jest najważniejsze zdanie całego ujawnienia: gdyby to były pojedyncze przypadki, można by je przypisać konkretnym lukom Cursora — ale zespół jest w trakcie odpowiedzialnego ujawniania analogicznych błędów we wszystkich popularnych agentach kodujących, co pokazuje, że potrzebne jest podejście systemowe, nie łatanie pojedynczych dziur. Innymi słowy: to nie jest bug Cursora. To jest wzorzec klasy, a Cursor jest pierwszym nazwanym przykładem.

Warto też zobaczyć to w ciągu, bo DuneSlide nie spadło z nieba. To już trzeci udokumentowany przypadek, w którym zatruty prompt kończy się wykonaniem kodu w samym Cursorze — po CurXecute i MCPoison z 2025 roku, z których każdy pokonywał inne zabezpieczenie. Co znaczące, badacze Cato to dawny zespół Aim Security, ci sami, którzy znaleźli CurXecute. Widzą tę samą maszynę psującą się na kolejne sposoby i mówią: problem nie jest w tym konkretnym zabezpieczeniu, które właśnie pękło, tylko w założeniu, że kolejne zabezpieczenie wystarczy.

Uczciwie: to jest już załatane

Zanim wyciągniemy wnioski, trzymajmy dyscyplinę, którą sobie narzuciliśmy — kalibrować według dzisiejszej rzeczywistości, nie jutrzejszego potencjału.

Obie luki są naprawione w Cursorze 3.0, wydanym 2 kwietnia. Cato zgłosiło je prywatnie 19 lutego; Cursor początkowo je odrzucił, potem wznowił zgłoszenia i wydał poprawki. Numery CVE nadano 5 czerwca, a pełne ujawnienie przyszło 1 lipca. To nie jest zatem zero-day eksploatowany w tej chwili — to jest lekcja architektoniczna z zamkniętą pętlą naprawy. Każda wersja przed 3.0 pozostaje podatna, więc jedyna pilna czynność jest prosta: sprawdź, czy masz 3.0 lub nowszą. Jeśli tak — ta konkretna para luk cię nie dotyczy.

Ale to, że pojedynczy błąd jest załatany, nie znaczy, że wzorzec zniknął. Sandbox jako obrona pozostaje słuszny — jest konieczny. DuneSlide pokazuje jedynie, że jest niewystarczający, jeśli parametry, które go konfigurują, i ścieżki, które sprawdza, same są sterowalne przez wstrzyknięty prompt. Poprawka w 3.0 zamyka dwie konkretne drogi. Nie zamyka pytania, ile jeszcze takich dróg istnieje w Cursorze i w każdym innym agencie, który wykonuje polecenia we własnym imieniu.

Co z tego wynika dla obrońcy

Pierwszy wniosek jest operacyjny i natychmiastowy. Jeśli twoja organizacja używa Cursora — a statystycznie, przy ponad połowie Fortune 500, jest to prawdopodobne — potwierdź wersję 3.0 lub nowszą na każdej maszynie. To jest cała pilna reakcja na tę konkretną lukę.

Drugi jest architektoniczny i trwalszy. Każda funkcja, która pozwala agentowi pobrać zewnętrzną treść — serwer MCP, wyszukiwanie w sieci, podłączone repozytorium — jest potencjalnym wektorem wstrzyknięcia. To znaczy, że nie wystarczy pytać „czy mój agent ma sandbox". Trzeba pytać: „czy parametry tego sandboxa i logika sprawdzania ścieżek są odporne na to, że sam agent, nakłoniony przez zatrutą treść, spróbuje je przestawić". Cato wprost zaleca zespołom budującym na agentach kodujących, by audytowały własną logikę obsługi katalogu roboczego i symlinków, zamiast zakładać, że sandbox utrzyma się przeciwko autonomicznemu wciąganiu treści.

Trzeci jest najgłębszy i domyka to, co prowadzimy od miesięcy. Powiedzieliśmy, że jedyną twardą barierą jest uprawnienie — to, czego agent technicznie nie może zrobić. DuneSlide dokłada do tego przypis, którego nie wolno przeoczyć: bariera jest tak twarda, jak twardy jest kod, który ją egzekwuje. Jeśli agent potrafi, przez wstrzyknięty prompt, sięgnąć do pliku, który definiuje jego własne ograniczenia, to „nie ma uprawnień" zamienia się w „ma uprawnienia, których mu nie daliśmy". Granica uprawnień nie jest linią narysowaną raz na zawsze. Jest kodem — a kod bywa podatny, zwłaszcza w miejscach, których nikt nie traktował jako powierzchni ataku, dopóki prompt injection tam nie sięgnął.

Jedna myśl na koniec

Cała nadzieja ostatnich miesięcy opierała się na przeniesieniu obrony z warstwy, której nie kontrolujemy — tego, co model zrobi — do warstwy, którą kontrolujemy: tego, co mu wolno. DuneSlide nie obala tej nadziei, ale pokazuje jej cenę. Przeniesienie obrony do sandboxa działa tylko wtedy, gdy sam sandbox jest napisany bez błędu, którego prompt nie potrafi wyzwolić. A skoro prompt injection potrafi teraz sięgać do klasycznego kodu walidacji parametrów i obsługi ścieżek, to lista miejsc, które muszą być bezbłędne, właśnie się wydłużyła — o cały kod, który egzekwuje granice agenta. Bezpieczeństwo agenta nie kończy się na tym, że dałeś mu klatkę. Zaczyna się od pytania, czy klucz do niej nie leży przypadkiem w zasięgu jego ręki.

Źródła

Cato AI Labs — oryginalne ujawnienie DuneSlide, z pełnym opisem obu luk, mechanizmu working_directory i błędu symlinka oraz tezą o systemowym charakterze problemu: https://www.catonetworks.com/blog/duneslide-two-critical-rce-vulnerabilities/

The Hacker News — omówienie z osią czasu, kontekstem CurXecute/MCPoison i szczegółami technicznymi nadpisania pliku cursorsandbox: https://thehackernews.com/2026/07/critical-cursor-flaws-could-let-prompt.html

CSO Online — analiza „prompt injection jako wektor RCE", cytaty Cato o niewystarczalności samego sandboxa i kontekst przejęcia Cursora przez SpaceX: https://www.csoonline.com/article/4191923/sandbox-bypass-flaws-in-cursor-ide-highlight-prompt-injection-as-an-rce-vector.html