Złośliwa aktualizacja Claude Code w Cursor Marketplace: co ujawnia atak na łańcuch dostaw wtyczek AI i jak zabezpieczyć środowiska IDE w firmie

29 października 2026 r. między około 10:27 a 21:35 czasu lokalnego przez marketplace edytora Cursor dystrybuowana była zmodyfikowana wersja oficjalnego rozszerzenia Claude Code (2.1.313) wydawanego przez Anthropic. Pakiet trafił do użytkowników jako zwykła aktualizacja, pod prawdziwym wydawcą, i zawierał złośliwy kod. Według komunikatu Cursor incydent mógł dotknąć maksymalnie 5000 osób, które w tym oknie zainstalowały lub zaktualizowały wtyczkę. Firma usunęła wersję, odbudowała marketplace, wyłączyła serwer wykorzystywany przez atakujących i zapowiedziała bezpośredni kontakt z poszkodowanymi.

Sprawa jest ważna z dwóch powodów. Po pierwsze, pokazuje, że zaufanie do wydawcy i do mechanizmu automatycznych aktualizacji w marketplace IDE nie wystarcza, gdy zawodzi kontrola publikacji po stronie platformy. Po drugie, dotyczy narzędzi, które w polskich firmach IT coraz częściej mają dostęp do kodu źródłowego, konfiguracji projektów i zmiennych środowiskowych z poświadczeniami. Nie chodzi więc o egzotyczne zagrożenie z niszowego repozytorium, lecz o kanał dystrybucji, z którego deweloperzy korzystają rutynowo. Poniższa analiza opiera się na materiale dowodowym: relacji Sekuraka powołującej się na OpenSourceMalware, The Hacker News i komunikat Cursor. Czego te źródła nie potwierdzają, tego nie dopowiadamy.

Co dokładnie się wydarzyło

Złośliwa wersja 2.1.313 była dystrybuowana wyłącznie przez marketplace Cursor. Źródła nie potwierdzają, by ta sama zmodyfikowana paczka pojawiła się w Open VSX ani w Microsoft VS Code Marketplace. To rozróżnienie ma praktyczne znaczenie: organizacje, które korzystają z VS Code i instalują rozszerzenia z oficjalnego marketplace’u Microsoftu, nie mają podstaw — na podstawie dostępnego materiału — by uznawać się za dotknięte tym konkretnym incydentem. Nie oznacza to, że są wolne od ryzyka łańcucha dostaw w ogóle; oznacza wyłącznie, że ten wektor w tym przypadku ich nie dotyczył.

Cursor poinformował, że złośliwej wersji nie stworzył Anthropic, a incydent nie obejmuje innych rozszerzeń pobranych z marketplace Cursor ani pozostałych produktów firmy. Nie znamy sposobu, w jaki atakujący zdołali opublikować zmodyfikowany pakiet pod prawdziwym wydawcą. To luka w wiedzy, którą trzeba nazwać wprost: bez znajomości wektora wejścia nie da się ocenić, czy podobny scenariusz może się powtórzyć w tej samej formie.

Chronologia zdarzenia w punktach

• 29 października 2026, ok. 10:27–21:35 — okno dystrybucji złośliwej wersji 2.1.313 przez marketplace Cursor.
• Po wykryciu — Cursor tymczasowo zamyka marketplace i usuwa pakiet.
• Reakcja — odbudowa marketplace, rotacja kluczy po stronie Cursor, współpraca z dostawcą hostingu w celu wyłączenia serwera atakujących.
• Zalecenie — aktualizacja do wersji 2.1.314, usunięcie nieautoryzowanego klucza SSH i mechanizmów persystencji, rotacja poświadczeń w zmiennych środowiskowych.

Tło techniczne prostym językiem

Marketplace edytora to sklep z rozszerzeniami. Deweloper klika „zainstaluj” lub „aktualizuj”, a edytor pobiera paczkę od wydawcy i uruchamia jej kod w swoim procesie. Rozszerzenie ma zwykle szerokie uprawnienia: może czytać pliki projektu, wywoływać polecenia systemowe, otwierać widoki (webview) i korzystać ze zmiennych środowiskowych procesu. W praktyce oznacza to, że złośliwe rozszerzenie działa z uprawnieniami użytkownika, który je uruchomił.

W tym przypadku mechanizm był stosunkowo prosty. Przed prawidłowym kodem rozszerzenia wstawiono loader — 66 linii kodu. Po uruchomieniu VS Code i otwarciu webview wtyczki loader dopisywał do pliku ~/.ssh/authorized_keys klucz SSH kontrolowany przez atakujących, zapisany pod nazwą svc-telemetry. Nazwa sugeruje nieszkodliwy komponent telemetryczny, co utrudnia przypadkowe rozpoznanie. Następnie rozszerzenie próbowało ustanowić tunel zwrotny do adresu 134[.]209[.]82[.]225, wdrażało persystencję i wysyłało informacje o hoście na adres 134[.]209[.]82[.]225[:]8099/beacon zwykłym żądaniem HTTP.

Warto podkreślić ograniczenie, które sam Cursor wskazał: włączenie lokalnej usługi SSH wymaga uprawnień administratora, których złośliwe rozszerzenie nie ma na większości urządzeń z macOS i Windows. To istotny szczegół, ale nie unieważnia zagrożenia — zależy od konfiguracji hosta, sposobu uruchomienia edytora i tego, czy użytkownik pracuje na koncie z podniesionymi uprawnieniami. Bezpieczniej jest traktować ten mechanizm jako próbę, która mogła się powieść w części środowisk, niż jako nieszkodliwy epizod.

Jakie dane zbierał beacon

Żądanie na endpoint beacon zawierało: publiczny adres IP pobrany z api[.]ipify[.]org, nazwę hosta i lokalną nazwę użytkownika, system operacyjny i architekturę procesora, nazwę katalogu domowego i roboczego, adres e-mail z konfiguracji Git (git config --global user.email) oraz nazwy maksymalnie 40 zmiennych środowiskowych zawierających słowa KEY, TOKEN, SECRET, PASS, AWS lub GCP.

Kluczowe rozróżnienie: na tym etapie przesyłane były nazwy zmiennych, nie ich wartości. To znacząco ogranicza bezpośredni wyciek poświadczeń, ale nie czyni go zerowym. Same nazwy ujawniają, z jakich dostawców chmury i narzędzi CI korzysta ofiara, jakie konwencje nazewnicze stosuje i gdzie warto szukać dalszych wektorów. To materiał wywiadowczy, który ułatwia przygotowanie kolejnego etapu ataku — na przykład przez tunel SSH, jeśli udało się go ustanowić.

Realne konsekwencje i scenariusze ryzyka

Skala incydentu jest ograniczona: maksymalnie 5000 użytkowników, jedno okno czasowe, jeden marketplace. To nie jest masowa kampania. Ryzyko dla pojedynczej organizacji zależy jednak od tego, co znajdowało się na dotkniętym hoście i jak był skonfigurowany.

Scenariusz	Warunek wystąpienia	Potencjalny skutek
Dodanie klucza SSH	Loader wykonał się i miał prawo zapisu do ~/.ssh/authorized_keys	Trwały dostęp zdalny do hosta deweloperskiego
Ustanowienie tunelu zwrotnego	Dostępny lokalny demon SSH i brak blokady wyjścia	Kanał komunikacji omijający część kontroli sieciowych
Persystencja	Zapis do zadań zaplanowanych, crontab lub LaunchAgent	Ponowne uruchomienie mechanizmu po restarcie
Wyciek metadanych	Wykonanie beaconu	Ujawnienie struktury hosta, użytkowników i dostawców chmury
Wyciek poświadczeń	Nie potwierdzony w materiale na tym etapie	Nie zakładamy go bez dowodów, ale rotacja jest środkiem ostrożności

Największe ryzyko dotyczy hostów deweloperskich, które mają szeroki dostęp: do repozytoriów, do chmur, do systemów CI/CD i do sekretów w zmiennych środowiskowych. Taki host jest atrakcyjnym celem, bo z niego można przejść dalej — do kodu, do pipeline’u i do infrastruktury. Nawet jeśli w tym incydencie nie potwierdzono wycieku wartości sekretów, sam dostęp SSH do maszyny deweloperskiej byłby poważnym problemem.

Czego źródła nie potwierdzają

• Nie znamy wektora publikacji złośliwej wersji pod prawdziwym wydawcą.
• Nie wiadomo, ile osób faktycznie miało udany zapis klucza SSH lub udany tunel.
• Nie potwierdzono wycieku wartości zmiennych środowiskowych.
• Nie ma podstaw, by wiązać incydent z innymi rozszerzeniami Cursor lub innymi produktami.
• Nie ma dowodów na dystrybucję przez Open VSX lub Microsoft VS Code Marketplace.

Jak sprawdzić, czy problem dotyczy Twojej organizacji

Punktem wyjścia jest ustalenie, kto używa Cursor i czy w oknie 29 października 2026 r. instalował lub aktualizował rozszerzenie Claude Code. Warto sprawdzić to na poziomie centralnym, jeśli firma ma inwentaryzację oprogramowania, oraz lokalnie na hostach deweloperskich.

1. Ustal listę hostów z Cursor — na podstawie CMDB, agenta EDR, logów proxy lub inwentaryzacji oprogramowania.
2. Sprawdź wersję rozszerzenia Claude Code — interesuje Cię 2.1.313; wersja 2.1.314 i nowsze są zalecane przez Cursor.
3. Sprawdź ~/.ssh/authorized_keys — szukaj wpisu z komentarzem svc-telemetry lub innych nieznanych kluczy dodanych w tym okresie.
4. Sprawdź mechanizmy persystencji — zadania zaplanowane (Windows Task Scheduler), wpisy crontab, LaunchAgent na macOS.
5. Przejrzyj logi sieciowe — połączenia do 134[.]209[.]82[.]225, w tym port 8099 i ścieżka /beacon.
6. Sprawdź konfigurację Git — czy git config --global user.email jest zgodny z oczekiwanym.
7. Ustal, jakie zmienne środowiskowe zawierają słowa KEY, TOKEN, SECRET, PASS, AWS lub GCP na dotkniętych hostach.

Jeśli nie masz pewności, czy host był w oknie dystrybucji, traktuj go jako podejrzany do czasu potwierdzenia wersji rozszerzenia i braku wpisu svc-telemetry. Ostrożność jest tańsza niż analiza późniejszego incydentu.

Plan reakcji krok po kroku

Poniższa kolejność zakłada, że masz już listę potencjalnie dotkniętych hostów. Działań nie trzeba wykonywać w tej kolejności literalnie, ale izolacja i zabezpieczenie dowodów powinny wyprzedzać czyszczenie.

1. Odizoluj hosty — odłącz od sieci firmowej lub przenieś do segmentu kwarantanny, zachowując możliwość zdalnej analizy.
2. Zabezpiecz dowody — zrób kopię authorized_keys, wpisów persystencji, logów i listy procesów przed usuwaniem czegokolwiek.
3. Usuń nieautoryzowany klucz SSH — wpis svc-telemetry i inne nieznane klucze dodane w oknie incydentu.
4. Usuń mechanizmy persystencji — zaplanowane zadania, wpisy crontab, LaunchAgent powiązane z incydentem.
5. Zaktualizuj rozszerzenie — do wersji 2.1.314 lub nowszej, zgodnie z zaleceniem Cursor.
6. Zrotuj poświadczenia — wszystkie sekrety, których nazwy mogły zostać ujawnione, oraz te, do których dostęp miały procesy na hoście.
7. Przeanalizuj logi — połączenia wychodzące, logowania SSH, nietypowe procesy w oknie incydentu.
8. Uruchom skanowanie EDR — na wszystkich hostach deweloperskich, nie tylko na potwierdzonych.
9. Udokumentuj — zakres, działania, wnioski; to podstawa ewentualnych zgłoszeń i komunikacji wewnętrznej.

Typowe błędy w reakcji

• Skupienie się wyłącznie na usunięciu rozszerzenia. Sama aktualizacja do 2.1.314 nie usuwa klucza SSH ani persystencji.
• Pominięcie authorized_keys. To najbardziej bezpośredni ślad i najprostszy do przeoczenia, jeśli ktoś sprawdza tylko listę rozszerzeń.
• Rotacja tylko „oczywistych” sekretów. Nazwy zmiennych ujawniają dostawców i konwencje; rotacja powinna objąć wszystko, co mogło być widoczne.
• Traktowanie braku uprawnień administratora jako gwarancji bezpieczeństwa. To zależy od konfiguracji hosta i sposobu uruchomienia edytora.
• Brak analizy logów sieciowych. Bez niej nie wiadomo, czy beacon lub tunel w ogóle zadziałały.
• Pominięcie hostów zdalnych i maszyn w chmurze. Deweloperzy często pracują na maszynach wirtualnych i środowiskach zdalnych.

Działania krótkoterminowe

W ciągu najbliższych dni priorytetem jest ograniczenie ekspozycji. Warto rozważyć czasowe wstrzymanie automatycznych aktualizacji rozszerzeń w Cursor dla zespołów, które nie muszą ich mieć natychmiast, oraz wprowadzenie ręcznej akceptacji nowych wersji wtyczek o szerokich uprawnieniach. To nie jest rozwiązanie docelowe, ale daje czas na weryfikację.

Równolegle należy dokończyć inwentaryzację hostów, usunąć potwierdzone ślady i zrotować poświadczenia. Jeżeli w firmie działa zespół bezpieczeństwa, warto uruchomić krótki przegląd logów wychodzących z hostów deweloperskich za okno 29 października 2026 r. i kilka dni po nim — persystencja mogła zadziałać z opóźnieniem.

Działania długoterminowe

Incydent pokazuje, że marketplace IDE trzeba traktować jak kanał dostaw oprogramowania, a nie jak wygodny sklep. Oznacza to politykę aktualizacji: krótki odstęp między wydaniem a wdrożeniem, kontrolę wersji, możliwość cofnięcia i świadome zarządzanie rozszerzeniami o szerokich uprawnieniach. Nie chodzi o blokowanie aktualizacji, lecz o to, by nie były one natychmiastowe i niekontrolowane.

Drugi filar to segmentacja hostów deweloperskich. Maszyna, na której uruchamiane są wtyczki AI z dostępem do kodu i sekretów, nie powinna mieć nieograniczonego dostępu do produkcji. Trzeci — zarządzanie sekretami. Zmienne środowiskowe z poświadczeniami są wygodne, ale trudne do kontroli. Warto rozważyć dedykowane menedżery sekretów i krótkotrwałe poświadczenia, tak by nawet ujawnienie nazw nie prowadziło do łatwego dostępu.

Czwarty filar to monitoring. Bez logów wychodzących i alertów na nietypowe połączenia z hostów deweloperskich reakcja zawsze będzie spóźniona. Piąty — ćwiczenia z reakcji na incydent łańcucha dostaw, obejmujące scenariusz „zaufane rozszerzenie zostało zmodyfikowane”.

Checklista praktyczna

• Lista hostów z Cursor i wersjami rozszerzenia Claude Code.
• Weryfikacja ~/.ssh/authorized_keys pod kątem wpisu svc-telemetry.
• Przegląd zadań zaplanowanych, crontab i LaunchAgent.
• Analiza logów połączeń do 134[.]209[.]82[.]225 i portu 8099.
• Aktualizacja do 2.1.314 lub nowszej.
• Rotacja poświadczeń w zmiennych środowiskowych.
• Przegląd konfiguracji Git i adresów e-mail.
• Decyzja o czasowym wstrzymaniu automatycznych aktualizacji wtyczek.
• Ustalenie właściciela polityki rozszerzeń w IDE.
• Dokumentacja działań i wniosków.

Co powinien zrobić właściciel firmy / administrator

Właściciel firmy nie musi znać szczegółów technicznych, ale powinien zadać trzy pytania: czy wiemy, kto używa Cursor, czy mamy politykę aktualizacji rozszerzeń i czy hosty deweloperskie mają dostęp do tego, do czego nie powinny. Odpowiedzi na te pytania określają realne ryzyko — nie tylko dla tego incydentu, ale dla kolejnych.

Administrator powinien natomiast wykonać konkretne kroki: zinwentaryzować hosty, sprawdzić ślady, usunąć klucz i persystencję, zaktualizować rozszerzenie, zrotować sekrety i przeanalizować logi. Warto też ustalić, kto w organizacji odpowiada za zatwierdzanie rozszerzeń w IDE i jak szybko można wstrzymać aktualizacje, gdy pojawi się sygnał o problemie. Bez takiego właściciela każdy podobny incydent będzie reakcją ad hoc.

Na koniec kwestia komunikacji. Cursor zapowiedział bezpośredni kontakt z poszkodowanymi użytkownikami. Organizacja powinna mieć własny kanał informowania zespołu o tym, co się stało, jakie działania podjęto i czego oczekuje się od deweloperów. To ogranicza chaos i zapobiega samodzielnym, nieskoordynowanym próbom „naprawy”, które mogą zatrzeć dowody.

Incydent z 29 października 2026 r. nie jest dowodem na to, że wtyczki AI są z natury niebezpieczne. Jest dowodem na to, że zaufany wydawca i automatyczna aktualizacja to za mało, gdy zawodzi kontrola po stronie platformy. Dla polskich firm IT wnioski są praktyczne: wiedzieć, co jest zainstalowane, kontrolować tempo aktualizacji, segmentować hosty deweloperskie i zarządzać sekretami tak, by ich ujawnienie nie otwierało drogi do reszty infrastruktury.

Weryfikacja praktyczna: jak potwierdzić lub wykluczyć kompromitację

Weryfikacja nie polega na jednym poleceniu, lecz na zebraniu kilku niezależnych sygnałów, które razem dają wiarygodną odpowiedź. Poniższe sekcje porządkują ją od najprostszych sprawdzeń do analizy, która wymaga już dostępu do logów i kontekstu hosta.

Krok 1: potwierdzenie wersji rozszerzenia

Zacznij od ustalenia, jaka wersja Claude Code jest zainstalowana na hoście i czy pochodzi z marketplace Cursor. Interesuje Cię wyłącznie wersja 2.1.313 — to ona zawierała loader i była dystrybuowana 29 października 2026 r. między ok. 10:27 a 21:35. Wersja 2.1.314 i nowsze są zalecane przez Cursor. Pamiętaj, że sam fakt posiadania wtyczki nie oznacza kompromitacji — liczy się wersja i okno czasowe instalacji.

• Ustal wersję rozszerzenia na każdym hoście z Cursor, nie tylko na tych, o których wiesz, że deweloperzy ich używają.
• Sprawdź, czy wtyczka pochodzi z Cursor Marketplace — incydent dotyczył wyłącznie tego kanału, nie Open VSX ani Microsoft VS Code Marketplace.
• Jeśli nie potrafisz odtworzyć historii instalacji, potraktuj host jako podejrzany do czasu potwierdzenia wersji.

Krok 2: analiza ~/.ssh/authorized_keys

To najbardziej bezpośredni ślad. Złośliwa wersja dodawała do pliku ~/.ssh/authorized_keys klucz SSH kontrolowany przez atakujących, zapisany pod nazwą svc-telemetry — prawdopodobnie po to, by wyglądał na nieszkodliwy wpis telemetryczny. Sprawdź nie tylko obecność tego komentarza, ale też daty modyfikacji pliku i inne nieznane klucze dodane w oknie incydentu.

• Wyszukaj wpis z komentarzem svc-telemetry.
• Porównaj datę modyfikacji pliku z oknem 29 października 2026 r.
• Zestaw klucze z listą autoryzowanych kluczy zespołu — każdy nieznany wpis wymaga wyjaśnienia.
• Zabezpiecz kopię pliku przed usunięciem czegokolwiek; to dowód w ewentualnym postępowaniu.

Krok 3: przegląd mechanizmów persystencji

Malware wdrażał persystencję, więc samo usunięcie klucza SSH nie wystarczy. Sprawdź trzy miejsca: zadania zaplanowane w Windows Task Scheduler, wpisy crontab oraz LaunchAgent na macOS. Szukaj zadań i wpisów utworzonych w oknie incydentu lub tuż po nim, szczególnie takich, które uruchamiają nietypowe polecenia lub łączą się z zewnętrznym adresem.

1. Windows: przejrzyj Task Scheduler pod kątem zadań utworzonych 29 października 2026 r. i później.
2. Linux: sprawdź crontab użytkownika i systemowy, zwracając uwagę na wpisy odwołujące się do SSH lub zewnętrznych adresów.
3. macOS: przejrzyj LaunchAgent w katalogach użytkownika i systemowych.
4. Zapisz treść każdego podejrzanego wpisu przed usunięciem.

Krok 4: logi sieciowe i adresy wskaźnikowe

Bez analizy logów nie wiadomo, czy beacon lub tunel zwrotny w ogóle zadziałały. Szukaj połączeń do 134[.]209[.]82[.]225, w tym na port 8099 i ścieżkę /beacon. Malware wysyłał tam zwykłe żądanie HTTP z danymi hosta, a także ustanawiał tunel zwrotny SSH do tego samego adresu. Sprawdź logi proxy, firewalla i EDR za okno 29 października 2026 r. i kilka dni po nim — persystencja mogła zadziałać z opóźnieniem.

• Wyszukaj ruch wychodzący do 134[.]209[.]82[.]225 na wszystkich portach.
• Sprawdź, czy w logach występuje ścieżka /beacon i port 8099.
• Zweryfikuj, czy host pobierał publiczny adres IP z api[.]ipify[.]org — to jeden z elementów zbieranych przez malware.
• Zestaw wyniki z listą hostów, na których potwierdzono wersję 2.1.313.

Krok 5: kontekst, który warto sprawdzić dodatkowo

Malware zbierał publiczny adres IP, nazwę hosta i lokalną nazwę użytkownika, system operacyjny i architekturę procesora, nazwę katalogu domowego i roboczego, adres e-mail z Git pobrany przez git config --global user.email oraz nazwy maksymalnie 40 zmiennych środowiskowych zawierających KEY, TOKEN, SECRET, PASS, AWS lub GCP. Wartości tych zmiennych nie były wysyłane na tym etapie, ale same nazwy ujawniają dostawców usług chmurowych i narzędzi CI, z których korzysta ofiara.

• Sprawdź, czy git config --global user.email jest zgodny z oczekiwanym adresem.
• Ustal, jakie zmienne środowiskowe zawierają wskazane słowa kluczowe na dotkniętych hostach.
• Zapisz nazwy tych zmiennych — to podstawa decyzji o zakresie rotacji poświadczeń.
• Nie zakładaj, że brak wartości w żądaniu oznacza brak ryzyka; nazwy wystarczą do ukierunkowanego ataku.

Monitoring po wdrożeniu: co obserwować przez kolejne tygodnie

Po usunięciu śladów i aktualizacji rozszerzenia nie kończ sprawy. Incydent łańcucha dostaw wymaga okresu obserwacji, który wychwyci ewentualne opóźnione działania persystencji lub ponowne próby dostępu z użyciem wcześniej dodanego klucza.

Monitoring dostępu SSH

Skup się na logowaniach z użyciem klucza powiązanego z wpisem svc-telemetry oraz na nietypowych sesjach SSH z hostów deweloperskich. Nawet po usunięciu klucza warto sprawdzić, czy w okresie przed usunięciem nie doszło do logowania z zewnątrz. Analizuj źródłowe adresy IP, godziny i konta, na które się logowano.

• Alertuj na logowania SSH z adresów spoza znanej infrastruktury.
• Sprawdzaj, czy nie pojawiają się nowe klucze w authorized_keys — to może oznaczać ponowną próbę.
• Monitoruj próby połączeń do 134[.]209[.]82[.]225; serwer został wyłączony, ale adres może wrócić w innych kampaniach.

Monitoring ruchu wychodzącego z hostów deweloperskich

Hosty deweloperskie powinny mieć baseline ruchu wychodzącego. Każde odchylenie — nowe połączenia HTTP do nieznanych adresów, nietypowe porty, żądania do ścieżek takich jak /beacon — wymaga wyjaśnienia. To monitoring, który zapobiega sytuacji, w której reakcja zawsze jest spóźniona.

1. Ustal baseline połączeń dla zespołów deweloperskich.
2. Alertuj na nowe adresy docelowe i nietypowe porty.
3. Koreluj alerty z listą hostów, na których kiedykolwiek wykryto wersję 2.1.313.
4. Przeglądaj logi co najmniej przez kilka tygodni po incydencie.

Monitoring zmian w rozszerzeniach IDE

Po incydencie warto obserwować, jakie rozszerzenia są instalowane i aktualizowane w Cursor. Zmiana wersji wtyczki o szerokich uprawnieniach powinna być widoczna i możliwa do zatrzymania. To element polityki rozszerzeń, a nie jednorazowa akcja.

• Rejestruj instalacje i aktualizacje rozszerzeń w Cursor.
• Alertuj na aktualizacje wtyczek o szerokich uprawnieniach, w tym Claude Code.
• Utrzymuj możliwość cofnięcia wersji rozszerzenia.
• Ustal, kto zatwierdza nowe rozszerzenia i ich aktualizacje.

Monitoring sekretów i konfiguracji Git

Po rotacji poświadczeń obserwuj, czy stare sekrety nie są nadal używane. Sprawdzaj też konfigurację Git na hostach deweloperskich — adres e-mail z git config --global user.email był jednym z elementów zbieranych przez malware, więc jego nietypowa zmiana może sygnalizować problem.

• Weryfikuj, czy zrotowane sekrety zostały wdrożone wszędzie.
• Alertuj na użycie unieważnionych poświadczeń.
• Sprawdzaj spójność konfiguracji Git z oczekiwanym stanem.

Checklista weryfikacji przed zamknięciem sprawy

Poniższa lista porządkuje warunki, które warto spełnić, zanim uznasz host lub cały incydent za zamknięty. Nie każdy punkt musi być wykonany literalnie w tej kolejności, ale żaden nie powinien zostać pominięty bez świadomej decyzji.

1. Potwierdzona wersja Claude Code na każdym hoście z Cursor — 2.1.313 oznacza ekspozycję, 2.1.314 i nowsze są zalecane.
2. Sprawdzone ~/.ssh/authorized_keys pod kątem wpisu svc-telemetry i innych nieznanych kluczy.
3. Przejrzane zadania zaplanowane, crontab i LaunchAgent pod kątem persystencji.
4. Przeanalizowane logi połączeń do 134[.]209[.]82[.]225, portu 8099 i ścieżki /beacon.
5. Zweryfikowany adres git config --global user.email na dotkniętych hostach.
6. Ustalona lista zmiennych środowiskowych z KEY, TOKEN, SECRET, PASS, AWS lub GCP.
7. Zrotowane poświadczenia, których nazwy mogły zostać ujawnione, oraz te dostępne dla procesów na hoście.
8. Zaktualizowane rozszerzenie do 2.1.314 lub nowszej.
9. Uruchomione skanowanie EDR na wszystkich hostach deweloperskich, nie tylko potwierdzonych.
10. Udokumentowany zakres, działania i wnioski — podstawa ewentualnych zgłoszeń i komunikacji wewnętrznej.

Checklista decyzji organizacyjnych

Techniczna weryfikacja to połowa pracy. Druga połowa to decyzje, które zapobiegają powtórce. Cursor zapowiedział bezpośredni kontakt z poszkodowanymi użytkownikami, ale organizacja powinna mieć własny kanał informowania zespołu o tym, co się stało, jakie działania podjęto i czego oczekuje się od deweloperów.

• Czy wiemy, kto używa Cursor i na jakich hostach?
• Czy mamy politykę aktualizacji rozszerzeń w IDE, w tym krótki odstęp między wydaniem a wdrożeniem?
• Czy hosty deweloperskie mają dostęp do tego, do czego nie powinny — na przykład do produkcji?
• Czy sekrety są przechowywane w sposób, który ogranicza skutki ujawnienia nazw zmiennych?
• Czy mamy właściciela polityki rozszerzeń w IDE i procedurę wstrzymania aktualizacji?
• Czy zespół wie, jak zgłaszać podejrzenia i gdzie szukać informacji w trakcie incydentu?

Incydent z 29 października 2026 r. dotyczył maksymalnie 5000 użytkowników, którzy zainstalowali złośliwą wersję 2.1.313. Cursor usunął złośliwą wersję, odbudował marketplace i wyłączył serwer wykorzystywany przez atakujących. Nie znamy sposobu, w jaki atakujący byli w stanie opublikować złośliwą wersję prawdziwej wtyczki. To właśnie dlatego weryfikacja i monitoring po wdrożeniu są tak istotne — nie da się wykluczyć podobnego scenariusza w przyszłości wyłącznie na podstawie zaufania do wydawcy.

Źródła i materiały do dalszej weryfikacji

Artykuł jest autorskim opracowaniem przygotowanym na podstawie poniższych materiałów. Linki prowadzą do publikacji źródłowych.

1. Złośliwa aktualizacja Claude Code w Cursor Marketplace. Do 5000 potencjalnie poszkodowanych użytkowników (sekurak.pl)
2. Before you continue to Google (news.google.com)

Zdjęcie wyróżniające: Godfrey Atima / Pexels.