Złośliwe rozszerzenie Claude Code – kogo dotyczy i jak sprawdzić komputer

29 października 2026 r. marketplace edytora Cursor przez około 11 godzin rozprowadzał podrobione wersje rozszerzenia Claude Code – 2.1.312 i 2.1.313 dla Windows i macOS – które próbowały założyć na komputerze tylne drzwi SSH. Dotyczy to wyłącznie osób, które między 10:27 a 21:35 czasu polskiego zainstalowały albo zaktualizowały rozszerzenie w Cursorze. Sprawdzenie komputera zajmuje kilka minut i nie wymaga niczego poza terminalem.

Cursor podaje, że złośliwej wersji nie stworzył Anthropic, a Anthropic zapewnia, że wersje w jego oficjalnych kanałach nie są dotknięte. Niżej znajdziesz oś czasu, tabelę „kogo to dotyczy”, gotowe polecenia dla Windows, macOS i Linuksa oraz kroki na wypadek, gdyby sprawdzenie coś wykazało. Tekst opiera się na komunikacie bezpieczeństwa Cursora, oświadczeniu Anthropic i analizach technicznych firm StepSecurity i Phorion.

Co się stało z rozszerzeniem Claude Code w Cursorze?

Ktoś opublikował w marketplace edytora Cursor kopię oficjalnego rozszerzenia Claude Code z dopisanym złośliwym kodem, a Cursor usunął ją po około 11 godzinach. Rozszerzenie łączy edytor z modelami Claude i jak każde rozszerzenie działa z uprawnieniami zalogowanego użytkownika, więc podrobiona wersja mogła na komputerze to samo co on.

Cursor podaje, że po usunięciu wersji sprawdził dostęp do marketplace’u, nie znalazł innych podmienionych rozszerzeń, wymienił klucze, odbudował marketplace i we współpracy z firmą hostingową wyłączył serwer atakującego. Ani Cursor, ani Anthropic nie wyjaśnili, w jaki sposób podrobiona paczka trafiła do marketplace’u pod nazwą wydawcy Anthropic. Skalę incydentu StepSecurity, powołując się na Cursora, określa na najwyżej 5 000 użytkowników. Zaktualizowana wersja komunikatu Cursora tej liczby nie podaje.

Numer 2.1.312 bywa mylący. Czysta wersja o tym numerze była w oficjalnych kanałach od 27 października, a podrobiona paczka z tym samym numerem krążyła w marketplace Cursora. Sam numer wersji nie przesądza więc, czy komputer jest bezpieczny – liczą się źródło instalacji i ślady opisane niżej.

Kogo dotyczy złośliwe rozszerzenie Claude Code, a kogo nie?

Złośliwe rozszerzenie Claude Code dotyczy osób, które 29 października między 10:27 a 21:35 zainstalowały albo zaktualizowały rozszerzenie w Cursorze na Windows lub macOS – także wtedy, gdy aktualizacja przyszła automatycznie. Użytkownicy VS Code z oficjalnego marketplace’u Microsoftu i samego CLI według Anthropic nie są dotknięci.

Ostatni wiersz wymaga wyjaśnienia. Dokumentacja Anthropic podaje, że uruchomienie claude w zintegrowanym terminalu VS Code automatycznie instaluje rozszerzenie, a wyłącza to opcja „Auto-install IDE extension” w /config (ustawienie autoInstallIdeExtension). Jeśli pracujesz „tylko w terminalu”, ale tym wbudowanym w Cursora, zajrzyj do listy rozszerzeń – Claude Code mógł się tam znaleźć bez twojej wiedzy, a później aktualizować przez marketplace edytora. W razie wątpliwości sprawdzenie z dalszej części tekstu trwa kilka minut, więc lepiej je zrobić niż zgadywać.

Co robiła podrobiona wersja rozszerzenia?

Podrobione rozszerzenie zaraz po załadowaniu w edytorze dopisywało klucz SSH atakującego, instalowało mechanizm uruchamiany przy starcie systemu, próbowało otworzyć odwrotny tunel SSH do serwera pod adresem 134.209.82.225 i wysyłało tam podstawowe dane o komputerze. Według StepSecurity kod ruszał przy samym wczytaniu rozszerzenia – bez rozmowy z Claude i bez klikania czegokolwiek.

• Dane o komputerze – nazwa komputera i użytkownika, system i architektura, katalog domowy i katalogi robocze, adres e-mail z konfiguracji Gita, nazwy zmiennych środowiskowych i publiczny adres IP trafiały na serwer atakującego zwykłym HTTP na port 8099 (Cursor). Według StepSecurity i Phorion chodziło o nazwy (najwyżej 40) zmiennych zawierających m.in. KEY, TOKEN, SECRET, PASS, AWS i GCP – same nazwy, bez wartości, ale to podpowiedź, jakie klucze i tokeny są na komputerze. Publiczny adres IP kod sprawdzał w legalnych serwisach ifconfig.me i api.ipify.org, więc same połączenia z nimi nie są śladem infekcji.
• Klucz SSH atakującego – wpis w pliku authorized_keys z opisem svc-telemetry, który pozwala zalogować się na komputer bez hasła.
• Włączenie serwera SSH – na Windows przez doinstalowanie OpenSSH Server, na macOS przez włączenie zdalnego logowania. Ten krok wymaga uprawnień administratora, więc według Cursora na większości komputerów się nie udawał. Nie był też potrzebny tam, gdzie serwer SSH działał już wcześniej, bo ktoś włączył go celowo. Phorion, który rozłożył kod na części, opisuje do tego dwa błędy samego ataku: na Windows polecenie instalujące serwer szło przez /bin/sh, którego zwykły Windows nie ma, a na macOS sprawdzenie stanu zdalnego logowania bez uprawnień administratora kończyło się komunikatem, którego kod nie rozpoznawał, więc nawet nie próbował go włączyć. Tunel łączył się wtedy na zewnątrz, ale trafiał w zamknięty port 22. Tylne drzwi zaczynają jednak działać, gdy zdalne logowanie zostanie włączone później.
• Odwrotny tunel SSH – połączenie wychodzące do serwera atakującego (polecenie ssh -N -R, także przez autossh), ponawiane mniej więcej co 60 sekund. Taki tunel omija router i zaporę blokującą połączenia przychodzące, bo to komputer ofiary sam łączy się na zewnątrz. Prowadzi jednak tylko do portu 22 tego komputera: atakujący loguje się przez niego kluczem svc-telemetry, ale wyłącznie wtedy, gdy na komputerze nasłuchuje serwer SSH.
• Uruchamianie przy starcie – na Windows zadanie harmonogramu SysMon, a bez uprawnień administratora skrypt sysmon.cmd w folderze Autostart; na macOS agent com.apple.sysmond, którego nazwa udaje usługę systemową Apple; na Linuksie wpis cron @reboot.

Nieudane włączenie serwera SSH nie oznacza, że nic się nie stało. Cursor zaznacza, że dodanie klucza, mechanizm startowy i wysłanie danych mogły zadziałać bez uprawnień administratora, więc sprzątanie jest potrzebne zawsze. Bez działającego serwera SSH atakujący nie mógł się jednak zalogować przez tunel – tak ujmuje to Cursor. Najgorsze scenariusze to więc edytor uruchomiony jako administrator, który sam włączył serwer SSH, albo serwer SSH włączony wcześniej przez użytkownika – wtedy klucz i tunel mogły zadziałać razem. Na Windows pierwszy scenariusz według Phorion blokował błąd w samym kodzie. StepSecurity podaje, że interaktywny dostęp przez klucz atakujący uzyskiwał tam, gdzie tunel zadziałał, głównie przy edytorze uruchomionym z uprawnieniami administratora.

Druga ważna konsekwencja: odinstalowanie rozszerzenia albo aktualizacja do wersji 2.1.314 nie usuwa infekcji. Skrypty startowe działają niezależnie od edytora i zostają na dysku. Agent z dostępem do systemu, taki jak OpenClaw, i zwykłe rozszerzenie edytora mają tu ten sam słaby punkt: działają z pełnymi uprawnieniami użytkownika, więc podmiana ich kodu daje atakującemu dokładnie tyle, ile ma użytkownik.

Jak sprawdzić, czy komputer jest czysty?

Sprawdzenie polega na wyszukaniu pięciu śladów: klucza svc-telemetry w pliku authorized_keys, plików startowych, zadania albo agenta uruchamianego przy starcie, połączenia z adresem 134.209.82.225 oraz zmienionego pliku extension.js w folderze rozszerzenia. Wszystkie polecenia niżej tylko czytają – niczego nie zmieniają ani nie usuwają.

Windows (PowerShell)

Otwórz PowerShell jako administrator (prawy przycisk na ikonie, „Uruchom jako administrator”), bo zadanie SysMon działa z uprawnieniami SYSTEM. Wklej polecenia po kolei:

# Klucz atakującego w plikach SSH
Get-Content "$HOME\.ssh\authorized_keys", "C:\ProgramData\ssh\administrators_authorized_keys" -ErrorAction SilentlyContinue | Select-String "svc-telemetry" -SimpleMatch

# Pliki startowe i plik klucza tunelu
Test-Path "$HOME\.config\smt.cmd", "$HOME\.config\.smt", "$HOME\.config\smtk", "$env:APPDATA\Microsoft\Windows\Start Menu\Programs\Startup\sysmon.cmd"
Get-ChildItem $env:TEMP -Filter ".stk_*" -Force -ErrorAction SilentlyContinue

# Zadanie harmonogramu i serwer SSH
Get-ScheduledTask -TaskName "SysMon" -ErrorAction SilentlyContinue
Get-Service sshd -ErrorAction SilentlyContinue

# Połączenie z serwerem atakującego
Get-NetTCPConnection -RemoteAddress 134.209.82.225 -ErrorAction SilentlyContinue

# Zmieniony kod rozszerzenia w Cursorze
Get-ChildItem "$HOME\.cursor\extensions" -Recurse -Filter extension.js -ErrorAction SilentlyContinue | Select-String "svc-telemetry" -SimpleMatch -List

Czysty komputer zwraca cztery razy False przy plikach startowych i nic więcej – chyba że serwer SSH zainstalowałeś celowo, wtedy pojawi się też wiersz usługi sshd.

macOS

Otwórz Terminal i wklej:

# Klucz atakującego
grep -s svc-telemetry ~/.ssh/authorized_keys

# Agent startowy i pliki
ls -la ~/Library/LaunchAgents/com.apple.sysmond.plist ~/.config/.smt ~/.config/.smtk ~/.config/smt.cmd 2>/dev/null
find "$TMPDIR" -maxdepth 1 -name '.stk_*' 2>/dev/null

# Serwer SSH nasłuchujący na porcie 22
netstat -an | grep LISTEN | grep '\.22 '

# Połączenie z serwerem atakującego
netstat -an | grep 134.209.82.225

# Zmieniony kod rozszerzenia w Cursorze
grep -rl -e svc-telemetry -e 134.209.82.225 ~/.cursor/extensions 2>/dev/null

Na czystym komputerze żadne polecenie nic nie wypisuje – wyjątkiem jest wiersz z portem 22, jeśli sam włączyłeś zdalne logowanie. Nazwa com.apple.sysmond udaje usługę Apple, dlatego liczy się wyłącznie plik w folderze ~/Library/LaunchAgents – tam macOS swoich usług nie trzyma.

Linux

# Klucz atakującego
grep -s svc-telemetry ~/.ssh/authorized_keys

# Wpis w cron i pliki
crontab -l 2>/dev/null | grep -F '.config/.smt'
ls -la ~/.config/.smt ~/.config/.smtk ~/.config/smt.cmd 2>/dev/null
find /tmp -maxdepth 1 -name '.stk_*' 2>/dev/null

# Serwer SSH nasłuchujący na porcie 22
ss -tln | grep ':22 '

# Połączenie z serwerem atakującego
ss -tn | grep 134.209.82.225

# Zmieniony kod rozszerzenia w Cursorze
grep -rl -e svc-telemetry -e 134.209.82.225 ~/.cursor/extensions 2>/dev/null

Tu również czysty komputer nic nie wypisuje, poza wierszem z portem 22 tam, gdzie serwer SSH działa celowo. Phorion zwraca uwagę na jeszcze jeden skutek błędu w kodzie: przy kolejnym uruchomieniu złośliwy skrypt mógł skasować istniejące zadania cron użytkownika. Jeśli z crontab -l zniknęły twoje wpisy, to też ślad.

Jak czytać wynik

• Nic się nie wyświetla (w Windows tylko False) – komputer nie ma śladów tej infekcji.
• Jakiekolwiek trafienie – klucz svc-telemetry, któryś z plików, zadanie SysMon, plik com.apple.sysmond.plist w ~/Library/LaunchAgents, wpis w cron, połączenie z 134.209.82.225 albo plik extension.js z tymi napisami – oznacza, że komputer trzeba traktować jako zainfekowany. Przejdź do następnej sekcji.
• Działający serwer SSH sam w sobie nie jest dowodem, bo wielu programistów włącza go celowo. Zmienia jednak ocenę pozostałych trafień: serwer SSH razem z kluczem svc-telemetry oznacza, że atakujący mógł wejść na komputer przez tunel, bez względu na to, kto serwer włączył. Serwer, którego nikt nie włączał, to dodatkowo znak, że podrobione rozszerzenie działało z uprawnieniami administratora.
• Brak połączenia z 134.209.82.225 niczego nie dowodzi. Serwer atakującego jest wyłączony, więc tunel może nie mieć się z czym połączyć. O infekcji świadczą klucz, pliki i mechanizm startowy.
• Brak folderu z podrobioną wersją nie dowodzi, że komputer jest czysty. Edytor po aktualizacji do 2.1.314 zwykle usuwa stary folder rozszerzenia, a skrypty startowe zostają. Decydują więc ślady: klucz, pliki i mechanizm startowy, a nie numer wersji.

Co zrobić, jeśli znajdziesz ślady infekcji?

Po znalezieniu śladów odłącz komputer od sieci, usuń tylne drzwi skryptem przygotowanym przez Cursora, a hasła, tokeny i klucze zmień z innego, zaufanego urządzenia. Samo odinstalowanie rozszerzenia nie wystarcza.

1. Odłącz komputer od sieci – wyjmij kabel i wyłącz Wi-Fi. Tunel próbuje połączyć się ponownie co minutę.
2. Uruchom skrypt naprawczy Cursora. Komunikat bezpieczeństwa Cursora zawiera dwa skrypty: remediate-windows.ps1 uruchamiasz w PowerShellu jako administrator po zamknięciu wszystkich edytorów, a remediate-macos.sh jako zwykły użytkownik, nie jako root – osobno na każdym koncie, na którym działał Cursor. Pobierz je na innym komputerze i przenieś na przykład pendrive’em. Skrypty usuwają klucz, mechanizmy startowe, procesy tunelu i folder podrobionego rozszerzenia, a jeśli coś zostało, kończą się błędem – wtedy powtórz sprawdzenie z poprzedniej sekcji. Skrypt dla Windows czyści tylko pliki authorized_keys w profilach użytkowników: jeśli sprawdzenie znalazło svc-telemetry w C:\ProgramData\ssh\administrators_authorized_keys, usuń ten wpis ręcznie. Dla kont z grupy Administratorzy serwer OpenSSH w Windows czyta klucze właśnie z tego pliku, a nie z profilu użytkownika – podaje to dokumentacja Microsoftu. Dla Linuksa Cursor skryptu nie udostępnia, więc wpis cron, pliki ~/.config/.smt, ~/.config/.smtk i /tmp/.stk_*, procesy ssh i autossh korzystające z tych plików oraz klucz usuwasz ręcznie. Klucz atakującego bywa dopisany w tej samej linii co twój własny, dlatego kasuj sam wpis kończący się na svc-telemetry, a nie całą linię.
3. Odinstaluj rozszerzenie i zainstaluj wersję 2.1.314 lub nowszą. Kolejność ma znaczenie: najpierw usunięcie tylnych drzwi, potem nowa wersja – sama aktualizacja nie usuwa tego, co zostawiła podrobiona.
4. Zmień hasła i tokeny z innego komputera. Cursor zaleca wymianę wszystkich danych logowania i sesji dostępnych z zainfekowanej maszyny – w praktyce tokenów GitHuba lub GitLaba, kluczy API (Anthropic, OpenAI, chmura), kluczy SSH, dostępów do CI/CD i rejestrów pakietów. Unieważnij też aktywne sesje. Cursor zastrzega, że ograniczony zakres wysłanych danych nie wyklucza późniejszego dostępu do haseł przez tylne drzwi.
5. Sprawdź logi serwera SSH i rozważ reinstalację systemu. Cursor zaleca reinstalację rozważyć, a StepSecurity – wykonać, jeśli tunel zdążył się połączyć. Ryzyko wejścia dotyczy komputerów, na których działał serwer SSH – skrypty Cursora po usunięciu tylnych drzwi same informują, jeśli coś nasłuchuje na porcie 22. Wtedy przejrzyj logi serwera SSH (Windows: w PowerShellu jako administrator Get-WinEvent -LogName 'OpenSSH/Operational’ -ErrorAction SilentlyContinue | Where-Object Message -match 'Accepted publickey’ albo Podgląd zdarzeń, dziennik OpenSSH > Operational; Linux: sudo journalctl -u ssh -u sshd; macOS: dziennik systemowy) i szukaj udanych logowań kluczem (Accepted publickey) z adresu 127.0.0.1 lub ::1 – tak wygląda wejście przez odwrotny tunel. Odcisk klucza atakującego, który pojawi się w takim wpisie, podaje komunikat Cursora. Taki wpis albo serwer SSH, którego nikt nie włączał, oznacza, że reinstalacja jest bezpieczniejsza niż sprzątanie.
6. W zespole przeszukaj logi pozostałych komputerów. Cursor zaleca przejrzenie danych z komputerów, sieci i instalacji rozszerzeń pod kątem wskaźników z komunikatu. W ruchu sieciowym będą to połączenia z 134.209.82.225 na port 22 (tunel) i 8099 (wysyłka danych).

Pytania kieruj do Cursora na adres security@cursor.com.

Jak ograniczyć ryzyko automatycznych aktualizacji rozszerzeń?

Najprostsza ochrona przed takim incydentem to opóźnienie automatycznych aktualizacji. VS Code domyślnie instaluje nową wersję rozszerzenia automatycznie dopiero 12 godzin po jej publikacji. Podrobiona paczka była dostępna około 11 godzin, więc przy takim buforze edytor nie zdążyłby jej sam pobrać – z dwoma zastrzeżeniami: opóźnienie nie chroni przy ręcznej instalacji ani aktualizacji i działa tylko wtedy, gdy fałszywkę ktoś wykryje w ciągu tych 12 godzin. To ustawienie opisuje dokumentacja VS Code, a incydent dotyczył marketplace’u Cursora.

Przy vibe codingu edytor z kilkoma asystentami AI to codzienność, a każde z tych rozszerzeń dostaje od systemu tyle samo zaufania co sam programista. Dlatego warto:

• Nie skracać opóźnienia aktualizacji. W VS Code odpowiada za nie ustawienie extensions.autoUpdateDelay (w godzinach, wartość 0 oznacza instalację od razu). Przycisk „Update” przy rozszerzeniu omija opóźnienie.
• Wyłączyć automatyczne aktualizacje rozszerzeń z dostępem do kodu. Prawy przycisk na rozszerzeniu i odznaczenie „Auto Update” wyłącza je dla jednego dodatku, a ustawienie extensions.autoUpdate – dla wszystkich. Nowe wersje instalujesz wtedy sam, gdy mają za sobą dzień lub dwa bez zgłoszeń.
• Nie uruchamiać edytora jako administrator. Bez tych uprawnień podrobione rozszerzenie nie mogło włączyć serwera SSH. Według Phorion kod nie zawierał żadnej techniki podnoszenia uprawnień – korzystał wyłącznie z tych, które dostał od edytora.
• Wyłączyć serwer SSH, jeśli z niego nie korzystasz. Tunel atakującego prowadził do portu 22 komputera – tam, gdzie nic na nim nie nasłuchiwało, klucz svc-telemetry był bezużyteczny. Na Macu serwer SSH włącza opcja „Zdalne logowanie” w Ustawieniach systemowych > Ogólne > Udostępnianie. Nie włączaj jej, dopóki nie sprawdzisz komputera – według Phorion tylne drzwi na macOS czekają właśnie na nią.
• Nie trzymać kluczy API w plikach ustawień edytora. Klucz wklejony do settings.json albo do zmiennej środowiskowej jest w zasięgu każdego rozszerzenia – podrobiona wersja Claude Code spisywała nazwy właśnie takich zmiennych.
• Ustalić w zespole listę dozwolonych rozszerzeń. Dodatki AI instalowane na własną rękę to typowy przypadek shadow AI: nikt nie wie, co jest zainstalowane, więc po incydencie nikt nie wie też, czyje komputery sprawdzić.
• Wyłączyć auto-instalację, jeśli nie używasz rozszerzenia. Opcja „Auto-install IDE extension” w /config Claude Code zatrzymuje ponowne instalowanie rozszerzenia przy uruchamianiu claude w terminalu edytora.

FAQ

Przeczytaj też

• Bezpieczeństwo agentów AI w firmie i RAG
• Jak modele AI radzą sobie z programowaniem – ProgramBench
• OpenClaw – co to jest, jak działa i czy jest bezpieczny
• Shadow AI i bezpieczeństwo danych firmowych
• Vibe coding – przyszłość inżynierii i tworzenia aplikacji
• Model Context Protocol (MCP) – architektura i bezpieczeństwo
• Claude Code – cena, limity i kody rabatowe
• Wszystkie teksty z kategorii Bezpieczeństwo AI

Źródła

• Security notice – malicious version of Anthropic.claude-code (2.1.312 and 2.1.313) identified in the Cursor VS Code Extension Marketplace, Cursor: okno ekspozycji 29.10.2026, podrobione wersje dla Windows i macOS, działanie kodu i zakres wysyłanych danych, wymóg uprawnień administratora, wskaźniki infekcji (także dla Linuksa), skrypty naprawcze dla Windows i macOS, zalecenie przeszukania logów, działania Cursora
• Use Claude Code in VS Code, dokumentacja Anthropic: kanały publikacji rozszerzenia (Visual Studio Marketplace, Open VSX), automatyczna instalacja rozszerzenia z terminala, opcja autoInstallIdeExtension
• Extension Marketplace – Extension auto-update, dokumentacja VS Code: domyślne opóźnienie aktualizacji o 12 godzin, ustawienia extensions.autoUpdateDelay i extensions.autoUpdate, wyłączanie aktualizacji dla pojedynczego rozszerzenia
• OpenSSH Server Configuration for Windows, Microsoft Learn: plik administrators_authorized_keys dla kont z grupy Administratorzy, domyślne logowanie serwera SSH do dziennika zdarzeń
• Dopuszczanie zdalnego dostępu do Maca, Wsparcie Apple: opcja Zdalne logowanie (SSH) w Ustawieniach systemowych > Ogólne > Udostępnianie
• Trojanized Claude Code Extension Delivered Persistent SSH Backdoor to Developer Machines, StepSecurity (Rohan Prabhu): oś czasu w UTC, publikacja czystych wersji 2.1.312 i 2.1.314 w Open VSX, nazwy zmiennych w wysyłanych danych, dostęp przez klucz głównie przy edytorze z uprawnieniami administratora, zalecenie reinstalacji po połączeniu tunelu
• Analiza podrobionej wersji 2.1.313 rozszerzenia Claude Code, Phorion (Calum Hall): przebieg ataku krok po kroku, błędy w kodzie na Windows, macOS i Linuksie, brak techniki podnoszenia uprawnień, serwisy ifconfig.me i api.ipify.org, logowania przez tunel z 127.0.0.1
• Felix Rieseberg (Anthropic), wpis na X: incydent nie był włamaniem do systemów Anthropic, oficjalne kanały nie są dotknięte, dotyczy tylko użytkowników Cursora

Ostatnia aktualizacja: 31 października 2026 · Zgłoś poprawkę