Po uruchomieniu 1672 umiejętności Claude: prawdziwym ryzykiem nie jest malware

W przypadku narzędzi deweloperskich, takich jak umiejętności Claude, obawy o bezpieczeństwo sprowadzają się do poszukiwania klasycznego malware: ukrytych skryptów kradnących dane uwierzytelniające, zaciemnionych poleceń powłoki i innych ukrytych ładunków. Obawy te są uzasadnione. Audyt ToxicSkills przeprowadzony przez Snyk przeskanował 3984 umiejętności z ClawHub i skills.sh (stan na 5 lutego 2026 r.). Wykryto wzorce prompt-injection w 36% ekosystemu, 534 umiejętności z krytycznymi problemami bezpieczeństwa oraz 76 złośliwych ładunków potwierdzonych przez weryfikację manualną, z czego 8 wciąż było aktywnych na clawhub.ai w momencie publikacji. Podczas równoległego incydentu ClawHavoc z rejestru ClawHub usunięto 341 złośliwych umiejętności. Złośliwe umiejętności agentów nie są problemem czysto teoretycznym.

Warto więc precyzyjnie określić, co znaleźliśmy i co nasza liczba oznacza, a czego nie. W SkillProof instalujemy i uruchamiamy każdą umiejętność z naszej listy, po czym publikujemy wynik testu, zarówno pozytywny, jak i negatywny. Do tej pory przetestowaliśmy 1672 umiejętności: 1045 przeszło testy (wskaźnik powodzenia 63%), 560 wymagało ręcznej konfiguracji, a 67 uzyskało wynik niższy niż czysty Claude bez zainstalowanej umiejętności. Nie znamy innego katalogu, który publikowałby wyniki negatywne obok pozytywnych.

Wśród tych 1672 wykonanych testów nie znaleźliśmy ani jednego przypadku ukrytego malware. Wynik ten należy jednak opatrzyć gwiazdką: nasz katalog nie jest losową próbą z publicznego rejestru. Kandydaci są wstępnie sprawdzani pod kątem jakości, zanim trafią na stanowisko testowe, repozytoria o niskiej jakości i spamerskie są blokowane, a umiejętności, które doczekują się publikacji wyniku, to te, co do których istnieje już duże prawdopodobieństwo, że są legalne. Snyk badał próbę z całego rejestru; my badamy próbę z tej jego części, którą warto instalować. Obie liczby są prawdziwe i odpowiadają na różne pytania.

Nasza próba pozwala natomiast odpowiedzieć na pytanie, którego nikt inny nie zadaje: po odfiltrowaniu oczywistego malware, czym jeszcze należy się martwić? Odpowiedź, którą można powtórzyć w testach, brzmi: zakresem oddziaływania (blast radius) uprawnień i możliwości legalnych, użytecznych umiejętności. Ryzyko to jest trudniejsze do wykrycia skanowaniem, ponieważ w dużej mierze zależy od tego, o jakie zgody prosi umiejętność podczas instalacji i uruchamiania.

Czego nie znaleźliśmy: brak ukrytych ładunków

Mówiąc wprost. W ponad 1600 unikalnych uruchomień umiejętności znaleźliśmy:

• Zero przypadków ukrytej eksfiltracji danych uwierzytelniających na nieznany serwer.
• Zero przypadków ładunku curl | sh ukrytego w plikach umiejętności. Kilka umiejętności dostarcza instalator curl | bash w pliku README swojego repozytorium, a w jednym przypadku instalacja zewnętrznego CLI w ogóle nie jest wspomniana w SKILL.md. Są to ujawnione kroki instalacyjne, które można przeczytać przed uruchomieniem, a nie ukryte ładunki, ale warto je odnotować.
• Zero przypadków ładunków zaciemnionych przez base64 lub innych klasycznych technik obfuskacji mających na celu ukrycie intencji.
• Zero ukrytych instrukcji w pliku SKILL.md, które byłyby sprzeczne z publicznie deklarowanym celem umiejętności.

Poszukiwania konkretnych przykładów malware w naszym testowanym zbiorze nie przyniosły rezultatów. Nie oznacza to jednak, że skanowanie jest bezużyteczne. Oznacza to, że skanery, po które sięga większość ludzi, są dostrojone do niewłaściwych sygnatur. Narzędzie szukające wzorców złośliwego kodu nie zwraca niczego na naszej próbce; narzędzie dostrojone do wzorców uprawnień i możliwości wychwyciłoby większość tego, co zarejestrowaliśmy, ponieważ te wzorce są jawnie zapisane w tekście pliku. Problem leży w tym, czego szukasz, a nie w tym, czy samo szukanie działa. Uruchomienie pozwala wychwycić to, czego nie znajduje żadne z tych podejść: o jakie uprawnienia faktycznie prosi umiejętność podczas działania i co zapisuje do twojej konfiguracji, gdy wyrazisz zgodę. Aby dowiedzieć się więcej o naszym procesie, zobacz jak testujemy umiejętności Claude.

Prawdziwe zagrożenie: zakres oddziaływania uprawnień w legalnych umiejętnościach

Najpoważniejsze problemy z bezpieczeństwem, jakie znaleźliśmy, dotyczyły umiejętności, które poza tym są funkcjonalne i wartościowe. Dwie z pięciu poniższych umiejętności bez problemu przechodzą nasze testy funkcjonalności; pozostałe trzy wymagają ręcznej konfiguracji. Żadna z nich nie jest złośliwa. Niebezpieczeństwo, które wprowadzają, nie wynika ze złych intencji, lecz z nadmiernych możliwości. Ich 'blast radius' — czyli zakres tego, co mogą zrobić z przyznanymi im uprawnieniami — jest niepotrzebnie duży. Niekoniecznie są to niebezpieczne umiejętności Claude, których należy bezwzględnie unikać, ale wymagają one ostrożnego traktowania i zrozumienia przyznawanych uprawnień.

Zbyt szeroki dostęp do systemu plików

Częstym wzorcem jest żądanie uprawnień do systemu plików znacznie wykraczających poza to, co jest potrzebne do działania umiejętności. Sztandarowym przykładem jest UCTM Init, inicjalizator projektu dla potoku wtyczek uc-taskmanager. Podczas konfiguracji wyświetla ogólny monit o zastosowanie „zalecanych ustawień”, co obejmuje zapisanie szerokich uprawnień Read/Edit/Write(/**) do lokalnego pliku konfiguracyjnego .claude/settings.local.json. W naszym teście na pustym projekcie to jedno zatwierdzenie wykonało dwie oddzielne czynności: zapisało wpisy wildcard dla odczytu/edycji/zapisu, które stanowią faktyczny 'blast radius' dla systemu plików, oraz scaliło 34 nazwane uprawnienia Bash z konfiguracją projektu. Nazwane wpisy Bash to lista dozwolonych poleceń i jest to bardziej uzasadniona część; to wpis z wildcardem jest tym, co należy przeczytać przed kliknięciem 'tak'. Umiejętność działa i przechodzi nasze testy, ale zakres, który zatwierdzasz, jest znacznie szerszy niż zadanie, które masz do wykonania.

Tokeny API bez ograniczonego zakresu i daty ważności

Kolejnym powtarzającym się problemem jest obsługa kluczy API. Umiejętność Add Vercel, która wpina dane uwierzytelniające do wdrożeń Vercel w kontenerach agentów NanoClaw, instruuje użytkownika, aby utworzył token API Vercel z zakresem „Full Account” i bez daty wygaśnięcia. Następnie przypisuje ten potężny token do każdego agenta. Skompromitowany lub wadliwy agent mógłby teoretycznie użyć tego tokenu do odczytu, modyfikacji lub usunięcia dowolnego projektu, zespołu lub konfiguracji na całym koncie Vercel. Rozwiązanie jest proste — utworzyć token o wąskim zakresie i regularnie go wymieniać — ale domyślna ścieżka stwarza znaczne ryzyko.

Strzał w stopę w postaci flagi --dangerously-skip-permissions

Claude Code zawiera flagę --dangerously-skip-permissions, która pomija interaktywne monity o potwierdzenie podczas uruchomienia; sama dokumentacja Anthropic zaleca ograniczenie jej użycia do kontenera lub maszyny wirtualnej. Jest to znana funkcja dla zaawansowanych użytkowników, ale znaleźliśmy kilka umiejętności, które normalizują jej użycie, wbudowując ją w domyślne polecenia lub utrwalone konfiguracje. Sesja interaktywna wyświetla jednorazowe okno dialogowe akceptacji przy pierwszym wejściu w ten tryb, co jest dokładnie tym, co omija utrwalone ustawienie konfiguracyjne. W rezultacie świadome nadpisanie dla pojedynczego uruchomienia zamienia się w niewidoczny, stały stan obniżonego bezpieczeństwa.

Umiejętność	Kontekst użycia flagi	Ryzyko
OMA Image	Domyślne polecenie sub-agenta CLI	Proces potomny jest uruchamiany bez sprawdzania uprawnień.
Agentic OS Obsidian	Utrwalone konfiguracje pulpitu/terminala	Wyzwalacze nienadzorowane uruchamiają się bez potwierdzenia dla każdego uruchomienia.
Agy CLI	Zalecany wzorzec dla delegowanych uruchomień	Normalizuje wyłączanie podstawowej funkcji bezpieczeństwa do rutynowego użytku.

W przypadku OMA Image, kanoniczne polecenie dla jego sub-agenta domyślnie zawiera tę flagę. Dla Agentic OS Obsidian, flaga jest wbudowana w utrwalone konfiguracje przycisków na pulpicie i profili terminala, co oznacza, że akcje mogą być wyzwalane bez dodatkowych monitów o bezpieczeństwo. Agy CLI zaleca ją jako standardowy wzorzec dla delegowanych uruchomień. Chociaż dokumentacja umiejętności wspomina o ryzyku, jej powszechny wzorzec użycia skutecznie wyłącza kluczowy mechanizm bezpieczeństwa. Ponownie, są to użyteczne narzędzia, ale ich domyślne konfiguracje wymieniają bezpieczeństwo na wygodę w sposób, który wymaga ostrożności.

Ryzyka wtórne: obsługa danych i nieszczelne abstrakcje

Oprócz jawnego przyznawania uprawnień, zaobserwowaliśmy również złe praktyki bezpieczeństwa, które zwiększają powierzchnię ataku systemu lub prowadzą do wycieku wrażliwych informacji, nawet jeśli nie stanowią aktywnego malware.

Jednym z przykładów jest AI Search Hub. Jego skrypt opakowujący (wrapper) działa poprzez kopiowanie całego katalogu danych użytkownika przeglądarki — w tym ciasteczek i aktywnych sesji — do lokalnego, ignorowanego przez git folderu profilu (chrome_debug_profile_skill). Udostępnia również Chrome DevTools Protocol na porcie 9222 na lokalnej maszynie. To nie jest eksfiltracja; dane nie opuszczają lokalnej maszyny. Tworzy jednak lokalną kopię wrażliwych danych sesji i otwiera potężny port debugowania, rozszerzając 'blast radius' dla każdego innego lokalnego procesu, który mógłby zostać skompromitowany.

Innym przykładem jest Google Ad Scraper. Ta umiejętność przekazuje swój token API jako parametr zapytania w URL (?token=...), a nie w nagłówku Authorization. Query string to najgorsze miejsce na przechowywanie sekretów: trafiają one do historii powłoki, logów dostępowych serwera i każdego proxy na ścieżce. Ta sama umiejętność wysyła również ten token do zewnętrznego punktu końcowego, api.gooseworks.ai, gdy ustawiony jest odpowiedni klucz. Nie są to działania złośliwe, ale jest to niezastosowanie się do standardowych praktyk, co tworzy niechciane ryzyko. Więcej na ten temat można znaleźć w naszym przeglądzie bezpieczeństwa umiejętności Claude.

Konstruktywna strona: umiejętności, które poprawiają bezpieczeństwo

Ekosystem umiejętności to nie tylko źródło potencjalnego ryzyka; to także źródło potężnych narzędzi do jego ograniczania. Ten sam framework, który pozwala umiejętności na interakcję z systemem plików, pozwala również na audytowanie go pod kątem podatności. Przetestowaliśmy kilka umiejętności zaprojektowanych specjalnie do przeglądów bezpieczeństwa.

Skill Security Auditor jest godny uwagi. Przetestowaliśmy go na 13-liniowym pliku zawierającym jawne podatności SQL injection, command injection oraz zahardkodowany klucz API. Jego skrypty analityczne z powodzeniem zidentyfikowały wszystkie trzy podatności. Jako bonus, oznaczył również brakujący plik .gitignore, problem, który przeoczył ludzki recenzent.

Podobnie, uruchomiliśmy Code Health Check na celowo wadliwym API Express, które umiejętność dostarcza we własnym repozytorium. Znalazł wszystkie osiem podrzuconych problemów, które obejmowały SQL injection, parser konfiguracji oparty na eval(), dwa zahardkodowane sekrety, zignorowany błąd i martwą funkcję. Dla każdego z nich podał prawidłowe poziomy ważności oraz precyzyjne odwołania do pliku i numeru linii.

Narzędzia te pokazują drugą stronę medalu możliwości umiejętności. Udzielając zaufanej umiejętności audytującej kontrolowanego dostępu do kodu, można zautomatyzować części procesu przeglądu bezpieczeństwa. Więcej podobnych narzędzi można znaleźć w naszym przewodniku po umiejętnościach Claude do przeglądu bezpieczeństwa.

Jak się chronić: praktyczny model zagrożeń

Biorąc pod uwagę, że głównym zagrożeniem jest nadawanie zbyt szerokich uprawnień, a nie malware, strategia obronna ulega zmianie. Mniej chodzi o antywirusy, a bardziej o dyscyplinę operacyjną.

1. Zakładaj dobre intencje, weryfikuj zakres: Deweloper umiejętności, którą instalujesz, prawdopodobnie nie próbuje cię zhakować. Mógł jednak być nieostrożny lub przedłożyć wygodę nad bezpieczeństwo. Kiedy umiejętność prosi o uprawnienia, przeczytaj monit. Jeśli prosi o dostęp do zapisu w całym twoim katalogu domowym, aby dopisać jedną linię do pojedynczego pliku konfiguracyjnego, odmów.

2. Wybieraj umiejętności o małym 'blast radius': Szukaj umiejętności, które są samowystarczalne i stosują zasadę najmniejszych uprawnień. Świetnym tego przykładem jest Workthreads. Jest to samowystarczalna umiejętność bez żadnych zależności. Wywołuje git tylko za pomocą execFileSync ze stałymi argumentami tablicowymi, aby zapobiec command injection, i jest dostarczana z wbudowanym, deterministycznym mechanizmem redakcji sekretów dla AWS, GitHub, Slack, OpenAI, Anthropic, JWT i tokenów 'bearer' przed wypisaniem jakichkolwiek danych wyjściowych. Została wyraźnie zbudowana z myślą o małym, kontrolowanym 'blast radius'.

3. Uruchamiaj w piaskownicy (sandbox): Nie uruchamiaj nowej, nieznanej umiejętności na swoim głównym kodzie produkcyjnym ani z katalogu domowego. Utwórz dedykowany, jednorazowy katalog do testowania. Użyj Dockera lub innych technologii konteneryzacji, aby uzyskać jeszcze silniejszą izolację.

4. Ufaj wykonaniu, nie tylko kodowi: Jedynym sposobem, aby mieć pewność, co robi dana umiejętność, jest jej uruchomienie i obserwacja zachowania. To podstawowa zasada metodologii SkillProof. Publikujemy nasze notatki z testów, w tym ostrzeżenia dotyczące bezpieczeństwa, takie jak pięć w tym artykule, dla każdej uruchomionej przez nas umiejętności.

Warto przeczytać: praktycznym uzupełnieniem tego artykułu jest tekst o tym, jak deklaracja allowed-tools umiejętności faktycznie ogranicza jej dostęp, co jest mechanizmem leżącym u podstaw większości powyższych problemów. Aby dowiedzieć się, jak szerszy ekosystem katalogów opisuje sam siebie w porównaniu z tym, co weryfikuje, zobacz naszą weryfikację rzeczywistości katalogów.

Każde cytowane tutaj ostrzeżenie dotyczące bezpieczeństwa jest publicznie dostępne na stronie danej umiejętności w katalogu, obok jej wyniku i oceny, dzięki czemu możesz zapoznać się z dowodami przed instalacją. Jeśli wolisz zacząć od zestawu, który już to przeszedł, nasz Pakiet Bezpieczeństwa i Przeglądu Kodu zbiera dziesięć przetestowanych umiejętności do przeglądu kodu, debugowania i testowania kontraktów.