AI znalazła groźną lukę w PHP i uruchomiła wyścig o bezpieczeństwo stron

Sztuczna inteligencja pomogła wykazać, że stare błędy w PHP mogą prowadzić do przejęcia serwera. Teraz przyspiesza również pracę potencjalnych napastników. Poprawki są już dostępne, a dla firm najważniejsze staje się ustalenie, kto i kiedy zabezpieczy ich internetowe usługi.

• PHP2Shell obejmuje krytyczne podatności technologii wykorzystywanej przez wielką część internetu
• Badacze wspierani przez AI pokazali, że problemy z obsługą pamięci można wykorzystać do zdalnego uruchomienia kodu
• Poprawki udostępniono 21 października, o dzień wcześniej, niż pierwotnie planowano
• Sama aktualizacja strony lub wtyczek nie zastępuje sprawdzenia bezpieczeństwa PHP na serwerze

PHP2Shell to nazwa problemu, który dotyka jednego z podstawowych elementów internetowej infrastruktury. PHP odpowiada za działanie m.in. WordPressa, Drupala czy Joomli. Błędy znajdują się w samym silniku języka, dlatego poprawnie napisany serwis może nadal działać na podatnym fundamencie. W określonych warunkach napastnik nie potrzebuje konta użytkownika, aby uruchomić własny kod na serwerze.

W doniesieniach pojawia się liczba nawet 70 proc. światowych witryn korzystających z PHP. To miara znaczenia technologii, a nie potwierdzona liczba stron możliwych do przejęcia. Rzeczywiste ryzyko zależy m.in. od wersji oprogramowania, konfiguracji i sposobu obsługi żądań. Nie należy też mylić podatności z udanym włamaniem. Obecność błędu nie dowodzi, że dane konkretnej firmy zostały skradzione.

Jak opisuje „The Wall Street Journal”, badacz Calif Ryan Austin pracował z modelem AI podczas audytu kodu PHP. Zdołał pokazać praktyczny sposób wykorzystania problemów z pamięcią, a 11 sierpnia zespół zawiadomił osoby odpowiedzialne za bezpieczeństwo projektu. Niezależne ustalenia dostarczyły następnie zespoły OpenAI i Wiz. Wieloletni problem stał się pilnym zadaniem dla całego ekosystemu.

Dla obrońców oznacza to konieczność ponownego przyjrzenia się także znanym, lecz wcześniej odsuwanym problemom.

Czytaj też: AI wychodzi z piaskownicy. Cyberataki osiągają nowy poziom

Poprawka rozpoczyna kolejny wyścig

Przygotowanie zabezpieczeń wymagało współpracy twórców PHP, badaczy, dystrybutorów oprogramowania i firm zabezpieczających. Zmiany objęły blisko 200 plików oraz ponad 10 tys. linii kodu. Nie wystarczało usunąć jednego wadliwego fragmentu. Trzeba było ograniczyć ryzyko, że poprawki zakłócą działanie aplikacji opartych na PHP.

Pierwotnie wydanie zaplanowano na 22 października. Po przedwczesnym ujawnieniu informacji termin przesunięto na 21 października. PHP Foundation potwierdziła publikację wersji 8.5.12, 8.4.27, 8.3.36 oraz 8.2.35, usuwających dwie krytyczne podatności. To informacja istotna dla administratorów, ale w usługach zarządzanych sposób dostarczenia zabezpieczeń należy potwierdzić u dostawcy.

Publiczna poprawka ma podwójne znaczenie także dla biznesu. Pozwala obrońcom zabezpieczyć systemy, a napastnikom daje materiał do porównania starego i nowego kodu. Mogą w ten sposób ustalić, jaki problem usunięto. AI przyspiesza również tę analizę, więc okres między wydaniem aktualizacji a pojawieniem się prób ataku może się skracać. Ochrona zależy zatem nie tylko od jakości poprawki, lecz także od sprawności jej wdrożenia.

Z punktu widzenia biznesu najgroźniejsza bywa niejasna odpowiedzialność. Właściciel sklepu zakłada, że aktualizuje go agencja, agencja odpowiada za aplikację, a wersją PHP zarządza hosting. W takim układzie ostrzeżenie może krążyć między skrzynkami, choć żadna osoba nie sprawdza faktycznego stanu serwera. Potrzebne jest potwierdzenie wykonania aktualizacji, a nie samo przesłanie komunikatu.

Polskie firmy potrzebują potwierdzenia ochrony

Dla polskiego sklepu, wydawcy czy małej firmy praktyczny krok to pytanie do hostingu o używaną wersję PHP i wdrożenie poprawki. Gdy serwis obsługuje agencja, warto ustalić, kto odpowiada za warstwę serwerową. Aktualizacja WordPressa nie potwierdza aktualizacji PHP, a brak widocznych problemów na stronie nie jest dowodem bezpieczeństwa jej zaplecza.

Po wdrożeniu zabezpieczeń firma powinna sprawdzić działanie kluczowych funkcji, takich jak logowanie, formularze czy składanie zamówień. Jeżeli pojawią się oznaki wcześniejszej ingerencji, potrzebna jest analiza incydentu — usunięcie podatności nie cofa automatycznie skutków włamania. Warto więc rozdzielić dwa pytania: czy system jest już załatany i czy wcześniej nie został wykorzystany.

PHP2Shell pokazuje też ograniczenie samej automatyzacji. AI może pomóc znaleźć więcej błędów, ale ktoś nadal musi odróżnić istotne zgłoszenia od szumu, przygotować poprawki i dopilnować wdrożenia. Bez ludzi, finansowania oraz jasnych procedur szybsze wykrywanie problemów może przede wszystkim wydłużyć kolejkę spraw czekających na rozwiązanie. Właściciel serwisu powinien wiedzieć, gdzie trafiają nowe ostrzeżenia i kto ma prawo zlecić aktualizację. Przy powszechnej technologii jest to element ciągłości działania przedsiębiorstwa.

Czytaj też: 82% Polaków słyszało o wycieku danych. Większość nie zrobiła jednak nic