Krótko: Obejście luki bezpieczeństwa PHP2Shell może obniżyć ryzyko, ale nie zastępuje aktualizacji. php.net podaje w tym celu stałe limity pamięci i uploadu, wyłączenie session upload progress oraz w PHP 8.5 fatal_error_backtraces=0. Jeśli także to nie jest możliwe w krótkim czasie, BSI zaleca czasowe odłączenie serwera WWW od sieci.
Co obejście może zapewnić, a czego nie
Środki przejściowe php.net mają utrudnić warunki, w których luki CVE-2026-109618 i CVE-2026-109619 dają się wykorzystać. Wyraźnie nie są pełną ochroną. Luki są naprawione tylko w PHP 8.5.12, 8.4.27, 8.3.36 i 8.2.35 lub w potwierdzonym backporcie Państwa dostawcy.
Środki mają sens, gdy aktualizacja z konkretnego powodu jeszcze nie jest możliwa: okno serwisowe dopiero nadejdzie, aplikację trzeba najpierw przetestować albo eksploatują Państwo PHP 8.1 lub starsze, dla którego nie ma już oficjalnej aktualizacji. Są wtedy mostem, a nie celem.
Dlatego razem z obejściem proszę planować aktualizację: kto ją wykona, w jakim oknie serwisowym i kto potem sprawdzi, że wszystkie workery zostały zrestartowane? Rozwiązanie przejściowe bez daty końcowej grozi przekształceniem się w stan trwały.
Opcja 1: czasowo odłączyć serwer od sieci
BSI ogłosił poziom ostrzeżenia 3 (pomarańczowy) i zaleca czasowe odłączenie dotkniętych serwerów WWW od sieci, jeśli aktualizacja nie jest możliwa od razu. Niektórzy dostawcy zrobili to z ostrożności; nie oznacza to, że te strony zostały zhakowane.
Dla wielu firm niedostępność sklepu lub portalu jest kosztowna. Sensowne może być rozważenie: dostęp tylko przez VPN lub dopuszczone adresy IP, statyczna strona konserwacyjna zamiast aplikacji PHP albo wyłączenie pojedynczych, niepotrzebnych stron na serwerze. Im mniej PHP jest dostępne z zewnątrz, tym mniejsza powierzchnia ataku.
Ważne jest, aby decyzję podjąć świadomie i ją udokumentować: kto, kiedy i z jakimi środkami ochronnymi zdecydował o pozostawieniu serwera online? Pomaga to później wobec ubezpieczyciela, ochrony danych i zarządu.
Środki przejściowe php.net
| Środek | Wartość | Uwaga |
|---|---|---|
memory_limit |
-1, bez możliwości nadpisania |
wtedy ustawić limit pamięci przez kontener lub cgroup |
post_max_size |
8M bez uploadów, 32M z uploadami |
upload_max_filesize poniżej |
| Limit pamięci | przez kontener/cgroup | nie przez RLIMIT_AS ani RLIMIT_DATA |
session.upload_progress.enabled |
0 |
w php.ini, puli lub konfiguracji serwera, nie przez ini_set() ani .user.ini |
fatal_error_backtraces |
0 |
tylko PHP 8.5 |
Ustawienie session.upload_progress.enabled=0 jest zarazem środkiem zaradczym dla zgłoszonej 23 października luki CVE-2026-115560.
Prawidłowe ustawienie obejścia luki PHP
Decydujące jest miejsce. Wartości muszą być ustawione tak, aby aplikacja nie mogła ich nadpisać. Ścieżki i nazwy usług różnią się zależnie od dystrybucji; przykłady zakładają PHP 8.3.
PHP-FPM, w puli (np. /etc/php/8.3/fpm/pool.d/www.conf):
php_admin_value[memory_limit] = -1
php_admin_value[post_max_size] = 8M
php_admin_value[upload_max_filesize] = 6M
php_admin_flag[session.upload_progress.enabled] = off
; tylko PHP 8.5:
; php_admin_flag[fatal_error_backtraces] = off
Apache z mod_php, w konfiguracji serwera lub w VirtualHost:
php_admin_value memory_limit -1
php_admin_value post_max_size 32M
php_admin_value upload_max_filesize 24M
php_admin_flag session.upload_progress.enabled off
Limit pamięci przez cgroup, tutaj przez systemd dla usługi FPM. Wartość dostosowują Państwo do swojego serwera:
# sudo systemctl edit php8.3-fpm
[Service]
MemoryMax=2G
Następnie zrestartować wszystkie workery, inaczej nic z tego nie zadziała: systemctl restart php8.3-fpm lub przy mod_php Apache. Jak sprawdzić, że żaden stary proces już nie działa, opisuje strona Restart PHP-FPM i wszystkich workerów. Ogólne utwardzanie konfiguracji opisuje strona Bezpieczna konfiguracja php.ini.
Proszę przetestować uploady i duże formularze po zmianie. Zbyt wąski post_max_size może blokować zamówienia, formularze aplikacyjne lub uploady mediów. To jeden z powodów, aby nie odkładać aktualizacji na długo.
Dodatkowe warstwy ochrony
Web Application Firewall lub wirtualne łatanie mogą pomóc jako kolejna warstwa. Cloudflare wdrożył reguły ochronne, ale sam ostrzega, że same reguły oparte na danych żądania nie wystarczają. WAF jest więc uzupełnieniem, a nie zamiennikiem. Więcej na stronie WAF i wirtualne łatanie.
Proszę też zabezpieczyć logi serwera od 20 października. Według doniesień medialnych pierwszą próbę ataku zaobserwowano już 17 października; logi są podstawą, jeśli później trzeba będzie wyjaśnić, czy przed poprawką coś się wydarzyło.
Jak konkretnie pomaga PHP SOS?
- Wyjaśnienie sytuacji: Sprawdzamy, czy aktualizacja jest możliwa w krótkim czasie, czy potrzebne jest rozwiązanie przejściowe, i omawiamy z Państwem opcję odłączenia części od sieci.
- Ustawienie środków: Wpisujemy wartości z php.net we właściwym miejscu, ustawiamy limit cgroup i restartujemy wszystkie workery.
- Test działania: Formularze, uploady i procesy zamówień sprawdzamy po zmianie.
- Doprowadzenie do poprawki: Przez usługę łatania PHP planujemy aktualizację i potem w kontrolowany sposób cofamy wartości przejściowe, gdzie przeszkadzają.
Częste pytania
Czy obejście chroni w pełni przed PHP2Shell?
Nie. php.net wyraźnie określa te środki jako przejściowe, a nie jako pełną ochronę. Zmniejszają ryzyko do czasu zainstalowania aktualizacji. BSI zaleca czasowe odłączenie serwerów bez poprawki od sieci.
Czy mogę ustawić te opcje przez .htaccess lub .user.ini?
W przypadku session.upload_progress.enabled php.net wyraźnie wyklucza ini_set() i .user.ini. Także dla memory_limit obowiązuje: wartość musi być ustawiona tak, aby aplikacja nie mogła jej nadpisać. Udaje się to w php.ini, w puli FPM z php_admin_value lub w konfiguracji serwera Apache.
Czy Web Application Firewall wystarcza jako obejście?
Jako dodatkowa warstwa może pomóc. Cloudflare wdrożył reguły ochronne, ale sam zwraca uwagę, że same reguły oparte na danych żądania nie wystarczają. WAF nie zastępuje ani aktualizacji, ani środków przejściowych na serwerze.
Co zrobić, jeśli mam tylko hosting współdzielony?
Wtedy php.ini i restart leżą po stronie dostawcy hostingu. Proszę zapytać konkretnie, czy aktualizację zainstalowano lub środki przejściowe ustawiono oraz czy wszystkie procesy PHP zostały zrestartowane.