Spis treści
Elad Meged z Novee Security kilka dni temu był badaczem który znalazł krytyczną podatność w Gemini CLI — tę samą o której pisaliśmy przy okazji łatki Google. Ten sam badacz, ten sam tydzień, inne narzędzie AI do kodowania: tym razem Cursor.
CVE-2026-26268. CVSS 9.9 według NVD. Zdalne wykonanie kodu na maszynie dewelopera — bez żadnej interakcji, bez żadnego ostrzeżenia, przez sklonowanie repozytorium.
Łatka była gotowa w lutym 2026. Szczegóły opublikowane 28 kwietnia. Jeśli używasz Cursor w wersji starszej niż 2.5 — czas na aktualizację.
Dlaczego to nie jest zwykła podatność w IDE
Assaf Levkovich z Novee Security, który prowadził badania, ujmuje sedno problemu w jednym zdaniu: "Pierwotna przyczyna to nie błąd w podstawowej logice produktu Cursor, ale konsekwencja interakcji między funkcjami Git — która staje się eksploitowalna w momencie gdy agent AI zaczyna autonomicznie wykonywać operacje Git wewnątrz repozytorium, którego nie kontroluje."
To jest zdanie, które warto czytać uważnie, bo opisuje nową klasę podatności — nie w kodzie konkretnego narzędzia, ale w tym jak autonomiczne zachowanie agenta AI zmienia model zagrożeń dla dobrze znanych mechanizmów.
Git hooks to skrypty uruchamiane automatycznie przy określonych zdarzeniach systemu kontroli wersji — commitach, checkoutach, mergach. Są częścią Git od początku jego istnienia. Są powszechnie używane do automatyzacji powtarzalnych kroków w procesie deweloperskim. Sam w sobie Git hook nie jest zagrożeniem — uruchamia się gdy programista świadomie wykona operację Git.
Bare repositories to repozytoria zawierające wyłącznie dane kontroli wersji bez katalogu roboczego. Mogą być zagnieżdżone wewnątrz większego repozytorium.
Żadne z tych dwóch zachowań samo w sobie nie jest podatnością. Staje się podatnością gdy agent AI autonomicznie decyduje o wykonaniu operacji Git — bo wtedy programista nie wykonuje operacji. Wykonuje ją agent.
Jak działa atak
Scenariusz jest prosty do wykonania i trudny do wykrycia.
Atakujący tworzy pozornie legitymizowane repozytorium publiczne. Wewnątrz zagnieżdża bare repository — ukryty folder zawierający tylko dane kontroli wersji, niewidoczny w standardowym widoku struktury projektu. Wewnątrz tego bare repository umieszcza złośliwy skrypt jako pre-commit hook.
Deweloper klonuje repozytorium. Otwiera je w Cursor i wydaje wysokopoziomowe polecenie: "przejrzyj ten kod", "zrób checkout tej gałęzi", "przygotuj środowisko deweloperskie". Agent AI interpretuje polecenie i autonomicznie wykonuje operację git checkout jako część realizacji zadania.
W momencie wykonania git checkout Git automatycznie uruchamia pre-commit hook. Złośliwy skrypt wykonuje się na maszynie dewelopera z jego uprawnieniami. Bez ostrzeżenia. Bez prośby o potwierdzenie. Cursor wykonał to co agent uznał za właściwy krok do realizacji polecenia.
Wersja z wstrzyknięciem monitu jest jeszcze subtelniejsza: atakujący może użyć prompt injection w treści pliku w repozytorium żeby nakłonić agenta do zapisania złośliwej konfiguracji Git — a następnie wyzwolić jej wykonanie przy następnej operacji Git. Agent który potrafi pisać do plików konfiguracyjnych .git bez odpowiednich ograniczeń może samodzielnie przygotować grunt pod własne skompromitowanie.
SentinelOne klasyfikuje podatność jako CWE-862 — brak autoryzacji: aplikacja nie ograniczała prawidłowo dostępu do zapisu wrażliwych plików konfiguracyjnych .gitwewnątrz swojego środowiska izolowanego.
Ten sam badacz, ten sam tydzień, ta sama klasa
Zbieżność jest warta podkreślenia. Elad Meged jest głównym badaczem zarówno CVE-2026-26268 w Cursor jak i GHSA-wpqr-6v78-jr5g w Gemini CLI. Oba zostały ujawnione w tym samym tygodniu.
Oba opisują tę samą klasę podatności z różnych stron: agent AI w środowisku deweloperskim przetwarza niezaufane wejście i podejmuje autonomiczne działania — wykonując operacje których skutki są szersze niż intencja użytkownika.
W Gemini CLI niezaufanym wejściem był pull request od zewnętrznego kontrybutora w potoku CI/CD. Agent wykonywał polecenia systemowe przez tryb --yolo bez wymuszania list dozwolonych. W Cursor niezaufanym wejściem jest sklonowane repozytorium. Agent wykonuje operacje Git bez weryfikacji że zahaczone skrypty są bezpieczne.
Oba przypadki łączy jeden wniosek Novee Security: "Założenie jest takie, że narzędzia których deweloperzy używają do budowania oprogramowania są same w sobie bezpieczne. To założenie warte jest ponownego przemyślenia — szczególnie gdy te narzędzia są agentami AI operującymi autonomicznie wewnątrz środowiska dewelopera na kodzie z dowolnego źródła w internecie."
Łańcuch z całego miesiąca
Pisaliśmy o Comment and Control — złośliwe instrukcje w tytułach zgłoszeń na GitHubie wykonywane przez Claude Code, Gemini CLI i GitHub Copilot. Tam niezaufanym wejściem była treść platformy współpracy. Agent wykonywał polecenia bo przetwarzał tę treść jako część kontekstu zadania.
Pisaliśmy o Shai-Hulud — kampanii TeamPCP zatruającej Claude Code, Gemini CLI, Cursor i inne narzędzia AI do kodowania przez wstrzyknięcie kodu do plików startowych terminala. Tam wektor był przez zatrute narzędzie DevSecOps w łańcuchu dostaw.
CVE-2026-26268 dodaje trzeci wektor do tej samej rodziny: nie przez platformę współpracy, nie przez łańcuch dostaw, przez samo repozytorium kodu. Deweloper klonuje projekt z GitHuba — i to wystarczy.
Trzy różne punkty wejścia do tego samego celu: maszyny dewelopera ze wszystkimi kluczami dostępowymi do infrastruktury organizacji.
Maszyna dewelopera jako cel sam w sobie
Jest strukturalny wzorzec który łączy CVE-2026-26268 z wcześniejszymi wpisami cyberflux z tego miesiąca i który warto wyartykułować wprost.
Pisaliśmy o Marimo, SGLang i LMDeploy — frameworkach AI serwujących modele jako atakowane cele, bo mają dostęp do kluczy chmurowych i danych uwierzytelniających. Tam cel był w infrastrukturze produkcyjnej.
Maszyna dewelopera jest celem z innego powodu, ale równie wartościowym: kod źródłowy, klucze API do usług których używa projekt, tokeny dostępu do repozytoriów, poświadczenia do środowisk staging i produkcyjnych, klucze SSH do serwerów. Kompromitacja stacji roboczej jednego dewelopera to potencjalnie wejście do całej infrastruktury którą buduje i utrzymuje.
Przy Vercel przez Context.ai widzieliśmy jak jedna zainfekowana maszyna pracownika firmy zewnętrznej stała się mostem do infrastruktury Vercel. CVE-2026-26268 pokazuje że ten sam efekt można osiągnąć przez sklonowanie repozytorium — bez żadnej innej interakcji.
Novee ujmuje konsekwencję wprost: "Tradycyjne praktyki bezpieczeństwa koncentrują się na zewnętrznych powierzchniach ataku — API, przepływach uwierzytelnienia, wejściach użytkownika. CVE-2026-26268 pokazuje dlaczego to musi się zmienić: środowisko deweloperskie rzadko jest traktowane jako potencjalna powierzchnia ataku."
Autonomia jako mnożnik ryzyka
Jest jeszcze jedna warstwa tej historii którą warto wyciągnąć jako osobną obserwację.
Levkovich z Novee opisuje zmianę modelu: "Tradycyjne użycie IDE jest w dużej mierze pasywne. Deweloperzy otwierają repozytoria, czytają i piszą kod, ręcznie wykonują polecenia. IDE po prostu wykonuje instrukcje. Agent AI Cursora fundamentalnie zmienia ten model. Agent interpretuje wysokopoziomowy monit użytkownika i autonomicznie decyduje które operacje wykonać — włącznie z operacjami Git."
To jest precyzyjna diagnoza dlaczego ta klasa podatności jest nowa mimo że Git hooks istnieją od lat. Git hooks nie były wektorem ataku w tradycyjnym IDE bo programista świadomie wykonywał operacje Git — i widział co robi. Agent AI wykonuje operacje Git jako efekt uboczny realizacji wysokopoziomowego zadania — i użytkownik nie ma widoczności na poziomie poszczególnych kroków które agent podejmuje.
Im agent jest bardziej autonomiczny — tym więcej operacji wykonuje bez świadomości użytkownika. Każda z tych operacji jest potencjalnym wektorem jeśli wejście do agenta pochodzi z niezaufanego źródła.
Levkovich dodaje: "Gdy agent wykonuje git checkout jako część realizacji rutynowego żądania, nie robi niczego czego użytkownik nie autoryzował niejawnie. Ale skutki tego działania mogą wykraczać daleko poza intencję użytkownika."
To jest dokładnie ten sam wzorzec który opisywaliśmy przy raporcie OX Security o STDIO w MCP — agent działający w dobrej wierze, wykonujący operacje które są "oczekiwanym zachowaniem", produkujący skutki których nikt nie przewidział.
Co zrobić
Aktualizacja Cursor do wersji 2.5 lub nowszej eliminuje podatność. Łatka ogranicza możliwość zapisu do chronionych plików konfiguracyjnych .git wewnątrz środowiska izolowanego agenta — Git hooks z zewnętrznych repozytoriów nie mogą być już automatycznie wykonywane przez agenta.
Dla organizacji gdzie deweloperzy używają Cursor do pracy z publicznymi repozytoriami: weryfikacja że wszyscy używają zaktualizowanej wersji jest krokiem pierwszym. Wersja produktu jest widoczna w menu Help → About Cursor.
Szersza rekomendacja Novee: audyt narzędzi AI do kodowania pod kątem tego jak obsługują niezaufane wejście — nie tylko przez weryfikację wewnętrznego kodu narzędzia, ale przez analizę jakie operacje agent może wykonać autonomicznie i na jakich danych. To jest nowa kategoria przeglądu bezpieczeństwa której tradycyjne audyty nie obejmują.
Podsumowanie
CVE-2026-26268 w Cursor nie jest błędem w kodzie Cursor. Jest błędem w modelu zaufania: agent AI który autonomicznie wykonuje operacje Git zaufał repozytorium którego nie powinien ufać — i wykonał kod którego nie powinien wykonać.
Ten sam badacz, ten sam tydzień, ta sama klasa: Gemini CLI przez tryb --yolo i automatyczne zaufanie do przestrzeni roboczej. Cursor przez autonomiczne operacje Git i brak ograniczeń zapisu do konfiguracji. Comment and Control przez tytuły zgłoszeń i komentarze. Shai-Hulud przez zatrute narzędzia DevSecOps.
Wszystkie te podatności są odpowiedziami na to samo pytanie: co się dzieje gdy agent AI z uprawnieniami do wykonywania operacji na systemie dewelopera przetwarza wejście z niezaufanych źródeł?
Odpowiedź jest konsekwentna przez cały kwiecień 2026: atakujący dostaje dostęp do maszyny dewelopera i wszystkiego co na niej jest.
Źródła
Novee Security — pierwotny raport techniczny z opisem mechanizmu ataku i wnioskami: https://novee.security/blog/cursor-ide-cve-2026-26268-git-hook-arbitrary-code-execution/
CSO Online — analiza z komentarzem Assafa Levkovicha: https://www.csoonline.com/article/4164250/critical-cursor-bug-could-turn-routine-git-into-rce.html
Hackread — szczegóły techniczne i kontekst odpowiedzialnego ujawnienia: https://hackread.com/cursor-ai-ide-vulnerability-code-execution-git-hooks/
Cybersecurity News — mechanizm dwóch funkcji Git i scenariusz ataku: https://cybersecuritynews.com/cursor-ai-coding-agent-vulnerability/
SentinelOne — klasyfikacja CWE-862 i opis ucieczki z piaskownicy: https://www.sentinelone.com/vulnerability-database/cve-2026-26268/
