O czym jest ten film
- W PHP — języku, na którym działa około siedmiu na dziesięciu stron internetowych, w tym większość instalacji WordPressa — odkryto krytyczną lukę bezpieczeństwa.
- Podatność pozwala teoretycznie przejąć serwer, na którym działa strona, bez podawania hasła ani jakichkolwiek danych logowania.
- Luka uruchamia się, zanim WordPress zdąży obejrzeć przychodzące żądanie — wtyczki i ustawienia ochronne w samym WordPressie mogą więc nie zdążyć jej zatrzymać.
- W ramach prewencji część rządów (m.in. Finlandia i Holandia) czasowo wyłączyła swoje serwisy.
- Lukę ujawniło OpenAI, badając kod proaktywnie z pomocą AI; podatność istniała ponad dekadę, ale jej ręczne udowodnienie wymagałoby gigantycznego nakładu pracy.
- AI potrafi dziś rozrysować zasięg szkód „trudnych do udowodnienia” podatności — ale tę samą moc mają atakujący, którzy zaraz po ujawnieniu zaczęli próbować lukę wykorzystać.
- Strony na Shopify, Wix i Squarespace są najpewniej załatane po stronie platformy; realne ryzyko dotyczy stron składanych kiedyś przez agencje lub freelancerów i potem porzuconych.
- Autor pokazuje, jak w niecałe dwie minuty przeskanować stronę narzędziem OpenAI „php-to-shell” podpiętym do Claude Code, Codex lub Geminiego.
- Wynik „unknown” nie daje gwarancji bezpieczeństwa — trzeba zalogować się do hostingu i sprawdzić wersję PHP; 8.1 lub starsza wymaga aktualizacji albo pisemnego potwierdzenia łatki od dostawcy.
- Autor przewiduje, że to pierwszy przypadek z wielu: firmy AI będą systematycznie obciążać testami stary kod i wyciągać na światło dzienne kolejne dawne słabości.
10 najważniejszych takeaways — z kontekstem zastosowania
1.Dwuminutowy test strony z pomocą agenta AI
Na czym polega: OpenAI opublikowało darmowe narzędzie „php-to-shell”, które można podpiąć do Claude Code, Codexa czy Geminiego. Agent sam pobiera checkera, uruchamia skan wobec twojej domeny i zdaje relację prostym językiem.
Jak stosować: podaj modelowi adres repozytorium i swój adres strony, a potem użyj gotowego polecenia z materiału (zamieszczono je poniżej, w tłumaczeniu). Całość faktycznie zajmuje około dwóch minut.
Na co uważać: narzędzie widzi tylko to, co da się sprawdzić z zewnątrz. Nie dawaj agentowi szerszych uprawnień niż skan jednej, konkretnej domeny — to nie jest zaproszenie do „pentestów” na wszystkie twoje projekty.
2.Wtyczki bezpieczeństwa w WordPressie mogą nie zdążyć z reakcją
Na czym polega: ta podatność uruchamia się na poziomie samego PHP, zanim WordPress — a razem z nim wtyczki ochronne i specjalne ustawienia — w ogóle obejrzy żądanie. Mówiąc po ludzku: niekoniecznie zdołają ją zablokować.
Jak stosować: traktuj zabezpieczenia wewnątrz WordPressa jako dodatkową warstwę, nigdy jedyną. Krytyczne słabości rozwiązuje się na poziomie serwera i hostingu — to tam trzeba zadawać pytania.
Na co uważać: na fałszywe poczucie bezpieczeństwa w stylu „mam wtyczkę antywirusową, więc jestem chroniony”. Przy podatnościach wczytujących się wcześniej niż silnik strony taka ochrona po prostu nie ma jak zadziałać.
3.Wynik „unknown” to nie zielone światło
Na czym polega: jeśli skaner zwróci status „unknown”, oznacza to jedynie, że nie zdołał jednoznacznie rozstrzygnąć — a nie że strona jest bezpieczna.
Jak stosować: przy „unknown” zawsze rób drugi krok: zaloguj się do panelu hostingu i sprawdź wersję PHP, zwykle schowaną gdzieś głęboko w ustawieniach.
Na co uważać: hostingi potrafią rozdzielać środowiska (produkcyjne, testowe) i wyświetlać wersję w nieoczywistym miejscu. Upewnij się, że patrzysz na wersję, na której faktycznie działa twoja widoczna publicznie strona.
4.PHP 8.1 lub starsze wymaga natychmiastowej akcji
Na czym polega: jeśli numer wersji PHP zaczyna się od 8.1 lub od czegoś starszego, środowisko wymaga aktualizacji — albo twardego potwierdzenia, że dostawca już załatał lukę po swojej stronie.
Jak stosować: napisz do hostingu i poproś o pisemne potwierdzenie, że podatność została załatana. Brak odpowiedzi w rozsądnym czasie traktuj jako sygnał do zmiany dostawcy.
Na co uważać: skok na nowszą wersję PHP potrafi zepsuć stare wtyczki i motywy. Zanim cokolwiek zmienisz, zrób kopię zapasową strony i — jeśli to możliwe — przetestuj aktualizację na kopii środowiska.
5.Platformy typu Shopify, Wix czy Squarespace najpewniej załatwiły sprawę za ciebie
Na czym polega: serwisy SaaS utrzymują całą infrastrukturę po swojej stronie i w takich sytuacjach zwykle łatają ją centralnie, bez udziału klienta.
Jak stosować: jeśli twoja strona działa na takiej platformie, wystarczy rzetelność — sprawdź oficjalny komunikat dostawcy, czy łatka została wdrożona.
Na co uważać: nie przenoś tego wniosku na WordPressa postawionego na własnym lub wynajmowanym serwerze. Tam nikt nie załatwi nic za ciebie — odpowiedzialność leży po twojej stronie.
6.Najbardziej zagrożone są strony „porzucone”
Na czym polega: typowy profil ryzyka to strona małej firmy, którą kiedyś złożyła agencja albo freelaner — i od tamtej pory nikt, łącznie z wykonawcą, nie logował się do panelu. Nikt więc nie aktualizuje PHP ani nie śledzi komunikatów o zagrożeniach.
Jak stosować: zrób inwentaryzację: własne strony, strony klientów, dawne projekty. Przepuść je przez skan, nawet jeśli „od zawsze działały bez problemu” — właśnie takie strony są celem numer jeden.
Na co uważać: przy starych projektach bywa, że nie pamięta się już, gdzie strona jest hostowana i kto ma dostęp. Zacznij od ustalenia tego, zanim cokolwiek zechcesz załatać.
7.Ujawnienie luki to start wyścigu z atakującymi
Na czym polega: w chwili publikacji informacji o podatności atakujący zaczęli natychmiast próbować ją wykorzystać. Wiele stron — być może w tym twoja — mogło już zostać zagrożonych.
Jak stosować: komunikat o krytycznej luce traktuj jak alarm pożarowy: sprawdzaj i łataj od razu, nie „w przyszłym sprincie”. Im dłużej czekasz od momentu ujawnienia, tym większe ryzyko.
Na co uważać: nie uspokajaj siebie myśleniem „jestem za mały, nikt mnie nie szuka”. Automatyczne skanery nie robią różnicy między korporacją a lokalną firmą — sprawdzają po prostu zakres adresów.
8.AI w cyberbezpieczeństwie to obosieczny miecz
Na czym polega: te same modele, które pozwoliły odkryć dziesięcioletnią lukę, trafiają też do rąk atakujących. Sam autor przypomina inne doniesienia — o agentach uciekających z piaskownic czy o włamaniach z udziałem AI.
Jak stosować: wykorzystuj AI po stronie obrony: do audytów własnych stron, interpretacji wyników skanów czy przygotowania zgłoszeń do dostawcy hostingu.
Na co uważać: testowanie cudzych stron bez wyraźnej zgody jest nielegalne niezależnie od narzędzia. Ciekawość nie jest tu obroną — trzymaj się wyłącznie własnej infrastruktury.
9.Luka leżała dekadę, bo nikt nie chciał zrobić tej pracy ręcznie
Na czym polega: podatność istniała od ponad dziesięciu lat, ale udowodnienie jej i zmierzenie skali wymagałoby takiego nakładu żmudnej pracy ręcznej, że nikt się tego nie podjął. AI potrafi teraz wykonać tę robotę i rozrysować zasięg szkód.
Jak stosować: zmień założenie „stare i sprawdzone znaczy bezpieczne” na „stare może być po prostu nieprzebadane”. Utrzymuj prosty rejestr: jakie strony prowadzę, na jakim hostingu, w jakiej wersji PHP.
Na co uważać: lawina kolejnych odkryć wywoła z czasem przyzwyczajenie i obojętność — a to najgorszy moment na zignorowanie realnego alarmu. Priorytetyzuj według krytyczności, ale nie ignoruj.
10.Przekaż dalej każdemu, kto prowadzi biznes na starym WordPressie
Na czym polega: autor wprost zachęca, by wysyłać repozytorium OpenAI albo jego film osobom, których firmy działają na przestarzałych stronach WordPress — bo to one najczęściej nie dowiedzą się o zagrożeniu z własnej inicjatywy.
Jak stosować: krótka wiadomość z linkiem i jednym zdaniem, dlaczego sprawa jest pilna, działa lepiej niż samo przesłanie filmu bez kontekstu. Dodaj konkretny krok: „uruchom skan i sprawdź wersję PHP”.
Na co uważać: nie strasz bez konkretów. Odbiorca nietechniczny potrzebuje jednego jasnego działania, nie wykładu o podatnościach — inaczej wiadomość wyląduje w koszu razem z dziesięcioma innymi „ostrzeżeniami”.
Redakcyjne tłumaczenie
Luka w PHP, o której powinien wiedzieć każdy właściciel strony
Jeśli masz stronę internetową — własną albo firmową, zwłaszcza postawioną kiedyś na WordPressie — istnieje luka bezpieczeństwa, przy której ujawnieniu pomogło OpenAI, i naprawdę warto o niej wiedzieć. Siedzi w samym PHP. Dla osoby nietechnicznej: PHP to język, w którym — z grubsza rzecz biorąc — działa około siedmiu na dziesięciu stron internetowych. Zasadnicze zagrożenie polega na tym, że dzięki tej luce ktoś może przejąć komputer, na którym działa twoja strona, bez podawania hasła ani jakichkolwiek danych logowania. Pokrótce wyjaśnię, o co chodzi, dlaczego ludzie się niepokoją i jak w niecałe dwie minuty sprawdzić własną stronę albo stronę klienta.
Czym jest PHP i dlaczego to dotyczy niemal całej sieci
Jeśli budowałeś strony w czasach sprzed ery „vibe codingu” — czyli zanim zaczęliśmy pisać kod, po prostu rozmawiając z AI — z pewnością kojarzysz WordPressa. Większość stron opartych na tym systemie działa na PHP, które dla uproszczenia można traktować jako silnik napędzający stronę pod maską. I to właśnie w samym PHP znaleziono lukę. Teoretycznie wystarczy, że ktoś wyśle twojej stronie kilka specjalnie spreparowanych żądań, żeby przejąć komputer, na którym ją uruchamiasz — podkreślmy: bez logowania.
Najbardziej niepokojące jest jednak to, że podatność uruchamia się, zanim WordPress w ogóle zdąży obejrzeć przychodzące żądanie. Jeśli w WordPressie masz wtyczki albo ustawienia mające cię chronić, one po prostu nie zdążą się wczytać przed nią. Mówiąc po ludzku: niekoniecznie zdołają ją zatrzymać.
Skąd to zamieszanie, skoro większość ludzi nie wie, czym jest PHP
Może nie masz własnej strony i nie kojarzysz nazw WordPress ani PHP — skąd więc tyle emocji? Odpowiedź jest prosta: większość internetu powstała przed erą vibe codingu i od dekad spoczywa na fundamencie, jakim jest PHP. W ramach prewencji wielu dostawców, operatorów serwisów, a nawet całe rządy wyłączają swoje strony, żeby uniknąć katastrofy. Przykład? Rządy m.in. Finlandii i Holandii już zdecydowały się czasowo zdejmować z sieci część swoich serwisów, nie chcąc podejmować żadnego ryzyka.
Jak AI trafiło na dziesięcioletnią lukę
Tu jest ciekawy niuans. O firmach takich jak OpenAI czy Anthropic słyszymy zwykle w innym kontekście — gdy ich agenci uciekają z piaskownic albo się z nich wydostają, a także wtedy, gdy — jak podobno — włamują się na coś w rodzaju Hugging Face. Tym razem jednak sprawa wygląda inaczej: OpenAI natrafiło na tę lukę, działając przezornie, w ramach własnych badań. A sama podatność istnieje od ponad dekady.
Dlaczego tyle lat leżała odłożona? Bo udowodnienie, że to realna słabość i jak daleko sięgają jej skutki, wymagałoby gigantycznej, ręcznej pracy. I tu pojawia się dwie wiadomości naraz. Dobra: sztuczna inteligencja potrafi dziś rozrysować zasięg szkód takich „trudnych do udowodnienia” podatności. Zła: w chwili, gdy informacja wyszła na jaw, atakujący rzucili się ją wykorzystywać — i wiele stron, być może w tym twoja, wciąż może być zagrożonych.
Obosieczny miecz
Jeśli śledzisz ten obszar od kilku tygodni — a jeśli widziałeś mój poprzedni film sprzed paru dni, wiesz, że pokazywałem inne przykłady, w których AI pomaga nie tyle się bronić, co włamywać do różnorodnych systemów czy narzędzi programistycznych — to już wiesz, o co chodzi: w cyberbezpieczeństwie sztuczna inteligencja jest podręcznikowym obosiecznym mieczem.
Kto może spać spokojnie, a kto powinien działać
Jeśli twoja strona działa na Shopify, Wixie albo Squarespace, najpewniej większość pracy wykonano już za ciebie. Prawdziwie martwię się o strony, które ma mnóstwo małych firm: składała je kiedyś agencja lub freelaner i od tamtej pory nikt — łącznie z tym wykonawcą — nie zalogował się do panelu. Jeśli jesteś na WordPressie, czeka cię nieco więcej zachodu. Pokażę łatwe w użyciu repozytorium opublikowane przez OpenAI, które wystarczy podpiąć do Claude Code, Codexa albo Geminiego i kazać im doprowadzić sprawę do końca.
Test w dwie minuty: repozytorium php-to-shell
Aby szybko sprawdzić, czy luka dotyczy twojej strony, wejdź do repozytoriów OpenAI i odszukaj to zatytułowane „php-to-shell” (Informacja dodatkowa: repozytorium jest publiczne i darmowe; autor podał link w opisie filmu). Następnie weź jego adres, wklej go modelowi językowemu, z którego korzystasz, i przekaż mu takie polecenie:
„Skorzystaj z darmowego narzędzia php-to-shell od OpenAI dostępnego pod tym linkiem: [wstaw link]. Jako domenę do sprawdzenia podstaw: [twoja domena]. Pobierz narzędzie, przeskanuj wyłącznie moją stronę i opisz mi prostym językiem, co znalazłeś.”
Narzędzie wskaże konkretne problemy, a jeśli coś okaże się niejasne, model pomoże ci zredagować wiadomość do dostawcy hostingu, żeby sprawa została rozwiązana jak najszybciej.
Dwa przykładowe skany
Weźmy dwie strony testowe: test A i test B — jedna z nich ma lukę. Po zainstalowaniu repozytorium Claude wykona w twoim imieniu mniej więcej tyle: uruchomi skan, a gdy ten zakończy pracę, od razu widać w wynikach, czy strona jest podatna oraz czy chodzi o tę złą wersję PHP, którą trzeba zaktualizować, czy o wersję bezpieczną.
„Unknown” nie oznacza zielonego światła
Jeśli w wynikach pojawi się słowo „unknown”, nie masz stuprocentowej gwarancji, że wszystko jest w porządku — sprawdź to więc samodzielnie. Lepsza droga: zaloguj się do panelu tam, gdzie hostujesz stronę — osobiście albo przez agenta AI w trybie computer use (Informacja dodatkowa: „computer use” to tryb pracy agenta AI, w którym model sam obsługuje interfejs — klika, wypełnia formularze i nawiguje po stronach jak człowiek przy klawiaturze) — i sprawdź wersję PHP, zwykle schowaną gdzieś głęboko w ustawieniach. Jeżeli numer tej wersji zaczyna się od 8.1 albo od czegoś starszego, masz dwa wyjścia: przejść na nowszą wersję albo upewnić się, że twój hosting już załatał lukę po swojej stronie.
To dopiero pierwsza z wielu takich historii
Niestety, będziemy mieć do czynienia z kolejnymi wadami tego typu. OpenAI, Anthropic i Google dysponują dziś zasobami i modelami, które mogą bez końca przeglądać i obciążać testami kolejne potencjalne podatności — dokładnie taką jak ta. Prawdopodobnie nie ostatni raz usłyszysz o luce, która niby wyszła znikąd, a w rzeczywistości istniała od dawna i o którą musisz się teraz zatroszczyć.
Jeśli znasz kogoś, kto prowadzi firmę na starej stronie WordPress, szczerze polecam przesłać mu to repozytorium albo ten film — po prostu, żeby pomóc. A jak zapowiadałem, będę wracał do tematów cyberbezpieczeństwa, bo uważam, że to jeden z najważniejszych obszarów nadchodzącej przyszłości — i zależy mi, żebyś w nadchodzących wydarzeniach był jak najlepiej przygotowany, zabezpieczony i poinformowany. Jeśli materiał był dla ciebie pomocny, będę bardzo wdzięczny za łapkę w górę i komentarz pod filmem. Do zobaczenia w kolejnym.