Alarm związany z PHP2Shell przypomniał inwestorom, jak duże znaczenie mają narzędzia chroniące strony internetowe. Gdy administratorzy pospiesznie sprawdzali serwery i wdrażali poprawki, akcje Cloudflare zyskały w trakcie sesji ponad 6%. Rosły też notowania innych spółek z sektora bezpieczeństwa i oprogramowania. Nie da się jednak przypisać całego ruchu na giełdzie samym lukom w PHP: wśród pozostałych czynników wymieniano odpływ kapitału z firm półprzewodnikowych oraz osobne informacje o współpracy Nvidii i CrowdStrike.
19
20
22
17
Co napędzało wzrosty na giełdzie
Awaryjne wyłączanie niektórych stron i wyścig z aktualizacjami zwróciły uwagę na firmy dostarczające narzędzia bezpieczeństwa. W jednym z raportów rynkowych, obok Cloudflare, wymieniono wzrosty akcji Datadog, Okta i Zscaler. Inny popołudniowy raport podawał, że Cloudflare zyskiwał około 7%, a Palo Alto Networks około 4%. To migawki z handlu w ciągu dnia, a nie potwierdzone wyniki na zamknięciu sesji — nie dowodzą też, że każda z tych spółek rosła wyłącznie z powodu PHP2Shell.
19
20
Cloudflare było szczególnie widoczne, bo firma informowała o zabezpieczeniach wdrożonych w zaporze aplikacji internetowych (WAF). Takie reguły mogą pomóc ograniczyć ryzyko podczas przygotowywania i instalowania poprawki, ale nie zastępują aktualizacji PHP.
15
11
Na nastroje w sektorze wpływały również inne wydarzenia. Jeden z raportów opisywał przesuwanie kapitału z akcji półprzewodników do spółek programistycznych, między innymi w związku z obawami dotyczącymi skali inwestycji w infrastrukturę AI i kosztów finansowania. Inny wiązał wzrost notowań CrowdStrike z rozszerzeniem współpracy z Nvidią w obszarze bezpieczeństwa AI. To pomaga wyjaśnić, dlaczego zwyżki objęły więcej firm niż te bezpośrednio związane z PHP.
22
17
Na czym polegały luki PHP2Shell
Dwie podatności oznaczono jako CVE-2026-109618 i CVE-2026-109619. Łącznie określano je nazwą PHP2Shell, a ich poziom zagrożenia oceniono na 9,2 w skali CVSS v4.0. Opisy wskazywały na ryzyko zdalnego wykonania kodu bez uwierzytelnienia — napastnik mógł potencjalnie uruchomić kod na podatnym serwerze, nie logując się wcześniej.
14
15
Cloudflare opisał zagrożenie jako dotyczące serwerów korzystających z PHP 5.4 lub nowszego. Poprawki udostępniono dla wspieranych gałęzi w wersjach PHP 8.2.35, 8.3.36, 8.4.27 i 8.5.12.
15
8
Twórcy PHP ostrzegli o lukach we wtorek, 20 października, a poprawki pojawiły się następnego dnia. Według jednego z raportów dostępność aktualizacji potwierdzono około 13.45 GMT 21 października.
13
9
Dlaczego niektóre strony wyłączono
W Europie część stron administracji publicznej, szpitali i uniwersytetów wyłączono tymczasowo, by ograniczyć ryzyko podczas prac nad zabezpieczeniami. Samo wyłączenie strony z ostrożności nie oznacza, że została skutecznie zaatakowana.
3
Wikimedia poinformowała, że w ramach prewencyjnych prac serwisowych wyłączono między innymi Cloud VPS i Toolforge. Nie oznacza to, że niedostępne były wszystkie usługi Wikipedii.
7
Skalę niepokoju pomaga zrozumieć powszechne użycie PHP. W jednym z raportów oszacowano, że język ten działa na około 70% stron internetowych. To miara jego zasięgu, a nie liczba serwisów podatnych na atak lub już przejętych.
8
Co powinni zrobić właściciele stron
Cloudflare informował o pojawiających się atakach, podczas gdy niektóre krajowe agencje nie odnotowały prób wykorzystania luk. Te doniesienia nie muszą sobie przeczyć: instytucje mogą obserwować różne systemy i przedziały czasu. Brak zaobserwowanego ataku nie jest dowodem, że podatny serwer jest bezpieczny.
1
3
Jeśli prowadzisz niewielką stronę na hostingu współdzielonym, zapytaj dostawcę, czy zaktualizował wersję PHP na serwerze do wydania zawierającego poprawkę albo zastosował własną poprawkę bezpieczeństwa. Aktualizacja systemu zarządzania treścią nie musi oznaczać, że zaktualizowano samo PHP, na którym działa strona. Reguły WAF traktuj jako dodatkową, tymczasową warstwę ochrony i poproś hosting o informację, co zostało załatane i kiedy.
11
14