Dostępna jest aktualizacja bezpieczeństwa PHP z 21 października 2026Przeczytaj oficjalny komunikat ↗
Globya PHP2Shell Checkerby Globya Information Technologies
Polski

Najczęściej zadawane pytania

Które wersje PHP są podatne?

Każda wersja sprzed 8.5.12, 8.4.27, 8.3.36 i 8.2.35 we wspieranych gałęziach. PHP 8.1 i starsze nie są już wspierane i nie otrzymują wydania od projektu PHP; należy je traktować jako podatne, chyba że dostawca potwierdzi przeniesioną poprawkę.

Moja strona nie pokazuje wersji PHP. Czy jestem bezpieczny?

Niekoniecznie. Ukrycie wersji (expose_php = Off) to dobra praktyka, ale niczego nie łata. Sprawdź na serwerze poleceniem php -v lub zapytaj dostawcę.

Narzędzie pokazuje starą wersję, ale hosting twierdzi, że jest załatana. Kto ma rację?

Być może obie strony. Dystrybucje Linuksa, takie jak Debian, Ubuntu i RHEL, często przenoszą poprawki bezpieczeństwa bez zmiany numeru wersji. Zapytaj hosting, jaka kompilacja pakietu jest zainstalowana i czy jej changelog wymienia CVE-2026-109618 i CVE-2026-109619.

Czy WordPress, Laravel lub mój CMS są podatne?

Luki są w samym PHP, więc każda aplikacja działająca na podatnej wersji PHP jest narażona. Badacze zademonstrowali ataki bez uwierzytelniania na WordPress, Drupal i Joomla, ale były to tylko przykłady — wystarczy nawet zwykła strona „Hello World”. Aktualizacja WordPressa lub wtyczek tego nie naprawi; trzeba zaktualizować PHP.

Czy dane mogą wyciec, nawet jeśli nie wykonano żadnego kodu?

Tak. CVE-2026-109619 może ujawnić pamięć procesu PHP — hasła, tokeny sesji, klucze API i certyfikaty z innych żądań — bez uruchamiania kodu przez atakującego. Takie wycieki nie pozostawiają plików i są trudne do wykrycia, dlatego zmień sekrety każdej strony, która działała w internecie na podatnej wersji.

Czy wyłączenie session.upload_progress rozwiązuje problem?

Nie. php.net wymienia session.upload_progress.enabled=0 jako częściowy środek zaradczy dla niektórych potwierdzonych ścieżek CVE-2026-109619. Nie obejmuje on wszystkich wariantów i nie pomaga w przypadku CVE-2026-109618.

Czy zapora aplikacji WWW wystarczy?

WAF lub limity żądań mogą zmniejszyć narażenie na czas aktualizacji, ale problemy dotyczą sposobu, w jaki PHP obsługuje żądania i pamięć. Aktualizacja jest nadal konieczna.

Czy po aktualizacji trzeba coś zrestartować?

Tak. PHP-FPM, Apache, LiteSpeed i długo działające procesy robocze wykonują stary kod, dopóki nie zostaną zrestartowane. Kontenery trzeba odtworzyć z nowego obrazu.

Co właściwie robi to narzędzie?

Wysyła jedno żądanie HEAD (lub GET, jeśli HEAD nie jest dozwolone) na podany adres, podąża za maksymalnie trzema przekierowaniami i odczytuje nagłówki odpowiedzi, takie jak X-Powered-By i Server. Nigdy nie wysyła ładunków exploitów, dużych żądań ani plików i nie skanuje innych ścieżek.

Czy można legalnie sprawdzać dowolną stronę?

Sprawdzaj tylko strony, których jesteś właścicielem lub do których oceny masz upoważnienie. Żądanie jest takie samo jak zwykła wizyta, ale za odpowiedzialne użycie odpowiada użytkownik. Ograniczamy liczbę sprawdzeń na sieć i na stronę.

Czy PHP 8.5.12 zostało w pełni naprawione?

22 października 2026 r. pojawiły się doniesienia o awarii w 8.5.12, ale nie potwierdzono, że jest to podatność zdalna. Śledzimy php.net; jeśli pojawi się nowe wydanie, ta strona zostanie zaktualizowana, a data „ostatniej weryfikacji” się zmieni.

Gdzie przeczytać oficjalne szczegóły?

Na php.net oraz w komunikatach GitHub projektu PHP GHSA-w8hw-w9fx-j79w i GHSA-6wmf-4rv5-p3rp. Zespół badawczy (Wiz Research, OpenAI Codex Security i Calif) opublikował swoje ustalenia na php2shell.com.

Kto odkrył te podatności?

Badacze z Wiz Research, OpenAI Codex Security i Calif, w ramach skoordynowanego ujawnienia z zespołem bezpieczeństwa PHP, który przygotował poprawki. Zobacz wpis The PHP Foundation na temat tego wydania.