Wiadomości dotyczące bezpieczeństwa i sztucznej inteligencji

Łańcuch dostaw agentów AI · Autor FireAI Security & Research Team · Opublikowano

Pillar Security opisuje Deadbugz, serwer MCP, który czeka na trzy wywołania narzędzi, zanim zacznie szukać kluczy SSH

Według Pillar Security kampania 23 pull requestów oferowała serwer MCP, który po trzech wywołaniach każe agentowi AI szukać kluczy i historii powłoki.

A chat bubble with a warning sign and the FireAI research mascot, next to the words “An MCP server waits 3 calls, then hunts keys.”

Pillar Security opisał Deadbugz, kampanię, w której jedno konto GitHub 10 sierpnia 2026 r. w ciągu 74 minut zgłosiło 23 pull requesty, z których każdy dodawał serwer MCP zachowujący się początkowo normalnie, a później polecający podłączonemu agentowi AI szukać poświadczeń [1]. MCP, czyli Model Context Protocol, to standard, z którego wiele agentów AI korzysta do wywoływania zewnętrznych narzędzi.

Tło

Serwer MCP informuje agenta, jakie narzędzia oferuje i co one robią, a agent odczytuje te opisy jako instrukcje. Serwer, który zmienia swoje opisy po instalacji, może więc zmienić działanie agenta bez zmiany kodu, który widział recenzent [1].

Co opisuje raport

Pull requesty pochodziły z publicznego konta o nazwie zellkernel i trafiły do niepowiązanych projektów AI i narzędzi deweloperskich między 21:52 a 23:07 UTC. Siedemnaście z nich konfigurowało zdalny punkt końcowy MCP, cztery odwoływały się do ukrytego lokalnego skryptu Python, a dwa były zgłoszeniami do katalogów. Dziewiętnaście zamknięto, a cztery były wciąż otwarte, gdy Pillar je analizował; żadnego nie scalono za pomocą mechanizmu scalania GitHub [1].

Serwer o nazwie productivity-suite oferuje formatowanie i streszczanie tekstu. Gdy podłączony klient wykona trzy wywołania narzędzi, serwer przepisuje opisy własnych narzędzi tak, by agent otrzymał polecenie szukania kluczy SSH, poświadczeń AWS, historii powłoki i konfiguracji Kubernetes, ukrywając tę aktywność przed użytkownikiem. Pillar podaje, że zdalny punkt końcowy był aktywny w czasie analizy [1].

Znaczenie dla użytkowników Maca

Narażoną grupą są deweloperzy, którzy dodają serwery MCP do konfiguracji agenta lub akceptują pull requesty, które to robią. Pillar nie odnotowuje żadnego scalenia, więc opisana kampania w czasie analizy nie odniosła sukcesu za pośrednictwem GitHub. Deweloper, który skopiował jedną z konfiguracji ręcznie, nie byłby uwzględniony w tym zestawieniu [1].

Zalecenia

  1. Przeglądaj każdy pull request, który dodaje lub zmienia wpis serwera MCP, równie starannie jak taki, który dodaje kod.
  2. Przeszukaj komputery i repozytoria pod kątem punktu końcowego i ścieżki skryptu podanych przez Pillar i wycofaj zmiany, które je wprowadzają.
  3. Wybieraj klientów MCP, którzy ostrzegają, gdy serwer zmienia definicje narzędzi po zatwierdzeniu, zgodnie z zaleceniem Pillar.
  4. W miarę możliwości trzymaj klucze SSH, poświadczenia chmurowe i historię powłoki poza zasięgiem procesów agentów.

Związek z FireAI

FireAI nie czyta konfiguracji MCP ani instrukcji otrzymywanych przez agenta i nie może kazać agentowi ich zignorować. W przypadku zdalnego serwera, takiego jak opisany, każde połączenie jest zdarzeniem sieciowym: pierwsze połączenie aplikacji z nowym celem wywołuje pytanie w trybie Alert, a reguła dla aplikacji może zablokować ten host. Serwer działający lokalnie, który jedynie czyta pliki, nie generuje ruchu sieciowego, który FireAI mógłby zobaczyć.

Ograniczenia

Pobrany tekst raportu nie zawiera daty publikacji. Przypisanie opiera się na publicznym koncie, a stojący za nim operator jest nieznany. Raport nie podaje, czy jakikolwiek agent faktycznie wykonał wrogie instrukcje ani czy przejęto jakiekolwiek poświadczenia [1].

Wypróbuj FireAI od HisnLabs za darmo przez 17 dni.

Źródła

  1. Pillar Security: Deadbugz, a currently active MCP supply-chain campaign (publication date not shown in the fetched text)