Krytyczne luki w Cursor umożliwiają obejście sandboxa i wykonywanie poleceń przez prompt injection - Security Bez Tabu

Krytyczne luki w Cursor umożliwiają obejście sandboxa i wykonywanie poleceń przez prompt injection

Cybersecurity news

Wprowadzenie do problemu / definicja

W narzędziach programistycznych wspieranych przez AI bezpieczeństwo coraz częściej zależy nie tylko od jakości kodu, ale również od sposobu, w jaki agent interpretuje i wykonuje polecenia. Najnowszy przypadek dotyczy edytora Cursor, w którym ujawniono dwie krytyczne podatności pozwalające obejść mechanizmy sandboxingu i doprowadzić do uruchamiania poleceń poza zakładanym obszarem izolacji.

W praktyce oznacza to, że złośliwa treść dostarczona agentowi AI, na przykład przez repozytorium, dokumentację lub wynik wyszukiwania, może zostać wykorzystana do przejęcia kontroli nad operacjami wykonywanymi lokalnie na stacji roboczej dewelopera.

W skrócie

  • Ujawniono dwie krytyczne luki: CVE-2026-50548 i CVE-2026-50549.
  • Podatności dotyczą wersji Cursor wcześniejszych niż 3.0.
  • Obie luki umożliwiają zapis plików poza dozwolonym workspace, a następnie obejście lub wyłączenie ochrony sandboxa.
  • Scenariusz ataku może zostać uruchomiony w toku standardowej pracy z agentem AI, bez dodatkowych, podejrzanych działań użytkownika.
  • Producent udostępnił poprawki w wersji Cursor 3.0.

Kontekst / historia

Cursor od pewnego czasu pozostaje ważnym przykładem szerszego problemu bezpieczeństwa narzędzi AI dla programistów. Wcześniejsze badania pokazywały już, że prompt injection może wpływać na decyzje agenta, modyfikować jego zachowanie oraz prowadzić do wykonywania nieautoryzowanych akcji w środowisku lokalnym.

W odpowiedzi na tego rodzaju ryzyko w linii 2.x wdrożono domyślny sandbox dla poleceń terminalowych generowanych przez agenta. Nowe ustalenia pokazują jednak, że sama izolacja nie wystarcza, jeśli mechanizm przyznawania dostępu do plików lub walidacja ścieżek może zostać pośrednio zmanipulowana. Podatności zostały publicznie opisane 1 lipca 2026 r., natomiast poprawiona wersja 3.0 była dostępna już od 2 kwietnia 2026 r.

Analiza techniczna

Pierwsza podatność, CVE-2026-50548, dotyczy parametru working_directory używanego podczas wykonywania poleceń terminalowych. Mechanizm sandboxa przyznawał prawo zapisu do katalogu roboczego wskazanego dla danej operacji. Problem polegał na tym, że agent mógł wpłynąć na wartość tego parametru i skierować zapis poza właściwy katalog projektu.

W efekcie możliwe stawało się uzyskanie dostępu do wrażliwych lokalizacji systemowych lub plików startowych użytkownika. To z kolei otwierało drogę do nadpisania komponentu pomocniczego odpowiedzialnego za izolację i uruchamiania kolejnych komend już poza sandboxem.

Druga luka, CVE-2026-50549, wynikała z nieprawidłowej obsługi dowiązań symbolicznych oraz błędów w kanonikalizacji ścieżek. Aplikacja miała sprawdzać, czy rzeczywisty cel zapisu znajduje się w obrębie projektu, jednak w określonych warunkach błędnie ufała ścieżce wyglądającej na bezpieczną. Atakujący mógł więc przygotować dowiązanie symboliczne prowadzące poza workspace i wymusić zapis do dowolnej lokalizacji.

W obu scenariuszach łańcuch ataku wygląda podobnie. Agent otrzymuje złośliwe instrukcje ukryte w zewnętrznej treści, wykonuje operację zapisu poza zamierzonym obszarem, a następnie umożliwia uruchamianie dalszych poleceń z uprawnieniami bieżącego użytkownika systemu.

Konsekwencje / ryzyko

Skala zagrożenia jest szczególnie duża, ponieważ podatności dotyczą środowiska deweloperskiego, które zwykle ma dostęp do kodu źródłowego, sekretów, tokenów API, kluczy SSH, narzędzi CI/CD oraz zasobów chmurowych. Udane wykorzystanie luk może prowadzić do pełnego kompromitowania stanowiska pracy programisty.

  • wykonanie dowolnego kodu na lokalnej stacji roboczej,
  • kradzież poświadczeń i innych danych uwierzytelniających,
  • przejęcie dostępu do usług SaaS i środowisk chmurowych,
  • modyfikacja kodu źródłowego lub pipeline’ów budowania,
  • dalszy ruch boczny w organizacji z użyciem skompromitowanego konta deweloperskiego.

Szczególnie groźny jest niemal bezklikowy charakter ataku. Użytkownik nie musi ręcznie uruchamiać podejrzanego skryptu ani pobierać typowego malware. Wystarczy, że agent AI odczyta odpowiednio spreparowaną treść i podejmie działania w ramach normalnego workflow.

Rekomendacje

Najważniejszym krokiem jest natychmiastowa weryfikacja używanej wersji Cursor i aktualizacja wszystkich instalacji do co najmniej wersji 3.0. To jednak tylko pierwszy etap ograniczania ryzyka.

  • ograniczyć użycie agentów AI w środowiskach z dostępem do produkcyjnych sekretów i krytycznych zasobów,
  • oddzielić środowiska deweloperskie od kont uprzywilejowanych i stałych poświadczeń chmurowych,
  • monitorować próby zapisu poza workspace oraz modyfikacje plików startowych powłoki,
  • ściśle kontrolować integracje MCP i inne zewnętrzne źródła kontekstu dla agentów,
  • traktować wszystkie dane pobierane przez agentów jako niezaufane wejście,
  • wdrożyć EDR oraz dokładne logowanie zdarzeń na stacjach deweloperskich,
  • segmentować uprawnienia tokenów używanych przez narzędzia AI i skracać czas życia poświadczeń,
  • zaktualizować modele zagrożeń o prompt injection, path traversal, symlink abuse i sandbox escape.

Dobrym uzupełnieniem ochrony będzie uruchamianie agentów AI w dodatkowo izolowanych środowiskach, takich jak maszyny wirtualne, kontenery deweloperskie lub dedykowane hosty z ograniczonym dostępem do zasobów firmowych.

Podsumowanie

Przypadek luk CVE-2026-50548 i CVE-2026-50549 pokazuje, że pojedyncza warstwa ochrony, nawet w postaci domyślnego sandboxa, nie gwarantuje bezpieczeństwa agentów AI. Jeśli agent może pośrednio wpływać na ścieżki zapisu, walidację plików lub przyznawane uprawnienia, izolacja szybko przestaje spełniać swoją funkcję.

Dla zespołów bezpieczeństwa i DevSecOps to wyraźny sygnał, że narzędzia AI dla programistów należy traktować tak samo rygorystycznie jak komponenty wykonujące kod i obsługujące poświadczenia. W praktyce kluczowe pozostają szybkie aktualizacje, ograniczone zaufanie do danych wejściowych oraz dodatkowa izolacja środowisk pracy.

Źródła

  • https://thehackernews.com/2026/07/critical-cursor-flaws-could-let-prompt.html
  • https://github.com/cursor/cursor/security/advisories/GHSA-3p48-7v9f-v5cw
  • https://nvd.nist.gov/vuln/detail/CVE-2026-50548
  • https://nvd.nist.gov/vuln/detail/CVE-2026-50549
  • https://www.catonetworks.com/blog/curxecute-rce/