Jak środowisko Cursor pozwalało na uruchomienie złośliwego kodu – CVE-2025-54136

Nie da się ukryć, że LLMy na stałe wpisały się w krajobraz naszej rzeczywistości. Dodatkowo, szczególną rolę, odgrywają w świecie IT, gdzie stają się nieodzownym elementem narzędzi, np. środowisk programistycznych. Generowanie kodu, podpowiadanie składni, przygotowanie dokumentacji czy także także dodatkowe funkcjonalności dostępne dzięki rozwiązaniu Model Context Protocol, o którym już nie raz wspominaliśmy. 

TLDR:

• Popularne IDE oparte na Microsoft Visual Studio Code – Cursor – pozwala na konfigurację MCP w plikach projektu.
• Każdorazowe dodanie MCP wymaga zgody użytkownika. 
• Jednak po akceptacji konfiguracji, kolejne zmiany są już przeźroczyste dla developera.

Popularne IDE na bazie MS Visual Studio Code – Cursor zyskał wielu użytkowników, dzięki wygodnej integracji dużych modeli językowych z workflow programistycznym. Model podpowiada składnię (z naszych eksperymentów wynika, że całkiem skutecznie jeśli chodzi o prosty kod szablonowy/snippety) i pozwala zwiększyć produktywność (chociaż akurat ten współczynnik jest dyskutowany w środowisku naukowym, my tylko przypominamy, że czas zaoszczędzony na generowaniu kodu przez AI powinien zostać wykorzystany na jego analizę pod kątem bezpieczeństwa przez naturalną inteligencję), a już na pewno poprawia szybkość implementacji kolejnych funkcjonalności. 

Dodatkowe funkcje tego IDE mogą zostać rozbudowane przy pomocy MCP. Konfigurację dodatkowych usług można przeprowadzić przy pomocy modyfikacji pliku mcp.json w katalogu .cursor/, który znajduje się wewnątrz każdego projektu edytowanego przy pomocy tego środowiska programistycznego. Narzędzia mogą być też dodane przy pomocy tzw. deeplinków (czyli takich URL, które są otwierane bezpośrednio w IDE – tutaj fanom vima i tego drugiego gorszego edytora na “e” przypominamy, że VS Code to tak naprawdę przeglądarka internetowa udająca IDE).

W momencie dodania nowego MCP do konfiguracji projektu, użytkownik proszony jest o akceptację nowo dodanej funkcjonalności przy pomocy popupu. 

Jak słusznie zauważyli badacze z Checkpoint Research, akceptacja użytkownika wymagana jest tylko jednokrotnie, w momencie wykrycia konfiguracji w katalogu projektu (np. w wyniku synchronizacji z repozytorium). 

Jeśli użytkownik wyrazi zgodę na wykorzystanie “demo plugin”, to będzie ona ważna, nawet jeśli w wywoływaniu tej funkcjonalności zajdą zmiany. W szczególności wtedy, kiedy zmieni się komenda, np na taką złośliwą.

Atakujący podmieniając pierwotną konfigurację na inną, uzyska zdalne wykonanie kodu, jeśli dana wtyczka została wcześniej zaakceptowana przez programistę. 

Badacze przedstawili krótki filmik pokazujący cały atak:

Atak jest trywialny do przeprowadzenia oraz prawdopodobny, zwłaszcza we wskazanym przykładzie pracy zespołowej, gdy katalog .cursor/ jest synchronizowany przy pomocy systemu kontroli wersji. Synchronizacja z repozytorium, np. git może dać atakującemu wygodną metodę na aktualizację wywoływanych poleceń, które będą wykonywane np. za każdym razem gdy użytkownik uruchomi edytor. To pozwala osiągnąć nie tylko zdalne wykonanie kodu, ale też utrzymać dostęp do systemu na dłużej (ang. persistence). 

Mimo prostoty wykonywanego ataku, należy wskazać, że łamie on kluczowe ramy zaufania wobec konfiguracji środowiska programistycznego. Luka została załatana w wersji 1.3, dlatego zachęcamy wszystkich użytkowników do aktualizacji. Przy okazji sugerujemy zastanowić się czy pliki konfiguracyjne projektu, zwłaszcza dotyczące uruchamianych poleceń systemowych powinny być synchronizowane w repozytorium? Może lepiej dopisać tę jedną linijkę do .gitignore i ręcznie wprowadzać zmiany? 

~Black Hat Logan