Przejdź do treści

Steal My Bitcoin: 2000 dolarów za udane włamanie przez lukę PHP. Nikt jeszcze nie wygrał

Adam Marzec
Okładka artykułu o wyzwaniu Steal My Bitcoin: portfel 2013 dolarów na serwerze z PHP 8.4.26 sprzed łatki PHP2Shell, cztery wpłaty i zero wypłat na odczyt 25 października

W sobotę 24 października 2026 o 20:30 UTC na Hacker News pojawił się short „Show HN: Steal My Bitcoin” z linkiem do stealmybitcoin.com. Zasada jest równie prosta, co bezczelna: klucz prywatny portfela Bitcoin stoi na serwerze, w pliku dostępnym dla konta, na którym działa PHP, i do zdobycia go służy znana z zeszłego tygodnia krytyczna luka w silniku PHP. Kto pierwszy ją wykorzysta w praktyce i opróżni portfel, zabiera bitcoiny dla siebie. Za challenge’em stoi konto, które wszystko wskazuje na znanego badacza bezpieczeństwa, a nagroda urosła w dobie z 502 do ponad 2000 dolarów, bo czytelnicy HN zaczęli dorzucać do portfela z czystej ciekawości.

Co z tej zabawy wynika, sprawdzam z dwóch stron. Pierwsza: to live test pytania, które przez ostatnie dwa tygodnie rozgrzewało branżę, czyli czy AI pozwala każdy skalpel w postaci CV z podstawami zamienić w działający exploit. Druga: czy po panice wokół luk CVE-2026-109618 i CVE-2026-109619 realnie istnieje ryzyko dla zwykłych serwerów. Na dziś odpowiedź brzmi: po ponad 13 godzinach portfel wciąż stoi, a to mówi sporo o obu pytaniach naraz.

Najważniejsze informacje

CoSzczegóły
ChallengeShow HN „Steal My Bitcoin”, 24 października 2026, 20:30 UTC, 487 punktów (odczyt 25.10)
Zasadaklucz portfela ukryty na serwerze, dostępny kontowi PHP przez binarny plik print-flag
Nagroda na start0,00625104 BTC, około 502 USD
Nagroda 25.100,02506816 BTC, około 2013 USD przy cenie BTC 80 302 USD; 4 wpłaty, zero wypłat
SerwerPHP 8.4.26 według odczytu użytkownika HN; łatka 8.4.27 wyszła 21 października
Statusbez wygranej; na odczyt 25.10 strona nie odpowiadała, wcześniej padała pod obciążeniem

Zasady: klasyczny CTF z zapisem wprost

Strona challenge’a jest krótka i czyta się ją w minutę. Autor zapowiada, że na serwerze stoi klucz bitcoinowy wart około 500 dolarów, dostępny dla konta PHP przez binarny plik o nazwie print-flag. Wersja PHP została dobrana z okresu sprzed publikacji luk PHP2SHELL, czyli jest podatna. Wygrywa pierwsza osoba, która dobierze się do portfela. Później dwie dopiski, które mówią sporo o autorze: jeśli nie potrzebujesz pieniędzy, możesz je oddać na charity Givewell, a cały ruch na serwerze jest logowany, bo to znany podatny komputer, na którym nie da się zagwarantować prywatności, i nie należy podawać nic, czego nie chce się pokazać innym.

To konstrukcja klasycznego CTF, tylko z prawdziwymi pieniędzmi na stole. Autor jasno upoważnia do ataku na jeden konkretny serwer, własny, z przyznającym się do monitoringu logów. Jeśli chodzi o uczciwość zabawy, krytycy na HN odnotowali od razu słaby punkt: nikt z zewnątrz nie zweryfikuje, że klucz faktycznie jest na serwerze, ani że challenge nie jest pułapką na gotowe exploity od profesjonalistów. Autor niczego takiego nie ukrywa, a warunki uczestnictwa ma podlinkowane w stopce. Po prostu przyjmujemy kontrakt na wiarę albo nie gramy.

Luka, o którą chodzi w zabawie

PHP2SHELL to nazwa, jaka przyjęła się dla pary krytycznych luk w samym silniku PHP, opisanych u nas w dedykowanym wpisie o PHP2Shell: CVE-2026-109618 i CVE-2026-109619. Pozwalają na zdalne wykonanie kodu bez logowania, dotyczą wersji aż od PHP 5.4 i dostały ocenę CVSS v4.0 9.2 na 10. Projekt PHP wydał poprawki 21 października o 14:00 UTC w czterech gałęziach: 8.5.12, 8.4.27, 8.3.36 i 8.2.35. Serwer challenge’a chodzi na PHP 8.4.26 według odczytu użytkownika randomblock1, czyli celowo o jedną łatkę wstecz. Atak jest więc legalny w ramach zabawy i realny z punktu widzenia technik, z tym że autor nie podaje serwerowi nic ułatwiającego: nginx stał z limitem 1 MB na rozmiar zapytania, co jak odnotowano w wątku, samo w sobie załatwia część ścieżek exploitacji.

Jeśli czytasz to z serwerem własnej strony w tle, jedyny praktyczny wniosek jest ten sam co przed tygodniem: aktualizacja PHP do 8.4.27 albo nowszej wersji domyka problem całkowicie. Cloudflare wdrażał mitigacje jeszcze przed publikacją luk, a exploity w stanie używalnym nie pojawiły się publicznie do dziś. Challenge jest w tym kontekście ciekawostką, nie nowym zagrożeniem.

Czy ktoś wygrał? Nie, ale nagroda rośnie

Portfel challenge’a ma adres bc1qlnu50y4zm0nwxkckxu09thn5xdcz8aw6t3cxqy i da się czytać jak licznik wyniku. Na start zawierał 0,00625104 BTC, około 502,35 USD według zapisu z pierwszych godzin zabawy. Na odczyt z 25 października około 10:15 UTC saldo to 0,02506816 BTC, czyli około 2013 dolarów po cenie 80 302 USD za Bitcoin. Cztery wpłaty, zero wypłat. Społeczność HN dokłada do nagrody z komentarzami w stylu „prize is up to $2000 now, any takers”, a jedna z osób dodała wprost, że podwojono stawkę. Nadal nikt nie zgarnia.

Serwer bywał mało dostępny. W pierwszych godzinach wątku autor mirrorował treść strony w komentarzu, bo serwis nie wyrabiał pod naporem ciekawskich, a jeden z czytelników zanotował później, że strona odpowiadała błędem dostępności. W chwili mojego drugiego odczytu w niedzielę strona w ogóle nie odpowiadała, więc niedostępność stała się z tym czasem stałym elementem zabawy. Timer na stronie liczy godziny bez udanego włamania i wracał do zera po restartach. To zresztą ironia tygodnia: najtrudniejszym testem dla challenge’a nie był exploit, tylko ruch, który on sam wygenerował.

Dlaczego nikt nie wygrywa

Sedno zabawy leży w dyskusji pod wątkiem, i jest o kilka poziomów ciekawsza niż sam tekst strony. Główna sprawa: posiadanie informacji o luce to nie to samo co działający exploit. Jeden z komentujących, badacz bezpieczeństwa praktykujący w tej materii, zadeklarował wprost, że ma PoC wygenerowane przez LLM, które potrafi zawiesić serwery z podatną wersją PHP, ale zawieszenie to nie jest RCE. Różnicę między crashem a zdalnym wykonaniem kodu trzeba nadrobić pracą: pełny łańcuch exploitacji, ominięcie ASLR i inne elementy, których żaden artykuł ani diff łatki nie podsuwa na tacy. Do tego serwer chodzi na nginx z PHP-FPM, co według tego samego autora jest trudniejsze niż tryb mod_php, dla którego przygotowano część materiałów.

Druga sprawa to ekonomia. Profesjonaliści mający działający exploit nie oddadzą go za 500 dolarów, bo takie narzędzie warte jest wielokrotnie więcej na własnym rynku. Jeden z komentarzy ujął to z surowym rachunkiem: podnieś nagrodę do 15-25 tysięcy dolarów, a portfel zniknie od razu, i to prawdopodobnie bez użycia PHP2Shell. W efekcie challenge testuje nie tyle umiejętności hakerów, ile nadwyżkę działających, niewypalonych exploitów w naturze. Jeśli ktoś twierdzi, że każdy nastolatek z dostępem do modeli AI potrafi dziś napisać RCE, ten portfel jest gotowym testem falsyfikacyjnym: jest nagroda, jest podatny serwer, jest zaproszenie. Po 13 godzinach test falsyfikacyjny wypada na niekorzyść twierdzenia.

To zdanie zacytuję, bo brzmi jak podsumowanie całej afery, a pada w wątku niemal mimochodem: nie ma „tysięcy rojów agentów autonomicznie przejmujących każdy serwer”, jak pisywano na X i LinkedIn, i fakt, że portfel wciąż stoi, kończy tę narrację. Nie znaczy to, że luka była nieważna. Znaczy to, że przepaść między czytaniem o luce a wykorzystaniem jej w praktyce jest duża, nawet w epoce modeli, które piszą kod lepiej niż większość ludzi. Autor challenge’a, pytany o sens, miał w wątku wsparcie: cała ta zabawa istnieje po to, by skonfrontować panikę z rzeczywistością.

Kim jest autor

Konto, które opublikowało challenge, to cloudlandsdev, a jego wcześniejsza i jedyna aktywność publikacyjna na HN prowadzi na pavursec.com, czyli osobistą stronę Jamesa Pavura, badacza bezpieczeństwa z doktoratem z informatyki na Uniwersytecie Oksfordzkim, laureata stypendium Rhodesa, byłego dyrektora laboratorium badawczego firmy CYSEC w Luksemburgu i byłego Presidential Innovation Fellow w amerykańskim Departamencie Stanu. Wszystko wskazuje więc, że za zabawą stoi badacz z bardzo poważnym dorobkiem w dziedzinie, którą zabawa parodiuje. To typowe dla tego środowiska: najtwardsze publikacje o ryzyku mają z reguły autorów, którzy znają obie strony luki od podszewki.

Co z tego dla polskich serwerów

Po pierwsze, spokój. Challenge nie jest nową luką ani kampanią ataków, tylko kontrolowanym testem na własnym serwerze z jawnymi zasadami i logami. Nie ma powodu, by reagować cokolwiek dalej niż standardową aktualizacją. Po drugie, przypomnienie: w Polsce testowanie luk na cudzych serwerach bez zgody właściciela to przestępstwo z art. 267b Kodeksu karnego, niezależnie od tego, jak ciekawy byłby wynik. Zabawa na stealmybitcoin.com jest legalna wyłącznie dlatego, że autor jasno upoważnia do ataku na własny sprzęt.

Po trzecie, status waszych stron. Fraza „php cve 2026” żyje w polskim autocomplete, czyli temat w Polsce szukają. Jeśli prowadzisz stronę na WordPressie albo innym PHP, sprawdź w panelu hostingu wersję. Którekolwiek z tych wydań domyka luki całkowicie: 8.4.27, 8.3.36, 8.2.35 albo 8.5.12. Jeśli nie masz dostępu do wersji PHP, zapytaj obsługę hostingu, kiedy wdrożyła łatki z 21 października, i nie przyjmuj za odpowiedź „nie mieliśmy problemów”. Nasz pełen opis techniczny, z historią odkrycia i listingiem ścieżek obrony, jest w dedykowanym wpisie o PHP2Shell, a o skutkach ubocznych tej samej fali poprawek w narzędziach brotli piszemy osobno.

Najczęstsze pytania

Co to jest RCE?

RCE to skrót od remote code execution, czyli zdalne wykonanie kodu. Oznacza sytuację, w której atakujący uruchamia własne polecenia na serwerze, do którego nie ma fizycznego ani zalogowanego dostępu. Luki CVE-2026-109618 i CVE-2026-109619 w PHP to właśnie RCE, dlatego dostali ocenę krytyczną 9.2 i dlatego patch 8.4.27 z 21 października warto wdrożyć tego samego dnia, w którym się o nim przeczyta.

Źródła

Powiązane artykuły