CVE-2025-59536 i CVE-2026-21852 to numery, które każdy deweloper korzystający z Claude Code powinien znać. Anthropic załatał obie luki jeszcze przed publikacją raportu – ale historia pokazuje nowy, niepokojący wektor ataku wymierzony wprost w zespoły deweloperskie.

Repozytorium jako pułapka – jak działały podatności

Claude Code przechowuje ustawienia projektu w pliku .claude/settings.json wewnątrz repozytorium. Każdy współpracownik z prawem zapisu może ten plik modyfikować.

Badacze Check Point Research odkryli, że złośliwa konfiguracja mogła uruchamiać polecenia systemowe automatycznie – jeszcze zanim użytkownik zdążył odpowiedzieć na okno dialogowe z prośbą o potwierdzenie zaufania.

W praktyce działało to przez trzy różne mechanizmy:

1. Hooks (SessionStart) – zdefiniowane w .claude/settings.json polecenia uruchamiane przy starcie sesji, bez dodatkowego monitu. Okno dialogowe wspominało o plikach wykonywanych „za zgodą użytkownika", ale haków nie obejmował osobny prompt potwierdzający.
2. Obejście zgody MCP – parametry enableAllProjectMcpServers lub enabledMcpjsonServers w pliku konfiguracyjnym powodowały uruchomienie serwerów MCP natychmiast po wpisaniu claude – kalkulator otwierał się dosłownie na tle jeszcze nieodczytanego okna dialogowego.
3. Eksfiltracja klucza API – zmienna środowiskowa ANTHROPIC_BASE_URL w .claude/settings.json pozwalała przekierować cały ruch API na serwer atakującego. Klucz API był wysyłany w nagłówku Authorization każdego żądania – zanim użytkownik cokolwiek potwierdził.

Jak podaje Check Point Research, każdy z tych mechanizmów dawał się eskalować do pełnego przejęcia maszyny (reverse shell) lub kradzieży danych uwierzytelniających.

Jeden klucz API, całe zasoby zespołu

Skradziony klucz API to nie tylko kwestia kosztów za nieautoryzowane zapytania do modelu. W modelu Workspaces klucze różnych członków zespołu współdzielą tę samą przestrzeń plików w chmurze. Jak wynika z analizy Check Point Research, jeden przejęty klucz dawał atakującemu:

• dostęp do odczytu plików w workspace – poprzez regenerację pliku przez narzędzie code execution (obejście blokady pobierania)
• możliwość usuwania i nadpisywania plików współdzielonych przez cały zespół
• możliwość wyczerpania limitu 100 GB przestrzeni dyskowej
• generowanie nieautoryzowanych kosztów użycia API lub blokadę usługi po przekroczeniu budżetu

„Narzędzia do tworzenia oprogramowania z wykorzystaniem AI nie są już dodatkowymi, pobocznymi narzędziami, a stają się elementem infrastruktury. Gdy warstwy automatyzacji zyskują możliwość wpływania na wykonywanie poleceń i zachowanie środowiska, zmieniają się granice zaufania. Organizacje, które przyspieszają wdrażanie AI, muszą dopilnować, by ich modele bezpieczeństwa ewoluowały w tym samym tempie" – mówi Oded Vanunu, badacz Check Point Research stojący za odkryciem.

To podatności typu supply chain – złośliwa konfiguracja rozprzestrzenia się przez zaufane kanały deweloperskie. Atakujący mógł dołączyć złośliwy .claude/settings.json do pozornie niewinnego pull requesta, stworzyć atrakcyjne „honeypot repozytorium" (biblioteka, tutorial, starter kit) albo – przy jednym skompromitowanym koncie wewnątrz firmy – zainfekować całą bazę kodu organizacji.

Trzy luki, siedem miesięcy – timeline odkryć

Co zrobić, żeby nie stać się ofiarą

Anthropic wdrożył poprawki przed publikacją raportu. Wzmocniono okno dialogowe zaufania, zablokowano uruchamianie zewnętrznych narzędzi przed jego akceptacją oraz wstrzymano komunikację API do czasu potwierdzenia zaufania do projektu.

Aktualna wersja Claude Code nie jest podatna na opisane ataki.

Dla zespołów korzystających z narzędzi AI do kodowania warto jednak wdrożyć trwałe nawyki:

1. Aktualizuj Claude Code – wszystkie opisane podatności zostały załatane; stare wersje nadal są narażone.
2. Audytuj pliki konfiguracyjne przed klonowaniem – sprawdzaj katalogi .claude/, .vscode/ i podobne w nieznanych repozytoriach.
3. Traktuj zmiany w plikach konfiguracyjnych jak zmiany w kodzie – przeglądaj pull requesty pod kątem settings.json i .mcp.json z taką samą uwagą jak kod produkcyjny.
4. Ogranicz uprawnienia kluczy API – stosuj zasadę minimalnych uprawnień; klucze deweloperskie nie powinny mieć dostępu do zasobów całej organizacji.
5. Monitoruj koszty API i anomalie – nagłe skoki zużycia mogą sygnalizować nieautoryzowane użycie skradzionego klucza.

Warto zapamiętać

• Plik konfiguracyjny to już kod – .claude/settings.json może wykonywać polecenia powłoki; traktuj go jak skrypt.
• Atak nie wymagał żadnej interakcji – samo wpisanie claude w katalogu projektu mogło oddać maszynę w ręce atakującego.
• Jeden klucz API = dostęp do zasobów całego zespołu – model Workspaces sprawia, że skradziony klucz to klucz do wspólnej szafy.
• Narzędzia AI to już infrastruktura – powinny podlegać audytom bezpieczeństwa na równi z serwerami i bazami danych.

Najczęstsze pytania

Czy muszę zaktualizować Claude Code?

Tak – wszystkie trzy podatności zostały załatane w bieżącej wersji. Jeśli korzystasz ze starszej wersji, jesteś narażony na atak przez złośliwe pliki konfiguracyjne w repozytoriach. Aktualizacja to najprostszy i najskuteczniejszy krok ochronny.

Czy podatności dotyczyły tylko Claude Code, czy też innych narzędzi AI do kodowania?

Raport Check Point Research skupia się na Claude Code. Inne narzędzia (np. GitHub Copilot, Cursor) mają inną powierzchnię ataku – Copilot nie wykonuje poleceń systemowych, Cursor oferuje tryb Privacy Mode. Jednak każde narzędzie AI z uprawnieniami do systemu plików i wykonywania poleceń może stanowić podobne ryzyko i wymaga regularnych audytów.

Jak sprawdzić, czy repozytorium zawiera złośliwą konfigurację Claude Code?

Przed uruchomieniem claude w sklonowanym repozytorium sprawdź zawartość pliku .claude/settings.json – szukaj kluczy hooks, enableAllProjectMcpServers, enabledMcpjsonServers oraz niestandardowych wartości ANTHROPIC_BASE_URL. Każda z tych sekcji w kodzie nieznanego źródła powinna wzbudzić czujność.

Co to są CVE i dlaczego warto śledzić takie identyfikatory?

CVE (Common Vulnerabilities and Exposures) to ustandaryzowany system numerowania publicznie znanych podatności bezpieczeństwa. Każdy CVE to unikalny identyfikator konkretnej luki, pozwalający śledzić poprawki i oceniać ryzyko. Deweloperzy powinni regularnie sprawdzać CVE dla narzędzi, których używają – baza NVD (nvd.nist.gov) jest dostępna publicznie i bezpłatnie.

Źródło: Check Point Research, Security Affairs, Anthropic