Co znajdziesz w tym artykule?
Wprowadzenie do problemu / definicja
W edytorze kodu Cursor, wykorzystującym funkcje AI do wsparcia pracy programistów, ujawniono dwie krytyczne podatności pozwalające na zdalne wykonanie kodu na poziomie systemu operacyjnego. Zagrożenie jest szczególnie poważne, ponieważ łączy prompt injection z możliwością obejścia mechanizmów izolacji i uruchamiania poleceń poza sandboxem.
Problem pokazuje, że nowoczesne narzędzia AI dla deweloperów stają się nie tylko platformą zwiększającą produktywność, ale również nowym wektorem ataku. Jeśli agent AI może wykonywać polecenia, modyfikować pliki i operować na środowisku lokalnym, to błędy w kontroli tych operacji mogą prowadzić do pełnej kompromitacji stacji roboczej.
W skrócie
Ujawnione luki zostały oznaczone jako CVE-2026-50548 oraz CVE-2026-50549 i otrzymały ocenę CVSS 9.8, co klasyfikuje je jako krytyczne. Badacze opisali ten łańcuch ataku nazwą DuneSlide.
- atak może rozpocząć się od prompt injection,
- podatności umożliwiają obejście ograniczeń sandboxa,
- napastnik może doprowadzić do nadpisania komponentu odpowiedzialnego za izolację,
- efektem końcowym jest wykonanie nieautoryzowanego kodu poza chronionym środowiskiem,
- poprawki uwzględniono w Cursor 3.0.
Kontekst / historia
Rozwój środowisk programistycznych wspieranych przez AI zmienia model pracy zespołów developerskich. Narzędzia tego typu coraz częściej analizują repozytoria, generują kod, modyfikują pliki i wykonują polecenia terminalowe w imieniu użytkownika. Taka automatyzacja przyspiesza pracę, ale jednocześnie zwiększa powierzchnię ataku i uzależnia bezpieczeństwo od odporności agenta AI na manipulację wejściem.
W przypadku Cursor problem dotyczył granicy pomiędzy katalogiem projektu, sandboxem i systemem operacyjnym hosta. Jeśli AI może zostać nakłonione do operacji wykraczających poza zakładany zakres pracy, nawet legalne funkcje IDE mogą zostać wykorzystane jako mechanizm eskalacji ataku. Podatności zgłoszono producentowi w lutym 2026 roku, a poprawki trafiły do wydania Cursor 3.0 opublikowanego 2 kwietnia 2026 roku.
Analiza techniczna
Pierwsza podatność dotyczyła sposobu obsługi parametru working_directory oraz granic bezpieczeństwa sandboxa. Mechanizm miał ograniczać wykonywanie poleceń do bieżącego katalogu roboczego projektu, jednak ustawienie niestandardowej wartości powodowało dodanie wskazanej ścieżki do listy lokalizacji uznawanych za dozwolone. W praktyce umożliwiało to skierowanie agenta AI do katalogu kontrolowanego przez atakującego poza zakresem projektu.
Taki scenariusz otwierał drogę do nadpisania pliku wykonywalnego odpowiedzialnego za sandboxing. Po podmianie tego komponentu kolejne polecenia mogły być realizowane już bez oczekiwanych ograniczeń izolacyjnych. To szczególnie niebezpieczny model ataku, ponieważ przełamanie ochrony następuje w ramach zaufanego przepływu pracy IDE, a nie przez klasyczne uruchomienie zewnętrznego malware.
Druga podatność była niezależna i dotyczyła walidacji ścieżek plików oraz obsługi dowiązań symbolicznych. Mechanizm ochronny miał blokować zapis poza katalogiem projektu, lecz logikę kanonikalizacji ścieżek można było obejść przy użyciu odpowiednio przygotowanego symlinku. W takim scenariuszu Cursor błędnie traktował operację jako bezpieczną, mimo że rzeczywisty cel dowiązania znajdował się poza dozwolonym obszarem.
W rezultacie także ta ścieżka mogła zostać użyta do wskazania pliku odpowiedzialnego za sandbox i jego nadpisania. Obie luki prowadziły więc do wspólnego rezultatu: eskalacji z manipulacji działaniem agenta AI do zdalnego wykonania kodu na poziomie systemu operacyjnego.
Konsekwencje / ryzyko
Ryzyko dla organizacji jest wysokie, ponieważ podatności dotyczą narzędzia instalowanego bezpośrednio na stacjach roboczych programistów. Takie środowiska często mają dostęp do kodu źródłowego, sekretów środowiskowych, tokenów API, kluczy SSH oraz danych uwierzytelniających do systemów CI/CD.
Skuteczne wykorzystanie luk może prowadzić do:
- kradzieży danych i poświadczeń,
- modyfikacji repozytoriów kodu,
- osadzenia backdoora w projektach,
- manipulacji artefaktami buildów,
- dalszego ruchu bocznego w infrastrukturze organizacji.
Dodatkowym wyzwaniem jest charakter ataku opartego na prompt injection. Użytkownik nie musi uruchamiać klasycznego złośliwego pliku, ponieważ wystarczy przetworzenie odpowiednio przygotowanej treści przez IDE. To sprawia, że złośliwe działania mogą przypominać legalne operacje wykonywane przez narzędzie developerskie, co utrudnia wykrywanie incydentu.
Rekomendacje
Organizacje korzystające z Cursor powinny w pierwszej kolejności potwierdzić wdrożenie wersji 3.0 lub nowszej na wszystkich stacjach roboczych. Warto również przeprowadzić inwentaryzację narzędzi AI używanych przez zespoły developerskie i ustalić, które z nich posiadają funkcje wykonywania poleceń oraz automatycznej modyfikacji plików.
- ograniczyć lokalne uprawnienia środowisk developerskich,
- oddzielić pracę nad kodem od poświadczeń uprzywilejowanych,
- monitorować nietypowe zmiany w plikach wykonywalnych narzędzi developerskich przy użyciu EDR lub XDR,
- blokować nieautoryzowane operacje na symlinkach i wrażliwych ścieżkach systemowych,
- śledzić procesy uruchamiane przez IDE i agentów AI,
- wdrożyć zasady zero trust wobec narzędzi wspierających kodowanie,
- szkolić zespoły w zakresie prompt injection oraz ryzyk związanych z agentami AI.
W środowiskach o podwyższonych wymaganiach bezpieczeństwa zasadne może być uruchamianie narzędzi AI w odseparowanych środowiskach roboczych, takich jak maszyny wirtualne lub kontenery z dodatkowymi kontrolami dostępu. Dobrą praktyką pozostaje również ograniczenie automatycznego wykonywania poleceń bez jednoznacznej akceptacji użytkownika.
Podsumowanie
Przypadek DuneSlide pokazuje, że bezpieczeństwo narzędzi AI dla programistów musi być oceniane szerzej niż tylko przez pryzmat jakości generowanego kodu. Kluczowe stają się odporność na prompt injection, poprawna walidacja ścieżek oraz skuteczność mechanizmów sandboxingu.
Luki wykryte w Cursor potwierdzają, że agent AI z dostępem do terminala i systemu plików może stać się celem o wysokiej wartości dla napastników. Dla zespołów bezpieczeństwa oznacza to konieczność traktowania AI IDE jako krytycznego elementu ochrony stacji developerskich i całego łańcucha dostaw oprogramowania.