Paperclip reklamuje się jako system operacyjny dla firmy opartej na AI: ustawiasz cele, zatrudniasz agentów jako pracowników i patrzysz, jak planują i wykonują pracę. Pod spodem to serwer Node.js z interfejsem w Reakcie, który orkiestruje zespół agentów. W tym tygodniu opublikowano komplet trzech luk w tej platformie, a najpoważniejsza z nich pozwala nieuwierzytelnionemu atakującemu przejąć całą instancję — bez konta, bez interakcji ofiary, znając wyłącznie jej adres.
Cały łańcuch to sześć wywołań API. Jest w pełni zautomatyzowany i działa przeciwko domyślnej konfiguracji.
Ale nie liczba wywołań jest tu najciekawsza, tylko to, czym okazał się plik, który atakujący wysyła w kroku piątym. Nazywa się .paperclip.yaml i w dokumentacji figuruje jako konfiguracja importowanej firmy. W praktyce jest to opis agenta — a opis agenta może wskazywać wbudowany adapter procesu i podawać dowolną komendę wraz z argumentami.
Import konfiguracji jest w tym systemie wykonaniem kodu. Tyle że nikt tego tak nie nazwał.
Sześć kroków, z których każdy wygląda legalnie
Warto prześledzić ten łańcuch, bo każde ogniwo z osobna jest funkcją działającą zgodnie z projektem.
Zaczyna się od otwartej rejestracji, która nie wymaga weryfikacji adresu e-mail. To jest domyślne ustawienie i ma sens dla narzędzia, które ma być łatwe do wdrożenia. Atakujący po prostu zakłada konto.
Krok drugi nadużywa przepływu autoryzacji dla wiersza poleceń — procedury opartej na wyzwaniu i zatwierdzeniu, która ma zapewnić, że dostęp z terminala przyzna ktoś uprawniony. Problem w tym, że atakujący może sam zatwierdzić własne żądanie, bez niezależnego zatwierdzającego. Wychodzi z tego trwałe poświadczenie API na poziomie zarządu, całkowicie pod jego kontrolą, przeżywające restarty serwera.
Krok trzeci wykorzystuje niedopasowanie uprawnień, które jest sednem całej sprawy. Bezpośrednie utworzenie nowej firmy w systemie wymaga uprawnień administratora instancji. Ale funkcjonalnie równoważna ścieżka importu wymaga jedynie poziomu zarządu — czyli dokładnie tego, co atakujący właśnie sobie wystawił. Dwie drogi do tego samego skutku, dwa różne progi.
I dopiero teraz przychodzi krok, w którym konfiguracja okazuje się kodem. Przesłany pakiet .paperclip.yaml definiuje agenta korzystającego z wbudowanego adaptera procesu, a wraz z nim komendę do wykonania. Zostaje ostatnie ogniwo: wywołanie budzące agenta pod adresem POST /api/agents/<id>/wakeup, które sprawdza jedynie dostęp do firmy — czyli uprawnienie, które atakujący właśnie sobie zapewnił, importując tę firmę.
Efektem jest wykonanie dowolnych komend jako użytkownik systemowy serwera. Stamtąd: pełny odczyt i zapis systemu plików, dostęp do całej bazy — a więc do konfiguracji wszystkich agentów, kluczy API i danych wszystkich najemców tej instancji — możliwość przejścia w głąb sieci wewnętrznej oraz zakłócenia pracy agentów u każdego klienta na serwerze.
Formalnie luka jest opisana trzema klasami słabości: niewłaściwym uwierzytelnianiem, brakiem autoryzacji i zainicjowaniem zasobu niebezpiecznym ustawieniem domyślnym. To trafne, ale rozbija na trzy części coś, co jest jednym błędem myślowym: założeniem, że plik opisujący agenta to dane, a nie program.
Naprawa endpointu nie usuwa problemu
Jest w tej historii uwaga odkrywcy, która wykracza poza samą lukę i którą warto zacytować, bo dotyczy sposobu naprawiania takich rzeczy w ogóle. Obejście importu było drogą do wykonania kodu — ale prawdziwym problemem jest to, że każdy może przejść od stanu nieuwierzytelnionego do w pełni trwałego użytkownika na poziomie zarządu przez samą kombinację otwartej rejestracji i samodzielnego zatwierdzenia.
Nawet po naprawieniu trasy importu ten sam atakujący wciąż dysponuje ważnym kluczem API. A z nim może odczytywać konfiguracje adapterów i wewnętrzną strukturę interfejsu, zatwierdzać i odrzucać decyzje w dowolnej firmie na instancji — bo te punkty końcowe sprawdzają tylko przynależność do zarządu, a nie dostęp do konkretnej firmy — anulować przebiegi agentów każdego klienta oraz czytać dane z przebiegów kontrolnych, gdzie uwierzytelnienia nie ma w ogóle.
To jest ten sam kształt problemu, który opisywaliśmy przy czterech kolejnych lukach tej samej klasy w Langflow. Łatanie konkretnego wejścia zamyka jedną drogę i zostawia model uprawnień, który tę drogę umożliwił. Jeśli nowo zarejestrowany użytkownik może sobie wystawić trwały klucz z szerokim zasięgiem, to pytanie brzmi już tylko, którym endpointem go wykorzysta.
Trzeba przy tym oddać, że producent naprawił obie warstwy. Import wymaga teraz uprawnień administratora instancji dla nowej firmy i dostępu do firmy dla istniejącej, a ta sama kontrola chroni zarówno podgląd, jak i wykonanie importu. Otwarta rejestracja pozostała dostępna, ale świeżo zarejestrowany użytkownik nie może już traktować ścieżki importu jak operacji administracyjnej.
Ten sam błąd w czterech różnych narzędziach
Najważniejsze zdanie w całej relacji nie pochodzi jednak od twórców Paperclipa ani od odkrywcy luki, lecz od badacza komentującego sprawę z zewnątrz. Eli Ainhorn z Noma Labs ujął to tak: niezależnie od tego, czy mówimy o Paperclipie, czy o trzech innych narzędziach agentowych, obserwujemy dokładnie tę samą awarię w całym krajobrazie AI — narzędzia deweloperskie mają domyślnie niebezpieczne uprawnienia sieciowe i traktują niezaufane dane wejściowe jako bezpieczne instrukcje, oddając zdalnym atakującym natychmiastową kontrolę nad stacjami roboczymi, serwerami i danymi firmowymi.
To jest lista, którą prowadzimy od miesięcy, tylko wypowiedziana jednym zdaniem. Langflow wykonuje dostarczony kod nie przez błąd, lecz dlatego, że na tym polega jego działanie. WordPress wpuścił do rdzenia warstwę AI, w której przejęcie panelu oznacza dostęp do kluczy modeli. Robak npm rejestrował podstawiony serwer MCP w konfiguracjach asystentów kodujących, a jego wczorajszy następca sadził hooki uruchamiane po zaufaniu przestrzeni roboczej. Za każdym razem punktem wejścia był plik uznawany za konfigurację, który w rzeczywistości opisywał, co ma zostać wykonane.
Konfiguracja przestała być deklaracją preferencji. W systemach agentowych jest opisem zachowania — a opis zachowania wykonywanego przez maszynę jest programem, niezależnie od tego, czy ma rozszerzenie .yaml, .json, czy siedzi w polu formularza.
Panel sterowania jest skarbcem
Drugi wątek dotyczy tego, co się traci przy przejęciu takiej platformy, i tu również warto sięgnąć po słowa badacza, który znalazł lukę. Sagi Layani z Oasis Research zwraca uwagę, że platformy agentowe są zwykle podłączone do poświadczeń i wrażliwych informacji, więc kompromitacja panelu sterowania może dać atakującemu dostęp do znacznie większego obszaru niż sama aplikacja.
To jest dokładnie logika skarbca, którą opisywaliśmy przy platformach AI, przeniesiona o poziom wyżej. Langflow trzymał klucze do usług, które łączył. Panel orkiestrujący zespół agentów trzyma coś więcej: konfiguracje wszystkich agentów wraz z uprawnieniami, jakie im nadano. Atakujący, który je kontroluje, nie tylko czyta dane — zyskuje możliwość kierowania uprzywilejowanym działaniem w każdym systemie, do którego sięga którykolwiek z tych agentów.
I to jest różnica jakościowa wobec klasycznego przejęcia serwera. Serwer daje dostęp do tego, co na nim leży. Panel agentowy daje dostęp do tego, co agenci mogą zrobić w twoim imieniu — a więc do zasięgu, który świadomie im nadałeś, zakładając, że nadajesz go im, a nie komuś, kto przejdzie sześć wywołań API.
Uczciwie: co to jest, a czego nie
Kilka rzeczy trzeba postawić jasno, żeby nie zrobić z tego alarmu.
To nie jest świeży zero-day. Najpoważniejszą lukę opublikowano w kwietniu, poprawki są dostępne od wersji 2026.416.0, a druga ścieżka została utwardzona osobno. To, co pojawiło się w tym tygodniu, to zebranie trzech luk w jeden obraz i pokazanie, że składają się na spójny wzorzec — i właśnie ten wzorzec jest wart uwagi, nie sama nowość.
Skala ryzyka też wymaga proporcji. W chwili sprawdzania luka nie figurowała w katalogu znanych eksploatowanych podatności, a żadne autorytatywne źródło nie raportowało wykorzystania w realnych atakach. Z drugiej strony ocena poważności jest maksymalna albo bliska maksymalnej — zależnie od użytej wersji standardu — a od czerwca istnieje publiczny moduł Metasploit automatyzujący cały sześciokrokowy łańcuch. Instytucjonalna ocena mówi wprost, że atak jest w pełni automatyzowalny i daje całkowity wpływ techniczny. Brak potwierdzonej eksploatacji przy istniejącym gotowym narzędziu jest stanem, który zwykle nie trwa długo.
Warto też zaznaczyć, co ogranicza ekspozycję: najpoważniejsza ścieżka dotyczy wdrożeń dostępnych sieciowo, działających w trybie uwierzytelnionym z domyślnymi ustawieniami rejestracji. Ograniczenie dostępu sieciowego istotnie zmniejsza ryzyko, ale go nie usuwa — dowolny użytkownik wewnętrzny albo przejęty host w sieci może przejść ten sam łańcuch.
Co z tego wynika dla obrońcy
Pierwsza rzecz jest oczywista i pilna dla użytkowników tej konkretnej platformy: zaktualizuj do wersji z poprawkami, wyłącz otwartą rejestrację wszędzie, gdzie ekspozycja to uzasadnia, i sprawdź instancję pod kątem śladów — nierozpoznanych firm i agentów, nietypowej aktywności kluczy API, plików pojawiających się w katalogach tymczasowych.
Druga jest szersza i wynika wprost z tego, czym okazał się plik importu. Traktuj konfiguracje agentów jak kod wykonywalny i obejmij je tą samą kontrolą, co każdy uprzywilejowany artefakt wdrożeniowy. To znaczy: przegląd zmian, ograniczony krąg osób mogących je modyfikować, kontrola przy imporcie z zewnątrz i świadomość, że plik opisujący agenta zawiera zwykle wskazanie, co ten agent może uruchomić. Jeśli twój proces przepuszcza konfiguracje bez przeglądu, bo „to tylko ustawienia", masz nieudokumentowaną ścieżkę wykonania kodu.
Trzecia dotyczy modelu uprawnień w narzędziach agentowych i jest najtrudniejsza. Sedno tej luki polegało na istnieniu dwóch dróg do tego samego skutku z dwoma różnymi progami uprawnień — administracyjnej i importowej. Warto poszukać takich par u siebie: operacji, które robią funkcjonalnie to samo, ale jedna jest chroniona ściśle, a druga luźno, bo powstała później albo w innym zespole. To jest miejsce, w którym rodzi się większość obejść autoryzacji, a w systemach z wieloma poziomami dostępu — zarząd, firma, instancja — mnoży się szybciej, niż ktokolwiek nadąża audytować.
Jedna myśl na koniec
Przez trzydzieści lat uczyliśmy się rozdzielać dane od kodu, bo pomieszanie ich jest źródłem większości klasycznych podatności. Wstrzyknięcie SQL, wykonanie skryptu przez przeglądarkę, deserializacja obiektów — wszystko to jest jednym błędem w różnych przebraniach: coś, co miało być opisem, zostało wykonane.
Narzędzia agentowe odtwarzają ten błąd na nowym poziomie i robią to niechcący, bo w ich przypadku granica jest naprawdę niejasna. Plik opisujący agenta musi określać, co agent robi — a określenie, co coś robi, jest programem. Nie da się mieć konfiguracji agenta, która nie byłaby w pewnym sensie kodem, tak jak nie dało się mieć platformy do budowania przepływów AI, która nie wykonywałaby dostarczonego kodu. Różnica polega tylko na tym, czy się o tym wie i odpowiednio zabezpiecza, czy nazywa to plikiem ustawień i importuje po sprawdzeniu, czy nadawca ma jakiekolwiek konto.
Źródła
The Hacker News — zestawienie trzech luk w Paperclipie z ocenami, opisem obu krytycznych ścieżek, stanem poprawek oraz informacją o module Metasploit, klasyfikacji CISA i braku wpisu w katalogu eksploatowanych podatności na dzień 5 sierpnia 2026: https://thehackernews.com/2026/08/paperclip-ai-flaws-let-attackers-run.html
Cyber Press — szczegółowy opis łańcucha ataku: otwartej rejestracji bez weryfikacji adresu, samodzielnego zatwierdzenia w przepływie autoryzacji wiersza poleceń, niedopasowania uprawnień między tworzeniem a importem firmy oraz definiowania agenta z adapterem procesu w pakiecie importu: https://cyberpress.org/critical-paperclip-ai-flaws/
SC Media — komentarze badaczy: Sagiego Layaniego z Oasis Research o panelach sterowania połączonych z poświadczeniami oraz Eliego Ainhorna z Noma Labs o powtarzalnym wzorcu niebezpiecznych ustawień domyślnych i traktowania niezaufanych danych jako bezpiecznych instrukcji w narzędziach agentowych: https://www.scworld.com/news/paperclip-authorization-bug-exploited-leads-to-control-plane-takeover
CSO Online — opis zakresu poprawek w obu wersjach oraz argument, że przejęcie konfiguracji agenta daje możliwość kierowania uprzywilejowanym działaniem we wszystkich systemach, do których ten agent sięga: https://www.csoonline.com/article/4205630/critical-paperclip-bugs-expose-ai-agent-trust-failures.html
Endor Labs — uwaga odkrywcy, że naprawa trasy importu nie usuwa możliwości przejścia od stanu nieuwierzytelnionego do trwałego użytkownika na poziomie zarządu, wraz z listą operacji dostępnych takiemu użytkownikowi w innych firmach na instancji: https://www.endorlabs.com/vulnerability/cve-2026-41679
Nie nowy atak, tylko naprawiony błąd. Co łatka Gemini CLI mówi o tym, że tryb –yolo w potoku CI/CD to nie jest dobry pomysł