O czym jest ten film
- Jednego dnia ujawniono poważne podatności w PHP, Node.js, GitLabie, Quick i innych elementach codziennego stosu — a w trakcie nagrywania doszedł jeszcze Oracle.
- Autor zdecydowanie rozdziela dwie kategorie: odkryte luki (CVE) w projektach open source oraz realne włamania na platformy OpenCode i Railway — to drugie uważa za groźniejsze, choć media skupiają się na pierwszym.
- Luki w PHP, ocenione na 9,2 na 10, pozwalają zdalnie uruchomić kod i przejąć pełną kontrolę nad serwerem; FBI wydało publiczny komunikat z konkretnymi zaleceniami.
- Modele AI drastycznie skracają „okno podatności”: potrafią przejrzeć commity, wychwycić łatki bezpieczeństwa i na ich podstawie napisać działający atak na stare wersje — nawet gdy commit niczego nie sugeruje.
- Podatności PHP znalazł model GPT 5.6 Soul, oceniany przez autora jako przeciętny, a niezależnie trafiła na nie firma Wiz — co podważa sens prywatnego ujawniania luk.
- Chainguard złamał uzgodnione embargo, publikując poprawione obrazy PHP kilka godzin przed planem — napastnicy mogli analizować łatki, zanim użytkownicy się zabezpieczyli.
- Statystyka „70% stron internetowych działa na PHP” jest bezwartościowa, bo liczona po adresach URL, w większości martwych i pozbawionych ruchu.
- Atak na OpenCode polegał na kradzieży kluczy API klientów; zgłaszano straty od 400 do 3000 dolarów w kilka minut oraz blokady kont.
- Na Railway odczytano zaszyfrowane zmienne środowiskowe, a osobno platforma przez ponad 16 godzin nie pozwalała na wdrożenia — co autor przypisuje nieudolności dostawcy, nie włamaniu.
- Główny motyw ataków to destylacja: laboratoria, którym Anthropic i OpenAI odmawiają sprzedaży tokenów, zasilają popyt na skradzione klucze — dlatego każda platforma przechowująca sekrety stała się celem.
10 najważniejszych takeaways — z kontekstem zastosowania
1.Rozdzielaj ujawnione luki od aktywnych ataków
Na czym polega: Jednego dnia dostaлиśmy dwie różne kategorie zagrożeń: publicznie ujawnione podatności (PHP, Node, GitLab) oraz faktyczne włamania (OpenCode, Railway). Wymagają one zupełnie innej reakcji.
Jak stosować: W komunikacji zespołu i w planie reagowania prowadź osobne tory: dla CVE — inwentaryzacja i szybka aktualizacja; dla ataków — rotacja sekretów i analiza tego, co napastnik mógł przejąć.
Na co uważać: Social media mieszają te sprawy w jeden „mega-incydent”. Nie podejmuj decyzji priorytetowych na podstawie takiego obrazu — najpierw sprawdź, czy dotyczy Cię kategoria luki, czy kategoria włamania.
2.AI skraca „okno podatności” z tygodni do godzin
Na czym polega: Kiedyś wykorzystanie łatki wymagało czterech żmudnych kroków: znalezienia poprawki, zrozumienia jej, napisania exploita i rozpowszechnienia go. Dziś agent przejrze każdy commit, wykryje ten dotyczący bezpieczeństwa i w krótkim czasie zbuduje działający atak na stare wersje.
Jak stosować: Traktuj dzień publikacji łatki jak dzień podwyższonego ryzyka — aktualizuj zależności natychmiast, a nie w kolejnym oknie serwisowym. Zwłaszcza w systemach dostępnych z internetu.
Na co uważać: „Czołowe laboratoria odmówią napisania exploita” nie jest zabezpieczeniem — model o otwartych wagach zrobi to samo bez oporów.
3.PHP: aktualizacja natychmiast, a gdy się nie da — system offline
Na czym polega: Dwie luki (9,2/10) pozwalają zdalnie wykonać kod w rdzeniu PHP i zdobyć pełne uprawnienia na serwerze. Wskazówki FBI: natychmiastowa aktualizacja wg php.net, a gdy to niemożliwe — odłączenie systemu do czasu naprawy.
Jak stosować: Zrób przegląd, gdzie PHP w ogóle działa w Twoim środowisku: własne serwery, systemy wystawione na internet, produkty dostawców z wbudowanym interpreterem. Monitoruj procesy PHP, które nagle uruchamiają powłokę systemową lub pobierają pliki.
Na co uważać: PHP często siedzi głęboko w cudzych produktach — „nie piszemy w PHP” nie oznacza jeszcze, że nie jesteś dotknięty.
4.Koordynacja ujawniania łuk bezpieczeństwa przestała działać
Na czym polega: Chainguard wydał poprawione obrazy PHP kilka godzin przed uzgodnionym harmonogramem, łamiąc embargo. W erze agentów sama łatka to gotowy punkt wyjścia do ataku — jej przedwczesna publikacja równa się wręczeniu exploita napastnikom.
Jak stosować: Jeśli publikujesz poprawki bezpieczeństwa (obrazy kontenerów, paczki, buildy), trzymaj się uzgodnionego z innymi dystrybutorami kalendarza i dopilnuj, by poprawka i jej wdrożenie u użytkowników szły w parze.
Na co uważać: Okno między „łatka jest publiczna” a „użytkownicy ją mają” jest dziś najniebezpieczniejszym momentem całego cyklu.
5.Jeśli dwóch znalazło tę samą lukę, znalazło jej więcej
Na czym polega: Podatności PHP wykrył model GPT 5.6 Soul — a niezależnie zrobiła to firma Wiz. Gdy dwa podmioty niezależnie trafiają na to samo, trzeba założyć, że trafiają na to również kolejne, po cichu.
Jak stosować: Nie traktuj „nieujawnionej jeszcze” luki jako bezpiecznej. Skracaj czas między wydaniem poprawki a jej faktycznym wdrożeniem u klientów — to jedyna zmienna, którą jeszcze kontrolujesz.
Na co uważać: Prywatne ujawnianie luk jako mechanizm obrony traci sens, gdy koszt ich znalezienia spada niemal do zera — nie opieraj na nim strategii.
6.Klucze API traktuj jak gotówkę: limity, alerty, rotacja
Na czym polega: Po ataku na OpenCode poszkodowani zgłaszali od 400 do 3000 dolarów zużyć w kilka minut oraz blokady kont. Klucz pozostawiony bez nadzoru to cudzy portfel.
Jak stosować: Ustaw limity wydatków i alerty billingowe na każdym koncie z kluczem, regularnie usuwaj nieużywane klucze i przydzielaj osobne, ograniczone uprawnieniami klucze każdemu projektowi i usłudze.
Na co uważać: Sam autor przyznaje, że słabo pilnuje zużycia w OpenAI — to najbardziej typowy błąd, nie zaniedbanie wyjątkowych.
7.Każda platforma trzymająca Twoje sekrety to przedłużenie Twojej powierzchni ataku
Na czym polega: Popyt na klucze Anthropic i OpenAI na czarnym rynku jest tak duży, że dostawcy typu Railway czy OpenCode stali się celami atrakcyjniejszymi niż kiedykolwiek — nie dla baz danych, ale dla haseł API klientów.
Jak stosować: Minimalizuj liczbę miejsc, w których lądują Twoje sekrety. Tam, gdzie się da, korzystaj z sekretów zarządzanych, automatycznej rotacji i krótkotrwałych, ograniczonych tokenów zamiast trwałych kluczy.
Na co uważać: Napastnikowi nie zależy na trwałym dostępie — wystarczy mu kilka godzin generowania na Twój rachunek, zanim klucz zdechnie.
8.Skutki włamania odróżniaj od awarii reakcji dostawcy
Na czym polega: Na Railway zbiegły się dwie osobne sprawy: kradzież zmiennych środowiskowych (atak) i 16-godzinna niemożność wdrażania — którą autor przypisuje po prostu niekompetencji platformy, nie hakerom.
Jak stosować: Przy incydencie u dostawcy zadawaj dwa osobne pytania: „czy nasze dane wyciekły” oraz „czy możemy dalej działać i wdrożyć obejście”. Miej plan B na hosting — możliwość szybkiego przeniesienia wdrożenia z nowymi sekretami.
Na co uważać: Platforma, która po włamaniu nie pozwala redeployować, przedłuża Twoją ekspozycję na atak — to osobne kryterium przy wyborze dostawcy niż sama cena i wygoda.
9.Ekonomia destylacji podnosi cenę Twoich kluczy
Na czym polega: Laboratoria odcięte przez Anthropic i OpenAI (bany, weryfikacja tożsamości, blokady regionów) potrzebują danych pokazujących, jak czołowe modele rozwiązują zadania — bo na nich trenują własne. Stąd czarny rynek kluczy.
Jak stosować: Przy ocenie ryzyka uwzględnij, że Twój klucz jest warty więcej, niż wynikałoby z rachunku: monitoruj nietypowe wzorce użycia API, a nie tylko progi kosztów.
Na co uważać: Anthropic aktywnie wykrywa wzorce destylacji i tnie konta — także pośredników. Przypadkowe „pożyczanie” kluczy lub ich odsprzedaż może skończyć się blokadą Twojego konta.
10.Odmowy modeli nie są zabezpieczeniem — ani Twoim, ani niczyim
Na czym polega: Te same modele, które znajdują luki, często odmawiają pomocy w ich analizie i naprawie, biorąc użytkownika za potencjalnego napastnika. Atakujący omijają te odmowy otwartymi modelami, więc nikogo realnie nie chronią.
Jak stosować: Nie opieraj pracy bezpieczeńnościowej na doraźnych pytaniach do czatu — buduj procesy na narzędziach z jasnym kontekstem: przeglądach kodu, skanerach, dedykowanych ścieżkach do pracy z podatnościami.
Na co uważać: Paradoks sytuacji pogłębia ryzyko: napastnicy mają pełny dostęp do zdolności modeli, a obrońcy dostają odmowy.
Redakcyjne tłumaczenie
Wszystko się zawaliło — ale to dwie różne historie
PHP? Włamane. Node.js? Włamane. LiteLLM? Włamane. GitLab? Zgadliście. OpenCode? Bardziej „open-włamane”. A Railway? Zeszło z torów. Wygląda na to, że zhakowano właściwie wszystko — i to dlatego, że tak właśnie jest. To jeden z najgorszych dni w historii oprogramowania, jeśli liczyć, ile rzeczy naraz przestało być bezpiecznych. Od dłuższego czasu próbuję bić na alarm, więc wcale mnie nie dziwi, że modele językowe doprowadziły nas do punktu, w którym dzieje się to wszystko.
Szczerze mówiąc, lekko przesadzam w tym wprowadzeniu i mogłoby ono wprowadzać w błąd. Prawda jest taka, że naraz dzieją się dwie różne rzeczy. Z jednej strony CVE — w Node, GitLabie, PHP, Quick, LiteLLM i innych. To realne, używane codziennie projekty open source, cegły naszego stosu, w których odkryto luki dające się wykorzystać w naprawdę niebezpieczny sposób. Zwłaszcza PHP — obiecuję wrócić do skali problemu. Z drugiej strony mamy ataki: Railway i OpenCode nie mają z tamtą listą nic wspólnego, bo to nie raporty o usterkach, tylko faktyczne włamania. Obie kategorie są złe, ale z zupełnie różnych powodów — i moim zdaniem to te drugie powinny nas przerażać znacznie bardziej, choć wszyscy skupili się na pierwszych. Martwi mnie zwłaszcza sposób, w jaki opisuje się włamania do Railway i OpenCode, bo pomija się kluczowe „dlaczego” i „jak”. Początkowo chciałem nagrać dwa osobne filmy z wyraźną granicą między lukami a atakami, ale uznałem, że połowa ludzi obejrzy tylko jeden, a potem powie głupoty. Dlatego będzie jeden, dłuższy materiał. Formalnie rzecz biorąc, LiteLLM też było atakiem — doprecyzuję to za chwilę. Chcę zrobić wszystko, żebyście zrozumieli, co się naprawdę dzieje i czego powinnyśmy się bać. A kiedy wyobrażam sobie sekcję komentarzy pod tym filmem, czuję, jak opada mnie otępienie.
(Informacja dodatkowa: poniższy akapit to wbudowany w materiał segment sponsorski — pozostawiono go w skrócie, bo autor porusza w nim wątek istotny dla całości: odmowy modeli przy pracy nad bezpieczeństwem.)
Modele od laboratoriów takich jak Anthropic czy OpenAI wplątały nas w paradoks. Nigdy wcześniej nie było tak łatwo zbudować duży, skomplikowany system — ale te same narzędzia odmawiają pomocy w wyszukiwaniu luk, czyli w tym, co akurat najbardziej się liczy. Sponsor tego odcinka, Code Rabbit, twierdzi, że problem rozwiązał: dostajesz panel śledzący, gdzie i jak narastają problemy bezpieczeństwa, przegląd każdego pull requesta, a przede wszystkim „deep scan” — rzucasz go na repozytorium, czekasz godzinę i dostajesz szczegółowy raport, w którym wiele pozycji odpowiada znanym, opisanym podatnościom. Do tego przycisk naprawy jednym kliknięciem. Cały smutek polega na tym, że samodzielnie nie zawsze zmusisz do takich poprawek własnego agenta — Opus, Fable, Inso czy Astra odmawiają coraz większej części nowoczesnej pracy bezpieczeńnościowej.
Właśnie w trakcie nagrywania dołączył Oracle — CVE, wygląda na to, że nie atak, więc trafia do lewej kolumny. LiteLLM z kolei nie pasuje nigdzie: nie była to usterka w samym kodzie, lecz przejęcie GitHub Actions, dzięki któremu na wierzchu istniejącej paczki opublikowano zainfekowaną wersję. (Informacja dodatkowa: GitHub Actions to system automatycznych buildów; jego przejęcie pozwala podszyć się pod oryginalny projekt i rozprowadzić złośliwy kod.) Żeby nie rozdymać materiału, wyrzucam ten wątek. Ataki są najciekawsze i najważniejsze — ale mam wskaźniki oglądalności do utrzymania, więc zaczniemy od dzisiejszych CVE.
Czym są CVE i jak działa „okno podatności”
Dla niewtajemniczonych: CVE to finansowany rządowo program, który śledzi podatności odkrywane i zgłaszane w różnym oprogramowaniu, by można było ocenić wagę każdej sprawy i ją załatwić; w praktyce działa wspólna baza, przez którą firmy i produkty dzielą się wiedzą. (Informacja dodatkowa: każda podatność w tym rejestrze dostaje numer i ocenę wagi w skali 1–10.) Październikowa poprawka bezpieczeństwa Node.js pokazuje, jak to działa: obejmuje linie 20, 22, 24 i 26, a w środku są m.in. luki w OpenSSL (dotyczące linii 24 i 22), podatność w bibliotece DNS używanej przez Node oraz poprawki związane z SQLite i certyfikatami po kompromitacji jednego z urzędów certyfikacji — firmy uprawnionej do wydawania certyfikatów SSL, której klucz prywatny ustawiono dosłownie na wartość „4”. Cztery to ładna liczba, ale tragiczne hasło. Skutki odczuje wszystko, co uznawało jej certyfikaty: przeglądarki muszą pójść na najnowszą wersję, a wydane przez ten urząd certyfikaty przestały obowiązywać.
Przy okazji ważna rzecz o samym mechanizmie: wiele z tych raportów wpłynęło dawno temu, a publicznie pokazano je dopiero teraz, bo firmy omawiają sprawy najpierw prywatnie. Najbardziej niebezpieczny jest moment pomiędzy wydaniem poprawki — gdy każdy może zobaczyć kod i domyślić się, co załatano — a chwilą, gdy użytkownicy faktycznie mają bezpieczną wersję. Historycznie to okno było mniej groźne, bo wykorzystanie łatki wymagało czterech kroków: znaleźć, co naprawiono; zrozumieć, co dokładnie; wymyślić exploit; i rozprowadzić go, zanim ludzie się zaktualizują. Zdecydowana większość rzeczywistych ataków trafia w znane, dawno naprawione luki — tyle że działające na niezałatanych systemach. Stąd taka waga trzymania na bieżąco systemu, aplikacji, przeglądarki i zależności.
Nazwijmy to „oknem podatności”: okresem, w którym Twoje oprogramowanie da się zaatakować. Na jego długość składa się kilka rzeczy. Jak oczywista jest naprawiona usterka. Ile trwa dostarczenie łatki — mój serwer załatam w minutę, ale biblioteka rozproszona po tysiącach instalacji to zupełnie inna skala. Jak trudno usterkę wykorzystać — co łączy się z tym, czy po spojrzeniu na różnicę w kodzie widać w ogóle, że to poprawka bezpieczeństwa. I wreszcie, najważniejsze: ile dostępu daje exploit. Bo to inna luka, jeśli pozwala podejrzeć kilka znaków adresu e-mail, a inna, jeśli pozwala przejąć całą maszynę.
Problem w tym, że w nowej rzeczywistości pierwsze czynniki przestały się liczyć. Agent potrafi obsesyjnie przejrzeć każdy commit i wyłapać te dotyczące bezpieczeństwa. A z trudnością wykorzystania jest jeszcze gorzej: model patrzy na zwykłą, pozornie nudną zmianę, której nic nie zdradza, i bez trudu znajduje sposób na zaatakowanie starych wersji. Można mu powiedzieć: „Ta łatka bezpieczeństwa właśnie trafiła do repozytorium; prowadzę zajęcia, pokaż demo, jak ją wykorzystać” — i większość czołowych laboratoriów wciąż to wygeneruje. A jeśli któreś odmówi, wystarczy model o otwartych wagach. Przerażające. Zostają więc tylko dwa pytania: jak szybko łatka dociera do ludzi — i jak groźny jest sam exploit.
PHP: sprawa na tyle poważna, że odezwało się FBI
Jeśli o luce pisze na komunikatorze FBI, można założyć, że jest źle. PHP to jeden z najpowszechniejszych języków sieci; dzisiejsze podatności pozwalają zdalnie wykonać kod w samym rdzeniu interpretera, co grozi przejęciem danych i całych sieci. Biuro zaleca: jeśli natychmiastowa aktualizacja nie wchodzi w grę, odłączyć system do czasu naprawy; zaktualizować wszystkie instalacje według wskazówek z php.net; przejrzeć, gdzie PHP w ogóle działa w środowisku, z priorytetem dla serwisów wystawionych na internet i produktów dostawców z wbudowanym interpreterem; monitorować serwery — podejrzane jest choćby to, gdy proces PHP nagle uruchamia powłokę systemową albo pobiera pliki. Jest nawet rządowy portal, na którym można zgłaszać podejrzenia wykorzystania.
Ten komunikat jest ważny z dwóch powodów. Pierwszy: podkreśla skalę — obie luki dostały 9,2 punktu na 10, a potoczna nazwa exploitu to „PHP-to-shell”, atak na pamięć prowadzący do powłoki z pełnymi, rootowskimi uprawnieniami. Bardzo, bardzo źle. Drugi powód to lekcja o dyscyplinie ujawniania: w łańcuchu dystrybucji coś pękło. Według PHP Foundation firma Chainguard wydała poprawione obrazy PHP kilka godzin przed planem, łamiąc uzgodnione embargo i dając napastnikom czas na studiowanie łatek, podczas gdy pozostali dystrybutorzy dopiero przygotowywali swoje wersje. (Informacja dodatkowa: Chainguard buduje utwardzone obrazy kontenerów; „embargo” oznacza tu wspólny, uzgodniony między dostawcami harmonogram publikacji poprawek.) W erze agentów samo opublikowanie łatki to gotowy materiał wyjściowy do ataku — wiedza, która wyjdzie na świat za wcześnie, jest prawie równoznaczna z wręczeniem exploita. Poza PHP dzisiaj trafione były także GitLab, Quick i Oracle.
Luki znalazł słaby model — i znalazły dwie niezależne strony
Dwie rzeczy w odbiorze tej historii wyjątkowo mnie irytują. Pierwsza to wpisy w stylu „PHP napędza 70% internetu, czyli zawaliło się wszystko” — do tego wrócę. Druga: podatności nie wykrył żaden najnowszy model — wykrył je GPT 5.6 Soul. To pokazuje dwie sprawy naraz: jak długa bywa droga od zgłoszenia do publikacji oraz że nawet model tak przeciętny jak 5.6 Soul potrafi takie luki znaleźć. A otwartych modeli o zbliżonych możliwościach jest już na rynku kilka. Jesteśmy w poważnych tarapatach. Do tego ten sam zestaw podatności niezależnie odkryła i zgłosiła firma Wiz. (Informacja dodatkowa: Wiz to jedna z największych firm bezpieczeństwa chmury.) Gdy o luce wie jedna strona — w porządku, niech zostanie naprawiona, zanim wyjdzie na jaw. Gdy dwie trafiają na nią niezależnie, znaczy to, że trafiają też kolejne. Przypomina to niedawną sytuację, gdy cztery niezależne zespoły w podobnym czasie przepisały TypeScript w Ruście. Jeśli jedna grupa potrafi zmusić współczesne modele do znalezienia exploita, można założyć, że innych grupom udaje się to mniej więcej równolegle. Prywatne ujawnianie luk jako mechanizm ochrony po prostu przestaje działać. Wszystko się sypie — to chcę powiedzieć.
„70% internetu” — statystyka, która nic nie mówi
Jest jednak malutkie światełko w tej całej aferze z „70% stron”. Cały dzień próbowałem wymyślić dobrą analogię, która pokaże, jak głupia to statystyka. Mam ją.
Czy wiedzieliście, że przeciętny człowiek spędza przed ekranem mniej niż godzinę rocznie? Wiem, brzmi absurdalnie — ale wystarczy uśrednić po wszystkich ludziach, którzy kiedykolwiek żyli, a liczba spada drastycznie. Dokładnie tak samo głupie jest mierzenie „stron internetowych” po liczbie adresów obsługiwanych przez PHP, bo zdecydowana większość stron w internecie jest martwa. Przeglądam właśnie otwarte karty: Railway — nie PHP. Czat YouTube, który i tak muli — nie PHP. Twitter — nie PHP. Twitch, przeżyłem już z nim różne rzeczy — nie PHP. GitHub — nie PHP. YouTube — nie PHP. Moje własne narzędzia — nic z tego nie jest PHP. Chcę powiedzieć: tak, formalnie 70% adresów obsługuje PHP, ale to liczba bez wartości, bo te strony nie mają żadnego ruchu. Nie obchodzi mnie, czy czyjś porzucony blog na WordPressie z 2014 roku został włamany. Naprawdę nie obchodzi. Czy to zła wiadomość dla zachowania sieci jako archiwum? Owszem — ale WordPress już wcześniej był złą wiadomością: to ponad połowa wszystkich stron, rzecz bardziej krucha niż samo PHP. Sam tego doświadczyłem: w liceum zrobiłem wujkowi stronę dla jego małej firmy wędkarskiej, potem o niej zapomniałem i została zaorana przez włamania, bo nikt jej nie utrzymywał. Realny problem to nie martwe strony, tylko porzucona opieka: strony po ludziach, którzy odeszli, serwisy po byłych pracownikach, przypadkowe projekty rządowe. To jest naprawdę poważna sprawa. Ale zdecydowana większość stron z faktycznym ruchem nie używa PHP — więc nie dajcie się przestraszyć tym „70%”, bo nikt przy zdrowych zmysłach tak nie liczy.
Atak na OpenCode: chodziło o klucze API
To był less interesting, mniej przerażający etap — przejdźmy do ataków. OpenCode padło kilka dni temu. Nie chodziło o dostęp do Twoich danych: narzędzie działa na Twoim urządzeniu i samo z siebie zbiera ich niewiele. Łupem padły klucze API — nie własne OpenCode, te od razu unieważnili, lecz te „przyniesione własne”, które użytkownicy zapisali w panelu po stronie serwera. Klucze do Anthropic, OpenAI, Gemini i pozostałych mogły wyciec — i często rzeczywiście wyciekły oraz zostały wykorzystane. Programiści zgłaszali wyzerowane konta OpenAI i zużyte salda; straty wahały się od 400 do 3000 dolarów, wszystko w ciągu minut od wykrycia klucza. Masa osób oberwała banami, masa straciła pieniądze. Na szczęście OpenCode mocno współpracuje z laboratoriami: zwroty środków, przywracanie kont, automatyczna rotacja kluczy.
I tu nasuwa się pytanie: po co ktoś włamuje się do OpenCode po klucze, które za kilka minut i tak umierają? Odpowiedź brzmi: bo dokładnie to samo zrobiono Railway.
Railway: włamanie i — osobno — awaria, która z włamaniem nie ma nic wspólnego
Komunikat Railway mówi, że rano wykryto anomalie w systemach przechowujących zmienne środowiskowe klientów; śledztwo wskazuje, że niepowołana strona mogła dostać się do zaszyfrowanych zmiennych, a część z nich odszyfrować. Zmienne środowiskowe potrafią zawierać sekrety: klucze API, dane logowania do baz i rejestrów.
To mnie osobiście wkurzyło, bo mam na Railway sporo projektów i wszystko właśnie leży. Nie tylko dlatego, że sekrety przeciekły: platforma ściągnęła też wdrożenia i po rotacji kluczy nie mogę wdrożyć usług na nowo. Właśnie dlatego rozdzielam tę historię na dwie osobne: kradzież zmiennych środowiskowych — to samo, co w OpenCode — oraz pełną awarię wdrożeń. Rozdzielam je świadomie, bo mam obowiązek wytknąć sponsorom, gdy nawalają. Z kradzieżą kluczy bywa: gdzie są dane wrażliwe, tam będą łowcy; do tego wątku zaraz wrócę. Ale niemożność wdrożenia to co innego. Nagrywam o 17:30, a wdrożenia nie działają od pierwszej w nocy. Szesnaście godzin. To nie jest skutek włamania — włamanie mogło co najwyżej wywołać ich reakcję, ale to, że klienci nie mogą naprawić własnych usług, to nieudolność Railway. Chętnie się mylę, ale już nie raz się na nich przejechałem i zastanowię się, czy hostingować u nich cokolwiek ważnego w przyszłości. Te słowa kosztują mnie dziesiątki tysięcy dolarów, bo mam z nimi dwie zawieszone umowy reklamowe — w tym jedną nagraną niedawno, na którą miałem ochotę, bo szczerze lubię tę platformę: świetny stosunek ceny do możliwości, a ich magazyn plików S3 to jedna z najlepszych tego typu usług, z której chętnie korzystają też moje agenty. Ale to jest nie do obrony. To nie pierwszy raz. Railway to konsekwentnie jeden z najmniej stabilnych elementów mojej infrastruktury — zaczyna doganiać GitHuba. A gdyby ktoś wspominał fly.io: to jedna z niewielu marek, z którymi zerwałem współpracę, bo platforma waliła się nawet w trakcie nagrywania reklam. Czego polecam zamiast tego — jeszcze nie wiem, odezwę się. Idea jest taka: pełna awaria wdrożeń ma niewiele wspólnego z hakerami, a bardzo dużo z samym Railway.
Dlaczego klucze API? Destylacja
Zostaje więc rzecz, która naprawdę się tu liczy: klucze. Po co komu klucz działający kilka godzin? Gdybym miał wybierać między kluczem z nieograniczonym użyciem przez jeden dzień a kluczem działającym rok ze stu dolarami zużycia dziennie — wziąłbym ten roczny bez wahania, nawet gdyby miał działać tylko miesiąc. Nie umiem sobie wyobrazić, co zrobiłbym z milionami dolarów wydanymi na odpytywanie modeli w ciągu doby. A skradzione klucze i tak szybko zostają unieważnione. Kto w takim razie chce nieograniczonego dostępu na kilka godzin?
W sieci krążą domysły: scamerzy generujący odpowiedzi — ale to robi się za grosze na otwartych modelach, nie warto w tym celu spalać włamań; hakerzy używający kluczy do kolejnych ataków; „crypto” — bzdura. Jest tylko jeden powód. Powtórzcie za mną: destylacja.
Wyobraźcie sobie laboratorium AI budujące nowy, bardzo zdolny model. Nazwijmy je całkowicie losowo… Seep Deek. (Informacja dodatkowa: wymyślona nazwa ewidentnie nawiązuje do DeepSeek.) Jako badacz w Seep Deek chcesz używać najlepszych dostępnych narzędzi, więc rejestrujesz się u dostawcy czołowego modelu — nieważne, jak go tu nazwiemy, mówmy po prostu: Claude. Chcesz go do pracy, do danych, do wszystkiego, bo Twoim celem jest model o możliwościach zbliżonych do Claude’a. I Anthropic doskonale o tym wie: dane z Claude’a są przydatne nie tylko jako pomoc w pisaniu kodu, ale przede wszystkim jako materiał treningowy. Mając dość przykładów tego, jak Claude rozwiązuje problemy, można zdziałać niesamowite rzeczy.
Surowa prawda jest taka, że klasycznych danych treningowych trudno się dziś dorwać — internet został pozamykany — a poza tym dane z sieci są coraz mniej wartościowe do zadań agentskich, bo nigdzie nie ma zbyt wielu przykładów tego, jak agent rozwiązuje zadanie, gdy jego sposób zaczyna odbiegać od ludzkiego, zwłaszcza w terminalu. Dane pokazujące, jak duży model radzi sobie ze złożonymi zadaniami przy użyciu narzędzi, trzeba w praktyce wytworzyć. I właśnie dlatego tak wiele firm chce zebrać całą Twoją historię rozmów z Claude’em i modelami OpenAI: mogą na niej doszlifować własne modele o podobnych możliwościach. To pozwola reszcie rynku gonić dwójkę liderów szybciej — bez budowania od zera całej infrastruktury, w której takie dane w ogóle powstają.
Skoro tak, czemu po prostu nie kupią tokenów? Bo po drugiej stronie dostają bana. Anthropic konsekwentnie blokuje próby chińskich laboratoriów zbierania danych do destylacji; banowali nawet firmy z USA — Windsurf tymczasowo, gdy podejrzewali, że przejmie go OpenAI. (Informacja dodatkowa: Windsurf to amerykański dostawca asystentów programistycznych.) Oficjalnie: nie chcą, by inni trenowali zbliżone modele, bo nie zagwarantują tego samego poziomu bezpieczeństwa. Moim zdaniem to mieszanka tej troski z ochroną własnego monopolu. Efekt: istnieje ogromny popyt podmiotów typu nasz hipotetyczny Seep Deek, gotowych płacić fortuny za tokeny Claude’a — a Claude odmawia sprzedaży. I nie tylko odmawia: tnie też firmy wyglądające całkiem uczciwie, jeśli podejrzewa, że odsprzedają dalej dane i tokeny. W grę wchodziło kilka firm z Korei Południowej, płacących Anthropic ogromne pieniądze — część była nawet inwestorem — a zostały odcięte, bo istniały podstawy, by sądzić, że przez ich klucze chińskie laboratoria pozyskują dane do destylacji.
Anthropic rozwinął przy tym całą baterię zabezpieczeń: wykrywanie wzorców zapytań typowych dla destylacji, procedury „poznaj swojego klienta” — weryfikację dowodem, prawem jazdy albo paszportem; progi użycia API zależne od wieku konta i dotychczasowego zużycia; rzeczy dostępne wyłącznie dla starych kont; wreszcie twarde blokady adresów IP i regionów, by utrudnić rejestrację i korzystanie z API m.in. z Chin. Czyli Seep Deek nie po prostu założy sobie konta u Claude’a. To zaś otwiera okazję dla pośredników. Jeśli jesteś hakerem albo po prostu nieuczciwym graczem, potrzebujesz jedynie porcji kluczy API. Bez kart płatniczych, bez fałszywych tożsamości. Wystarczą klucze, o których ludzie zapomnieli — bo z nimi masz wszystko, czego trzeba, by wygenerować masę tokenów. Konto w końcu poleci, jasne, ale zdążysz dużo zrobić, i to na cudzy rachunek. Stąd tak wielki popyt na klucze Claude i OpenAI tkwiące na słabo pilnowanych kontach. Powiem szczerze: sam kiepsko monitoruję nasze zużycie w OpenAI i dziś, po włamaniu do Railway, nerwowo sprawdzałem, czy któreś z moich kont nie zostało trafione, bo nie musiałem tego robić od dawna.
Chińskie laboratoria i inne podmioty chcące budować modele zachowujące się jak Claude bardzo mocno starają się zdobyć tę wiedzę — i przestanę udawać, że tak nie jest, bo oczywiste jest, że jest. To jest jedna z takich prób. Odmowa sprzedaży tokenów ma więc dziwny skutek uboczny: użytkownicy, klienci i platformy typu Railway czy OpenCode stali się celami w stopniu dotąd nieznanym. Włamanie do Railway przed erą AI niewiele by dało: wszyscy trzymali tam klucze, ale zanim wyciągniesz z baz cokolwiek użytecznego, jesteś wyrzucany — i co ci z tego? Natomiast garść haseł, z których każde wygeneruje od stu do kilku tysięcy dolarów wartości, zanim je zabiją, a potem tanio sprzedasz podmiotom o wątpliwych zamiarach — to już okazja jakich mało. Każda platforma przechowująca klucze API jest dziś celem, bo na czarnym rynku panuje na nie ogromny popyt. Powinienem dodać Gemini, ale powiem szczerze: nie sądzę, żeby ktokolwiek próbował destylować Gemini. Nawet Google.
Będzie gorzej, zanim będzie lepiej
Wszystko jest w kiepskim stanie i mam złe przeczucie: zanim będzie lepiej, najpierw będzie gorzej. Dziwnie brzmi stwierdzenie, że niechęć Anthropic do sprzedawania tokenów sprawia, że pośrednicy zbierają ciosy — ale dokładnie to się dzieje, i wielu z nas oberwie kulą postrzeloną. Czy Anthropic postępuje słusznie — można dyskutować; uważam, że jako firma ma prawo wybierać, komu sprzedaje. Po prostu skutkiem ubocznym tego wyboru jest piekło, w którym my — klienci i twórcy — dostajemy po kieszeni. I wisienka na torcie: nie możemy użyć modeli OpenAI czy Anthropic, żeby zdiagnozować i naprawić własne systemy, bo zaczną odmawiać, biorąc nas za hakerów. Laboratoria wpędziły nas w tę sytuację i nie kwapią się z pomocą. Będzie źle i nie będzie lepiej — najpierw będzie znacznie gorzej. Pół roku temu w podcaście mówiłem, że zostało nam trzy do dziewięciu miesięcy. Dziwne, jak dobrze trafiłem.
I ostatnie, bo już przewiduję komentarze — choć ci, którzy je piszą, zwykle nie doczekają do tego miejsca: jeśli uważasz, że luki w PHP i włamania do Railway czy OpenCode są ze sobą powiązane, mam nadzieję, że nie przywiązujesz się zanadto do zawodu programisty, bo Claude zastąpi cię bardzo szybko. Te sprawy nie mają ze sobą nic wspólnego i nie mam nic więcej do dodania.
Mam wrażenie początku końca, więc to chyba dobry moment, żeby skończyć. Serio: zabezpieczajcie swoje rzeczy. Trzymajcie wszystko na aktualnych wersjach, śledźcie, co się dzieje, i dopilnujcie, by klucze API były dobrze chronione, rozdzielone i łatwe do unieważnienia — bo zrobi się o niebo gorzej, zanim zrobi się lepiej. To wszystko, co mam do powiedzenia.
Do zobaczenia, nerdzi.