Wprowadzenie do problemu / definicja
Rosnąca popularność narzędzi AI wspierających programistów zwiększa również znaczenie nowych klas zagrożeń. Jednym z nich jest indirect prompt injection, czyli pośrednie wstrzykiwanie poleceń do modelu lub agenta AI dzięki treści kontrolowanych przez atakującego, takich jak pliki repozytorium, dokumentacja czy README.
Przypadek dotyczący edytora Cursor pokazuje, iż połączenie tej techniki z obejściem mechanizmów ochronnych oraz nadużyciem funkcji zdalnego tunelowania mogło doprowadzić do pełnego przejęcia stacji roboczej dewelopera.
W skrócie
Badacze opisali łańcuch ataku nazwany NomShub, który miał umożliwiać kompromitację maszyny dewelopera już po otwarciu złośliwego repozytorium w Cursor. Scenariusz zakładał ukrycie instrukcji w plikach projektu, nakłonienie agenta AI do ich wykonania, obejście ograniczeń powłoki i wykorzystanie funkcji remote tunnel do uzyskania zdalnego dostępu.
Problem został zgłoszony na początku lutego 2026 roku, a poprawka została uwzględniona w Cursor 3.0. Sprawa podkreśla, iż agenci AI działający lokalnie powinni być traktowani jak komponenty uprzywilejowane.
Kontekst / historia
Narzędzia klasy AI coding assistant coraz częściej nie ograniczają się do generowania podpowiedzi kodu. W praktyce działają jako agenci zdolni do odczytu plików projektu, uruchamiania terminala, wykonywania komend czy integrowania się z usługami zewnętrznymi.
Taki model pracy zwiększa powierzchnię ataku. Treści znajdujące się w repozytorium, dokumentacji lub komentarzach mogą zostać potraktowane przez agenta jako instrukcje operacyjne. W opisywanym przypadku wystarczające mogło być samo otwarcie przygotowanego przez napastnika repozytorium, aby uruchomić kolejne etapy ataku.
Szczególnie groźne było zestawienie automatyzacji działań AI z dostępem do lokalnego systemu operacyjnego oraz funkcją zdalnego tunelu. To właśnie ten łańcuch zależności sprawił, iż luka mogła prowadzić nie tylko do jednorazowego wykonania poleceń, ale też do trwałego i zdalnego dostępu do środowiska pracy ofiary.
Analiza techniczna
Pierwszym elementem łańcucha była pośrednia prompt injection osadzona w zawartości repozytorium, między innymi w pliku README. Po otwarciu projektu agent AI analizujący pliki mógł potraktować ukryte instrukcje jako polecenia, które należy wykonać.
Drugim etapem było obejście zabezpieczeń związanych z wykonywaniem komend powłoki. Według opisu badaczy mechanizmy ochronne miały koncentrować się na typowych poleceniach uruchamianych przez agenta, ale nie obejmowały w wystarczającym stopniu shell builtins. To mogło pozwalać na manipulację katalogiem roboczym, zmiennymi środowiskowymi oraz kontekstem uruchomienia powłoki.
Na macOS dodatkowe znaczenie miał model sandboxingu. Wskazano możliwość zapisu do katalogu domowego użytkownika i nadpisania pliku .zshenv. Ponieważ plik ten jest wykonywany przy uruchamianiu nowych instancji powłoki Zsh, atakujący mógł w ten sposób uzyskać mechanizm trwałego wykonywania własnych instrukcji w kolejnych sesjach terminala i procesach uruchamianych przez aplikacje.
Trzeci etap dotyczył funkcji zdalnego tunelu dostępnej w Cursor. Agent miał wygenerować kod urządzenia i przekazać go na serwer kontrolowany przez napastnika. Po autoryzacji sesji powiązanej z kontem GitHub atakujący mógł uzyskać dostęp do tunelu ofiary, a w praktyce także do zdalnej powłoki i utrzymania dostępu tak długo, jak długo tunel pozostawał aktywny.
Z perspektywy detekcji istotne było również to, iż ruch sieciowy związany z tunelem przechodził przez legalną infrastrukturę chmurową. To utrudnia wykrywanie incydentu wyłącznie na podstawie anomalii w ruchu sieciowym.
Konsekwencje / ryzyko
Najpoważniejszym skutkiem takiego scenariusza jest przejęcie stacji deweloperskiej bez konieczności manualnego uruchamiania klasycznego malware przez użytkownika. W środowiskach inżynierskich oznacza to ryzyko dostępu do kodu źródłowego, sekretów zapisanych w plikach konfiguracyjnych, kluczy API, tokenów chmurowych, danych sesyjnych oraz systemów CI/CD.
Kompromitacja pojedynczej maszyny dewelopera może również stać się punktem wejścia do ataku na łańcuch dostaw oprogramowania. Uzyskanie dostępu do repozytoriów, pipeline’ów buildów lub systemów podpisywania artefaktów otwiera drogę do dalszej eskalacji wpływu na organizację.
Problem ma ponadto szerszy wymiar. Nie dotyczy wyłącznie pojedynczej implementacji, ale całej klasy zagrożeń związanych z agentami AI, które jednocześnie interpretują nieufne dane wejściowe i posiadają możliwość wykonywania działań w systemie operacyjnym.
Rekomendacje
Organizacje korzystające z narzędzi AI dla programistów powinny przede wszystkim upewnić się, iż używają wersji zawierającej poprawki bezpieczeństwa, w tym przypadku co najmniej Cursor 3.0. Sam update nie rozwiązuje jednak problemu systemowo, dlatego konieczne są także dodatkowe zabezpieczenia organizacyjne i techniczne.
- Traktować pliki README, dokumentację i prompty w repozytoriach jako dane nieufne.
- Ograniczać uprawnienia agentów AI do niezbędnego minimum.
- Stosować izolowane środowiska robocze i restrykcyjny sandbox.
- Monitorować zmiany w plikach inicjalizacyjnych powłoki, takich jak .zshenv czy .bashrc.
- Ograniczyć lub wyłączyć funkcje zdalnego tunelowania tam, gdzie nie są konieczne.
- Wymuszać dodatkową autoryzację dla działań wysokiego ryzyka wykonywanych przez agenta.
- Segmentować środowiska deweloperskie i separować poświadczenia od codziennej stacji roboczej.
- Logować i korelować aktywność agentów AI z działaniami w systemie operacyjnym.
- Szkolić zespoły z zakresu prompt injection i ryzyk supply chain.
Dobrą praktyką jest również uruchamianie narzędzi AI na dedykowanych, krótkotrwałych środowiskach roboczych zamiast na głównej stacji dewelopera. Ogranicza to skutki ewentualnej kompromitacji i utrudnia napastnikowi utrzymanie trwałości.
Podsumowanie
Incydent związany z Cursor AI pokazuje, iż bezpieczeństwa agentów kodujących nie można oceniać wyłącznie przez pryzmat jakości modelu czy klasycznych luk aplikacyjnych. najważniejsze jest zrozumienie całego łańcucha zaufania: od treści repozytorium, przez interpretację instrukcji przez AI, po lokalne wykonanie poleceń i integracje z funkcjami zdalnego dostępu.
Połączenie indirect prompt injection, obejścia mechanizmów ochronnych powłoki i nadużycia legalnej funkcji tunelowania stworzyło scenariusz o wysokim potencjale operacyjnym dla atakującego. Dla zespołów bezpieczeństwa to wyraźny sygnał, iż narzędzia AI dla deweloperów wymagają takich samych rygorów kontroli jak inne uprzywilejowane komponenty środowiska IT.
