# Niebezpieczne fałszywe porady o PHP2Shell, które teraz krążą

> Porady o PHP2Shell sprawdzone: które krążące wskazówki nie chronią lub wręcz szkodzą i co zamiast nich radzą php.net, BSI i autorzy fachowi.

Źródło: https://phpsos.de/pl/blog/gefaehrliche-falschtipps/  
Stan: 25.10.2026  
Dostawca: PHP SOS, Pomoc awaryjna PHP i bezpieczeństwo serwerów. Natychmiastowa pomoc przez WhatsApp: https://wa.me/491736494914?text=Dzie%C5%84%20dobry%2C%20PHP%20SOS%2C%20potrzebujemy%20pomocy%20z%20naszym%20serwerem%20PHP.%20Firma%3A%20%E2%80%A6%20Strona%20internetowa%3A%20%E2%80%A6

**Krótko:** Wiele porad o PHP2Shell, które teraz krążą na forach i w sieciach społecznościowych, nie chroni, a nawet szkodzi: blokowanie żądań z cookie sesji, ukrywanie komunikatów o błędach, ustawianie wartości przez `.user.ini` lub aktualizowanie tylko CMS. php.net jest jednoznaczny: nie ma pełnych środków przejściowych, a aktualizacja PHP z restartem wszystkich procesów jest jedyną bezpieczną drogą.

## Dlaczego fałszywe porady są w tej sytuacji niebezpieczne

Przy krytycznej luce, która przyciąga dużą uwagę, powstaje rynek szybkich rozwiązań. Rady są udostępniane, skracane i przekazywane dalej, często bez ograniczeń ze źródła pierwotnego. Przy PHP2Shell dochodzi to, że szczegóły stały się według doniesień znane jeszcze przed oficjalnym terminem, a sytuacja w pierwszych dniach była niejasna.

Fałszywa porada szkodzi podwójnie. Zostawia lukę otwartą i wywołuje poczucie, że coś zrobiono. Właśnie to poczucie sprawia, że właściwa aktualizacja leży odłogiem. Niektóre rady paraliżują dodatkowo własną stronę.

## Dziewięć rad w sprawdzeniu faktów

Poniższa tabela podsumowuje to, co w ostatnich dniach często czytaliśmy, i zestawia te wypowiedzi z tym, co mówią źródła pierwotne.

| Krążąca porada | Dlaczego się nie sprawdza | Co obowiązuje zamiast tego |
|---|---|---|
| Blokować wszystkie żądania z `PHPSESSID` | Wyraźnie odrzucone przez autorów fachowych; paraliżuje logowania i koszyki | Zaktualizować PHP |
| `session.upload_progress.enabled=0` wystarcza | Według doniesień fachowych nie zamyka obu luk | Sensowny środek przejściowy, aktualizacja pozostaje obowiązkiem |
| Ustawiać wartości przez `ini_set()` lub `.user.ini` | php.net wyraźnie temu odradza | Po stronie serwera w php.ini, puli FPM lub konfiguracji serwera |
| Ukrywać komunikaty o błędach | Według php.net nie pomagają `error_reporting`, `display_errors` ani `@` | Aktualizacja; wyświetlania błędów i tak nie pokazywać publicznie |
| Ograniczać pamięć przez `RLIMIT_AS` lub `RLIMIT_DATA` | php.net ostrzega, że właśnie to może wywołać podatną sytuację | Limit przez kontener lub cgroup |
| Aktualizować WordPressa lub wtyczki | Luka leży w interpreterze PHP, a nie w CMS | Zaktualizować środowisko PHP |
| Cloudflare lub inny WAF wystarczy | Ochrona tylko dla ruchu przez usługę; serwery osiągalne bezpośrednio pozostają otwarte | WAF jako dodatkowa warstwa, a nie zastępstwo |
| Przeładować usługę zamiast zrestartować | Według Red Hat przeładowanie nie wystarcza, istniejące workery mogą zachować stary stan | Zrestartować w pełni wszystkie workery |
| Załatane znaczy czyste | Poprawka nie usuwa wcześniej wprowadzonego złośliwego oprogramowania | Zabezpieczyć logi od 20.10. i sprawdzić ślady |

## Trzy najczęstsze błędne przekonania dokładniej

### Zakaz cookies

Porada, by odrzucać wszystkie żądania z cookie sesji `PHPSESSID`, brzmi technicznie i stanowczo. Autorzy fachowi wyraźnie ją odrzucają. W praktyce łamie wszystko, co potrzebuje sesji: konta klientów, koszyki, strefy administracyjne, formularze z ochroną przed fałszerstwem. Ochroną przed luką nie jest.

### Jedno ustawienie, które wszystko rozwiązuje

`session.upload_progress.enabled=0` znajduje się w zaleceniach php.net i jest podanym rozwiązaniem dla CVE-2026-115560. W niektórych artykułach zrobiono z tego „PHP2Shell wyłączone”. Według doniesień fachowych samo to ustawienie nie zamyka jednak obu luk. Także `memory_limit=-1` usuwa według php.net tylko sterowalny wyzwalacz; błąd pamięci na głębszym poziomie może nadal dotrzeć do podatnej ścieżki. Na PHP 8.5 `fatal_error_backtraces=0` blokuje według php.net tylko potwierdzoną drogę przez backtrace.

Jak mimo to ustawić to rozwiązanie poprawnie i na stałe, opisuje artykuł [Wyłączanie session.upload_progress](https://phpsos.de/pl/blog/session-upload-progress-abschalten/). Pełna lista środków przejściowych znajduje się pod hasłem [Środki doraźne bez poprawki](https://phpsos.de/pl/php2shell/sofortmassnahmen-ohne-patch/).

### Tarcza z przodu

Cloudflare ma według własnych informacji od 21 października aktywne reguły ochronne, także dla klientów planu bezpłatnego. Sam Cloudflare wskazuje jednak granice: ochrona działa tylko dla ruchu przechodzącego przez Cloudflare. Jeśli serwer źródłowy jest osiągalny bezpośrednio, zostaje ominięta. Ponadto Cloudflare sprawdza dodatkowo odpowiedź serwera, ponieważ samo żądanie nie zawsze wystarcza. Dlaczego WAF nie zastępuje aktualizacji, wyjaśnia artykuł [WAF czy aktualizacja](https://phpsos.de/pl/blog/waf-oder-update/).

## Porada z ryzykiem: filtrować żądania przesyłania na brzegu

Nie każda niewygodna rada jest fałszywa. Autorzy fachowi proponują jako tymczasowy, nieoficjalny środek blokowanie żądań `multipart/form-data` poza prawdziwymi ścieżkami przesyłania na proxy lub w WAF. Może to zmniejszyć powierzchnię ataku, ale łamie formularze i przesyłanie plików, jeśli lista dozwolonych ścieżek jest niekompletna.

Kto idzie tą drogą, powinien wcześniej sprawdzić ją w środowisku testowym, uzgodnić z działami merytorycznymi i udokumentować jako środek ograniczony w czasie. Zastępstwem aktualizacji nie jest i ta rada.

Wiele rozwiązań WAF oferuje do tego tryb obserwacji, w którym reguły najpierw tylko rejestrują zamiast blokować. Proszę pozwolić nowej regule działać tak przez kilka dni i przeanalizować, które uprawnione żądania zostałyby dotknięte. Dopiero potem przełączyć na blokowanie. W ten sposób unikają Państwo tego, że formularze aplikacyjne, portale klientów lub przesyłanie obrazów w sklepie przestaną działać niepostrzeżenie.

## Jak sprawdzić poradę, zanim ją Państwo wdrożą

Cztery pytania oddzielają przydatne rady od niebezpiecznych:

1. **Źródło:** Czy zalecenie pochodzi z php.net, Państwa dystrybucji, BSI (niemieckiego Federalnego Urzędu ds. Bezpieczeństwa w Technice Informatycznej) lub z imiennie wskazanego autora fachowego?
2. **Zakres twierdzenia:** Czy środek jest opisany jako przejściowy, czy jako rozwiązanie? Przy PHP2Shell rozwiązaniem jest tylko aktualizacja.
3. **Skutek uboczny:** Co się psuje, gdy środek zadziała? Porada bez wskazówki o skutkach ubocznych jest niekompletna.
4. **Miejsce wdrożenia:** Czy ustawienie jest wprowadzane po stronie serwera w sposób niemożliwy do nadpisania, a po nim następuje restart wszystkich workerów?

> **Ważne:**
> Proszę zapisać, jakie środki przejściowe i kiedy zostały ustawione. W ten sposób można je później sprawdzić celowo i rozpoznać, czy rzekoma ochrona nie opóźniła właściwej aktualizacji.

## Jak konkretnie pomaga PHP SOS?

- Sprawdzamy środki, które zostały już u Państwa wdrożone, i oddzielamy skuteczne od nieskutecznych.
- Instalujemy aktualizację PHP, restartujemy wszystkie procesy i dokumentujemy stan.
- Tam, gdzie aktualizacja nie jest jeszcze możliwa, wdrażamy środki przejściowe według php.net po stronie serwera i z dokumentacją.
- Dzięki [WAF i wirtualnemu łataniu](https://phpsos.de/pl/leistungen/waf-virtuelles-patching/) uzupełniamy ochronę na brzegu, nie zastępując aktualizacji.


## Częste pytania

**Czy blokowanie żądań z PHPSESSID chroni?**  
Nie. Autorzy fachowi wyraźnie odrzucają tę krążącą poradę. Paraliżuje ona logowania, koszyki i formularze, nie zamykając luki w interpreterze.

**Czy session.upload_progress.enabled=0 wystarcza przeciw PHP2Shell?**  
Nie. To ustawienie jest jednym z kilku środków przejściowych i według doniesień fachowych nie zamyka obu luk. Ma sens, ale nie zastępuje aktualizacji PHP.

**Czy pomaga wyłączenie display_errors?**  
Dla PHP2Shell nie. php.net zwraca uwagę, że ukrywanie diagnostyki przez error_reporting, display_errors lub operator @ nie pomaga. W produkcji display_errors powinno mimo to być wyłączone z innych powodów.

**Po czym poznać rzetelną poradę?**  
Rzetelna porada podaje swoje źródło, opisuje granice i określa środki przejściowe jako takie. Kto obiecuje, że pojedyncze ustawienie czyni aktualizację zbędną, myli się w przypadku PHP2Shell.

## Źródła

- [php.net: komunikaty o bezpieczeństwie](https://www.php.net/)
- [Red Hat: CVE-2026-109618](https://access.redhat.com/security/cve/CVE-2026-109618)
- [Dr. Web: PHP2Shell und PHP-Versionen](https://www.drweb.de/php2shell-update-php-versionen/)
- [Blog Cloudflare](https://blog.cloudflare.com/)