500 dolarów w bitcoinach i publiczny serwer PHP: co eksperyment stealmybitcoin.com mówi o realnym ryzyku podatności PHP2Shell

W ostatni weekend października 2026 roku badacz bezpieczeństwa opublikował na blogu pavursec.com relację z eksperymentu „stealmybitcoin.com”. Wynajął tani serwer VPS, umieścił na nim aplikację PHP i klucz do portfela bitcoin o wartości 500 dolarów, po czym zaprosił publiczność do kradzieży środków. W ciągu około 26 godzin serwer odwiedziło ponad 120 tysięcy unikalnych adresów IP, które wygenerowały ponad 13 milionów żądań HTTP. Tylko dwa adresy IP zdołały uruchomić przygotowaną przez autora binarkę, a tylko jeden uczestnik wydobył z serwera użyteczne dane i zgłosił się po nagrodę.

Eksperyment dotyczy bezpośrednio firm i instytucji utrzymujących aplikacje w PHP — a więc znacznej części polskiego rynku hostingowego, e-commerce i systemów wewnętrznych. Jego wartość polega na tym, że zestawia narrację o krytycznej podatności PHP2Shell, opisaną przez autora jako alarmująca relacja w „New York Times”, z twardymi liczbami z kontrolowanego środowiska. Wniosek nie brzmi „podatność jest niegroźna”. Brzmi raczej: realna eksploatacja wymaga precyzyjnego dopasowania do konfiguracji ofiary, a masowe skanowanie sieci nie przekłada się automatycznie na masowe przejęcia. To zmienia sposób, w jaki należy priorytetyzować łatki.

Co dokładnie się wydarzyło

Autor wpisu „Observations from Running stealmybitcoin.com” z 30 października 2026 roku opisuje eksperyment zbudowany wokół prostego pytania: czy podatność PHP2Shell jest realnie eksploatowalna poza laboratorium i czy osoby o niskich umiejętnościach, wspierane modelem AI oraz kodem źródłowym PHP, potrafią ją wykorzystać. Odpowiedzi, które sam formułuje, są dwie i warto je rozdzielić, bo bywają mylone w dyskusjach.

• Czy podatność jest eksploatowalna w realnym internecie? Tak. Zwycięzca wyzwania wykorzystał dokładnie tę podatność przez otwarte połączenie internetowe, dopasowując exploit do konkretnej konfiguracji instalacji PHP na serwerze.
• Czy osoby o niskich umiejętnościach z dostępem do AI już to potrafią? Jeszcze nie. Z dziesiątek tysięcy prób tylko dwie uruchomiły binarkę, a tylko jedna zakończyła się wydobyciem danych.

Autor zastrzega, że jego statystyki ruchu są niepełne z powodu problemów z monitorowaniem. Pełne logi obejmują około 600 z około 1600 minut trwania wyzwania. Dane o błędach PHP i uruchomieniach binarki są natomiast opisane jako kompletne, bo generowały mały wolumen i nie podlegały rotacji pod obciążeniem. To rozróżnienie jest istotne: liczby dotyczące ruchu należy traktować jako przybliżone, liczby dotyczące sukcesów — jako wiarygodne.

Tło techniczne bez żargonu

PHP to język programowania napędzający dużą część stron internetowych. Aplikacja PHP działa na serwerze jako proces, który przyjmuje żądania od przeglądarki i zwraca odpowiedzi. Podatność klasy „remote code execution” oznacza, że atakujący może doprowadzić do uruchomienia własnego kodu w kontekście tego procesu — a więc z uprawnieniami, jakie ma aplikacja.

W eksperymencie autor celowo ustawił środowisko tak, by sukces był możliwy, ale wymagał pracy. Klucz do portfela zapisano w pliku, do którego odczytu uprawniona była wyłącznie jedna binarka o nazwie print-flag. Firewall wyłączono. Innymi słowy: nie było dodatkowych warstw ochrony, które trzeba by obejść, ale samo uruchomienie kodu nie wystarczało — trzeba było jeszcze zmusić serwer do wykonania konkretnego programu z odpowiednimi uprawnieniami.

To rozróżnienie tłumaczy, dlaczego tysiące prób nie dały tysięcy sukcesów. Skanery i automaty wysyłają żądania według schematów, które działają na typowych instalacjach. Gdy konfiguracja odbiega od schematu, exploit trzeba dostroić. W relacji widać to wprost: zwycięzca przygotował exploit „targeted the specific configuration of my PHP installation”.

Dlaczego serwer padał pod obciążeniem

Autor rozpoczął od VPS za 2,50 dolara miesięcznie z 1 vCPU, 500 MB RAM i 10 GB dysku. Po publikacji linku na Hacker News serwer trafił na stronę główną i pozostał tam niemal cały dzień. Autor nie mógł utrzymać sesji SSH. Skalował maszynę do 2 vCPU, 4096 MB RAM i 80 GB SSD. Hosting dwukrotnie tymczasowo wyłączył stronę: raz z powodu podejrzenia ataku DDoS, raz z powodu nadmiernego zużycia CPU.

W szczycie serwer odbierał ponad 18 tysięcy żądań na minutę. Logi rotowały się co około 4 minuty. Odnotowano około 2075 zdarzeń SIGSEGV w PHP — czyli awarii procesu — które autor wiąże z próbami bliższymi wywołania podatności, choć zastrzega, że mogą mieć inne przyczyny. To pokazuje, jak wygląda realny ruch wokół głośnej podatności: głównie hałas, częściowo testy, wśród nich pojedyncze precyzyjne trafienia.

Fakty, deklaracje i interpretacje

Warto rozdzielić trzy warstwy materiału, bo w dyskusji publicznej zlewają się w jeden przekaz.

Warstwa	Co mówi materiał	Jak traktować
Fakt z eksperymentu	Jeden uczestnik wykorzystał podatność przez internet i wydobył dane; dwa adresy IP uruchomiły binarkę	Potwierdzone logami i weryfikacją autora
Deklaracja autora	Osoby o niskich umiejętnościach z AI „jeszcze nie” potrafią wykorzystać tę klasę podatności	Opinia oparta na jednym eksperymencie, nie badanie populacyjne
Interpretacja	Medialna narracja o natychmiastowej apokalipsie rozminęła się z praktyką	Wniosek autora; warto zestawić z własnym kontekstem

Autor powołuje się na doniesienia „New York Times” o krytycznej podatności PHP oraz na komentarze Eliasa Taylora, Lucasa Luitjesa i firmy KELA, według których eksploatacja jest w praktyce trudna i grupy przestępcze zaczęły postrzegać ją jako niepraktyczną. Tych doniesień nie zweryfikowaliśmy niezależnie w ramach tego tekstu — traktujmy je jako twierdzenia przywołane przez autora, nie jako ustalenia redakcji.

„Z dziesiątek tysięcy prób tylko dwie wywołały binarkę print-flag, a tylko jedna pozwoliła uzyskać użyteczną treść z aplikacji” — to zdanie z relacji autora jest najlepszym podsumowaniem różnicy między zasięgiem a skutecznością.

Realne konsekwencje dla organizacji

Najważniejszy wniosek nie dotyczy samej podatności, lecz modelu zagrożenia. Masowe kampanie skanujące sieć są tanie i głośne, ale rzadko kończą się sukcesem bez dopasowania do celu. To oznacza, że ryzyko dla konkretnej firmy zależy mniej od tego, czy „wszyscy już exploitowali”, a bardziej od tego, czy jej konfiguracja jest wystarczająco typowa, by pasować do gotowych narzędzi.

Drugi wniosek dotyczy higieny uprawnień. W eksperymencie klucz był czytelny tylko dla jednej binarki. To nie uchroniło serwera przed zwycięzcą, ale znacząco zawęziło liczbę osób, którym się udało. W realnych systemach analogiczna zasada — minimalne uprawnienia procesów, brak zbędnych binarek w katalogach aplikacji, izolacja sekretów — przekłada się na to, ile trzeba zrobić po uzyskaniu pierwszego dostępu.

Trzeci wniosek dotyczy monitoringu. Autor odróżnił logi kompletne od niekompletnych i uczciwie oznaczył ograniczenia. W firmie warto zrobić to samo: wiedzieć, które źródła danych są wiarygodne w warunkach przeciążenia, a które zawodzą dokładnie wtedy, gdy najbardziej ich potrzebujesz.

Scenariusze ryzyka

Scenariusz 1: typowa instalacja, szybka eksploatacja

Jeśli aplikacja działa na standardowej konfiguracji, a poprawka nie została wdrożona, gotowe narzędzia mogą zadziałać bez dostrajania. To scenariusz, w którym liczy się czas reakcji, a nie analiza.

Scenariusz 2: nietypowa konfiguracja, konieczne dostrojenie

Niestandardowe wersje, rozszerzenia i uprawnienia zmniejszają szansę na przypadkowy sukces, ale nie eliminują ryzyka. W eksperymencie wystarczyło jedno precyzyjne trafienie, by nagroda została wypłacona.

Scenariusz 3: hałas maskujący realny atak

Gdy wokół podatności narasta szum, zespoły mogą zignorować pojedyncze nietypowe zdarzenia jako część tła. W eksperymencie sukces przyszedł w środku masowego ruchu i został wychwycony dzięki logom uruchomień binarki.

Scenariusz 4: presja medialna kontra ograniczone zasoby

Nagłówki o „70% internetu” mogą skłonić do chaotycznego łatania wszystkiego naraz. Lepszym podejściem jest inwentaryzacja i kolejność według ekspozycji.

Jak sprawdzić, czy problem dotyczy Twojej organizacji

1. Ustal, które systemy produkcyjne działają w PHP i w jakich wersjach. Wersję można odczytać z konfiguracji serwera i z metadanych pakietów, nie z publicznie dostępnych stron.
2. Sprawdź, czy systemy są wystawione bezpośrednio do internetu, czy stoją za reverse proxy lub WAF.
3. Zweryfikuj, czy poprawki bezpieczeństwa są wdrażane w cyklu regularnym, czy dopiero po incydencie.
4. Przejrzyj uprawnienia procesów aplikacji: czy mają dostęp do plików z sekretami, czy w katalogach aplikacji znajdują się zbędne binarki.
5. Sprawdź, czy logi aplikacji i serwera są odporne na rotację pod obciążeniem i czy zawierają zdarzenia awarii procesów.
6. Ustal, kto w organizacji odpowiada za decyzję o pilnym wdrożeniu łatki i w jakim czasie może ją podjąć.

Plan reakcji krok po kroku

1. Inwentaryzacja. Spisz systemy PHP, ich wersje, ekspozycję sieciową i właścicieli. Bez tego każdy dalszy krok będzie zgadywaniem.
2. Priorytetyzacja. Najpierw systemy publiczne z danymi wrażliwymi lub płatnościami, potem publiczne bez danych, na końcu wewnętrzne.
3. Wdrożenie poprawek. Zaplanuj okno wdrożeniowe i test regresji. Jeśli poprawka wymaga restartu, uwzględnij to w komunikacji z biznesem.
4. Ograniczenie ekspozycji. Tam, gdzie wdrożenie się opóźnia, rozważ ograniczenie dostępu sieciowego lub dodatkową warstwę pośrednią.
5. Weryfikacja. Po wdrożeniu potwierdź wersję i konfigurację na środowisku produkcyjnym, nie tylko na testowym.
6. Monitoring. Zwiększ czułość na awarie procesów aplikacji i nietypowe żądania w okresie okołopublikacyjnym.
7. Dokumentacja. Zapisz, co wdrożono, kiedy i z jakim skutkiem. To skróci kolejną reakcję.

Typowe błędy

• Łatanie wszystkiego naraz bez inwentaryzacji. Prowadzi do pominięcia systemów, które wypadły z ewidencji.
• Traktowanie braku doniesień o atakach jako dowodu bezpieczeństwa. Brak dowodów to nie dowód braku.
• Poleganie wyłącznie na WAF. Warstwa pośrednia pomaga, ale nie zastępuje poprawki.
• Testowanie tylko na środowisku przedprodukcyjnym. Różnice konfiguracji między środowiskami są regułą, nie wyjątkiem.
• Ignorowanie logów awarii procesów. W eksperymencie SIGSEGV były jednym z niewielu sygnałów aktywnych prób.
• Odkładanie decyzji o priorytetach na czas po publikacji. Wtedy zwykle brakuje rąk do pracy.

Działania krótkoterminowe i długoterminowe

Krótkoterminowo (dni)

• Zidentyfikuj publiczne systemy PHP i potwierdź ich wersje.
• Wdróż dostępne poprawki w systemach o najwyższej ekspozycji.
• Zwiększ monitoring awarii procesów i nietypowych żądań.
• Sprawdź uprawnienia procesów aplikacji i dostęp do plików z sekretami.

Długoterminowo (tygodnie i miesiące)

• Wprowadź regularny cykl aktualizacji zamiast reagowania na nagłówki.
• Uporządkuj zarządzanie sekretami: rotacja, separacja, minimalne uprawnienia.
• Zbuduj inwentarz zależności i właścicieli systemów.
• Przetestuj procedurę reakcji na krytyczną podatność, zanim będzie potrzebna.
• Ustal kryteria eskalacji: kiedy wdrażamy poza godzinami pracy, a kiedy czekamy do okna serwisowego.

Checklista praktyczna

• ☐ Znam wersje PHP wszystkich systemów produkcyjnych.
• ☐ Wiem, które systemy są wystawione bezpośrednio do internetu.
• ☐ Mam listę właścicieli systemów i kontakt do nich.
• ☐ Poprawki bezpieczeństwa są wdrażane w zaplanowanym cyklu.
• ☐ Procesy aplikacji mają minimalne uprawnienia.
• ☐ Sekrety nie leżą w katalogach dostępnych dla aplikacji bez potrzeby.
• ☐ Logi przeżywają przeciążenie i rotację.
• ☐ Mam zdefiniowane kryteria pilnego wdrożenia.
• ☐ Wiem, jak potwierdzić skuteczność wdrożenia na produkcji.

Co powinien zrobić właściciel firmy / administrator

Właściciel firmy: nie podejmuj decyzji o priorytetach na podstawie nagłówków. Zapytaj zespół o inwentarz systemów PHP, o to, które są publiczne, i o realny czas wdrożenia poprawki. Ustal, kto ma mandat do decyzji o wdrożeniu poza godzinami pracy. Zaakceptuj, że część systemów może wymagać ograniczenia ekspozycji, zanim poprawka zostanie wdrożona.

Administrator: potwierdź wersje i konfiguracje na produkcji, nie tylko w dokumentacji. Wdróż poprawki najpierw tam, gdzie ekspozycja jest największa. Sprawdź uprawnienia procesów i dostęp do sekretów. Zwiększ czułość monitoringu na awarie procesów. Po wdrożeniu zweryfikuj stan faktyczny i zapisz wynik. Jeśli poprawka nie może zostać wdrożona natychmiast, ogranicz dostęp sieciowy do czasu jej zastosowania.

Eksperyment z serwerem za 2,50 dolara nie dowodzi, że podatności PHP można ignorować. Dowodzi czegoś innego: że odległość między „każdy może to wykorzystać” a „jedna osoba na dziesiątki tysięcy prób zdołała” jest duża i zależy od konfiguracji. Dla organizacji oznacza to, że porządek w inwentarzu, uprawnieniach i monitoringu waży więcej niż panika — zarówno wtedy, gdy zagrożenie jest realne, jak i wtedy, gdy narracja wyprzedza praktykę.

Praktyczna weryfikacja wdrożonych poprawek

Weryfikacja nie kończy się na komunikacie „wdrożono”. W eksperymencie autora kluczowe okazało się potwierdzenie, że konkretna konfiguracja serwera i sposób osadzenia PHP odpowiadają za podatność — zwycięzca wykorzystał exploit dopasowany do tej konkretnej instalacji, a nie uniwersalny. Ta sama zasada obowiązuje przy sprawdzaniu poprawek: potwierdzenie musi dotyczyć rzeczywistej konfiguracji produkcyjnej, a nie założeń z dokumentacji.

Potwierdzenie wersji i konfiguracji na produkcji

• Odczytaj wersję PHP z metadanych pakietów i konfiguracji serwera na każdym hoście produkcyjnym, nie z arkusza inwentarzowego.
• Porównaj wynik z listą systemów, które miały zostać zaktualizowane. Każda rozbieżność to system poza kontrolą.
• Sprawdź, czy poprawka przetrwała restart usług i czy nie została nadpisana przez starszy pakiet przy okazji innego wdrożenia.
• Zweryfikuj, czy konfiguracja nie zawiera niestandardowych rozszerzeń ani ustawień, które w eksperymencie decydowały o tym, czy exploit w ogóle zadziała.

Test odtwarzający warunki ataku

Skoro podatność okazała się „raczej fiddly w praktyce” i wymagała dostrojenia do konkretnej instalacji, test weryfikacyjny powinien odtwarzać warunki zbliżone do produkcyjnych, a nie laboratoryjne. Warto sprawdzić, czy po wdrożeniu poprawki próba wykorzystania znanego wektora kończy się niepowodzeniem również przy konfiguracji nietypowej — bo właśnie nietypowe konfiguracje były w eksperymencie tymi, które wymagały od atakującego dodatkowej pracy.

Weryfikacja uprawnień po wdrożeniu

W eksperymencie klucz do portfela był czytelny tylko dla jednej binarki, co zawęziło grono potencjalnych zwycięzców. Po każdej aktualizacji warto ponownie potwierdzić, że procesy aplikacji nie zyskały przypadkiem dostępu do plików z sekretami i że w katalogach aplikacji nie pojawiły się zbędne binarki. Aktualizacje potrafią zmieniać uprawnienia w sposób niezamierzony.

Monitoring po wdrożeniu

Autor eksperymentu odróżnił logi kompletne od niekompletnych i uczciwie oznaczył ich ograniczenia. To rozróżnienie jest punktem wyjścia dla monitoringu powdrożeniowego: trzeba wiedzieć, które źródła danych zawodzą dokładnie wtedy, gdy najbardziej ich potrzebujesz.

Co obserwować w okresie okołopublikacyjnym

• Awaria procesów aplikacji, w tym zdarzenia typu SIGSEGV — w eksperymencie były jednym z niewielu sygnałów aktywnych prób wykorzystania podatności.
• Nietypowe żądania odbiegające od normalnego profilu ruchu, szczególnie kierowane do pojedynczych punktów wejścia.
• Spadki wydajności i przeciążenia, które w eksperymencie doprowadziły do niedostępności serwera i problemów z utrzymaniem sesji SSH.
• Zdarzenia restartów workerów PHP wywołane wysokim obciążeniem żądaniami lub częściowo udanymi próbami eksploatacji pamięci.

Odporność logów na przeciążenie

W eksperymencie serwer przez dłuższy czas był pod takim obciążeniem, że utrzymanie sesji administracyjnej było niemożliwe, a hosting czasowo wyłączył stronę raz z powodu podejrzenia ataku DDoS, a raz z powodu „nadmiernego wykorzystania CPU”. Monitoring zaprojektowany bez uwzględnienia takich warunków może przestać dostarczać dane dokładnie w momencie kryzysu. Warto okresowo testować, czy logi przeżywają rotację i przeciążenie oraz czy zdarzenia awarii procesów są w nich zachowywane.

Interpretacja szumu

Masowy ruch wokół podatności może maskować pojedyncze realne zdarzenia. W eksperymencie sukces przyszedł w środku ogromnego zainteresowania — dziesiątki tysięcy prób w krótkim czasie. Monitoring powinien pozwalać odróżnić tło skanowania od pojedynczych zdarzeń odbiegających od wzorca, zamiast reagować wyłącznie na wolumen.

Checklista weryfikacji i monitoringu po wdrożeniu

1. ☐ Potwierdzono wersję PHP na każdym hoście produkcyjnym, nie tylko w dokumentacji.
2. ☐ Sprawdzono, czy poprawka przetrwała restart usług i kolejne wdrożenia.
3. ☐ Wykonano test odtwarzający znany wektor ataku na konfiguracji zbliżonej do produkcyjnej.
4. ☐ Potwierdzono, że procesy aplikacji mają minimalne uprawnienia i nie mają dostępu do sekretów bez potrzeby.
5. ☐ Sprawdzono, czy w katalogach aplikacji nie pojawiły się zbędne binarki po aktualizacji.
6. ☐ Zwiększono czułość monitoringu na awarie procesów i nietypowe żądania.
7. ☐ Przetestowano odporność logów na rotację i przeciążenie.
8. ☐ Ustalono, kto analizuje sygnały z monitoringu w okresie okołopublikacyjnym.
9. ☐ Zapisano, co wdrożono, kiedy i z jakim skutkiem weryfikacji.
10. ☐ Zdefiniowano próg, przy którym pojedyncze nietypowe zdarzenie eskaluje do analizy incydentu.

Wnioski z eksperymentu dla praktyki weryfikacji

Eksperyment pokazał dwie rzeczy jednocześnie: podatność była realnie wykorzystywana poza laboratorium, ale spośród dziesiątek tysięcy prób tylko dwie osoby zdołały uruchomić binarkę print-flag, a tylko jedna wyciągnęła użyteczną treść z aplikacji. Ta asymetria ma bezpośrednie znaczenie dla weryfikacji: sukces atakującego zależał od dopasowania do konkretnej konfiguracji, więc i obrona musi być potwierdzana na konkretnej konfiguracji. Zwycięzca wykorzystał podatność przez specjalnie spreparowany exploit targetujący sposób instalacji PHP na serwerze — co oznacza, że ogólne potwierdzenie „mamy poprawkę” nie wystarcza, jeśli nie wiemy, jakiej konfiguracji ona dotyczy.

Drugi wniosek dotyczy skali hałasu. Link do wyzwania trafił na pierwszą stronę Hacker News i utrzymał się tam niemal cały dzień, a serwer wymagał skalowania od 1 vCPU i 500 MB RAM do 2 vCPU i 4096 MB RAM. W organizacji analogiczna sytuacja — nagły, masowy ruch związany z głośną podatnością — może przeciążyć zarówno infrastrukturę, jak i zespoły odpowiedzialne za weryfikację. Dlatego procedura powdrożeniowa powinna być na tyle prosta, by dała się wykonać w warunkach podwyższonego obciążenia, i na tyle konkretna, by jej wynik dał się zapisać i porównać z kolejnym wdrożeniem.

Trzeci wniosek dotyczy higieny sekretów w kontekście weryfikacji. Fakt, że klucz był czytelny tylko dla jednej binarki, nie uchronił serwera przed zwycięzcą, ale znacząco zawęził liczbę osób, którym się udało. Po wdrożeniu poprawki warto więc nie tylko potwierdzić wersję oprogramowania, lecz także sprawdzić, czy izolacja sekretów i minimalne uprawnienia procesów nadal obowiązują — bo to one decydują, ile pracy wymaga ewentualny kolejny krok atakującego.

Utrzymanie stanu po weryfikacji

Weryfikacja i monitoring to nie jednorazowe zadania, lecz element cyklu. Autor eksperymentu musiał doprowadzić serwer do „względnie stabilnego stanu”, w którym większość osób mogła się połączyć przez większość czasu — i to dopiero po serii interwencji. W organizacji analogiczny stan stabilności po wdrożeniu poprawek wymaga utrwalenia: potwierdzone konfiguracje powinny trafiać do inwentarza, a wyniki testów weryfikacyjnych do dokumentacji, która przetrwa zmianę osób odpowiedzialnych.

• Uaktualnij inwentarz o potwierdzone wersje i konfiguracje, nie o deklaracje z ticketów.
• Zapisz wyniki testów odtwarzających warunki ataku wraz z datą i środowiskiem.
• Ustal termin kolejnego przeglądu uprawnień procesów i dostępu do sekretów.
• Zweryfikuj, czy kryteria eskalacji z monitoringu są nadal aktualne po zakończeniu okresu okołopublikacyjnego.
• Przetestuj procedurę reakcji na kolejną krytyczną podatność, zanim będzie potrzebna — tak jak eksperyment testował realną eksploatację, zamiast opierać się na narracji.

Eksperyment z serwerem za 2,50 dolara nie dowodzi, że podatności PHP można ignorować. Dowodzi czegoś innego: że odległość między „każdy może to wykorzystać” a „jedna osoba na dziesiątki tysięcy prób zdołała” jest duża i zależy od konfiguracji. Weryfikacja po wdrożeniu i monitoring po nim są sposobem, by tę odległość mierzyć na własnym środowisku, zamiast opierać się na nagłówkach.

Źródła i materiały do dalszej weryfikacji

Artykuł jest autorskim opracowaniem przygotowanym na podstawie poniższych materiałów. Linki prowadzą do publikacji źródłowych.

1. Observations from Running stealmybitcoin.com | Pavursec (pavursec.com)

Zdjęcie wyróżniające: Tima Miroshnichenko / Pexels.