# WAF i wirtualne łatanie dla PHP

> Wirtualne łatanie PHP: łączymy reguły WAF ze środkami przejściowymi wg php.net, dopóki aktualizacja nie jest możliwa, i planujemy właściwą poprawkę.

Źródło: https://phpsos.de/pl/leistungen/waf-virtuelles-patching/  
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:** Wirtualne łatanie dla PHP przeczekuje czas do zainstalowania właściwej aktualizacji. Łączymy w tym celu reguły Web Application Firewall ze środkami przejściowymi, które php.net opublikował w sprawie PHP2Shell, i od razu ustalamy drogę do regularnej poprawki. Nie zapewnia to pełnej ochrony, ale zmniejsza ryzyko w okresie przejściowym.

## Kiedy wirtualne łatanie dla PHP ma sens

BSI (niemiecki Federalny Urząd ds. Bezpieczeństwa Informacji) zaleca przy PHP2Shell natychmiastową aktualizację, a jeśli nie jest to możliwe, czasowe odłączenie serwerów WWW od sieci. Dla wielu firm jedno i drugie nie jest od razu wykonalne: sklep musi pozostać dostępny, rozwiązanie własne wymaga przed aktualizacją testu albo serwer działa z PHP 8.1 lub starszym, dla którego nie ma już oficjalnych aktualizacji.

W takich przypadkach wirtualne łatanie jest pomostem. Nie zastępuje decyzji, czy praca offline nie byłaby stosowniejsza. Tę ocenę podejmują Państwo, my dostarczamy ocenę techniczną.

## Dlaczego sam WAF nie wystarcza

Cloudflare zgłosił zaobserwowane próby ataków i wdrożył reguły ochronne, ale ostrzega, że same reguły oparte na danych żądania nie wystarczają. Przyczyna leży w charakterze luk. W przypadku CVE-2026-109618 stan braku pamięci (out-of-memory) może przerwać PHP, gdy dane żądania są zainicjowane tylko częściowo. W przypadku CVE-2026-109619 stan wewnętrzny może pozostać po zwolnieniu pamięci i zostać wykorzystany przez późniejsze żądanie w tym samym workerze. Takie błędy zależą od stanu serwera, a nie tylko od treści pojedynczego żądania.

Dlatego stawiamy na kilka warstw: reguły WAF przed serwerem, środki przejściowe w samym PHP i wzmożoną obserwację serwera. Każda warstwa wychwytuje część, żadna sama nie wystarcza. Razem dają Państwu czas na uporządkowane zainstalowanie aktualizacji.

## Środki przejściowe wg php.net

php.net podaje kilka ustawień, które obniżają ryzyko, wyraźnie bez pełnej ochrony. Ważne, aby aplikacje nie mogły nadpisać tych wartości. Przykład puli PHP-FPM z uploadami:

```ini
; Środki przejściowe PHP2Shell (brak pełnej ochrony), potem zrestartować wszystkie workery
php_admin_value[memory_limit] = -1
php_admin_value[post_max_size] = 32M
php_admin_value[upload_max_filesize] = 30M
php_admin_flag[session.upload_progress.enabled] = off
; tylko PHP 8.5:
php_admin_flag[fatal_error_backtraces] = off
```

Bez uploadów php.net zaleca `post_max_size = 8M`. Ponieważ `memory_limit` zostaje zniesiony, potrzebny jest do tego limit pamięci na poziomie kontenera lub cgroup, a nie przez `RLIMIT_AS` czy `RLIMIT_DATA`. Ustawienie `session.upload_progress.enabled=0` należy do php.ini, puli FPM lub konfiguracji serwera, a nie do `ini_set()` ani `.user.ini`. Jest ono zarazem środkiem zaradczym dla wskazówki dotyczącej [CVE-2026-115560](https://phpsos.de/pl/php2shell/cve-2026-115560/). Wszystkie środki w zestawieniu znajdą Państwo na stronie [Środki natychmiastowe, gdy nie można jeszcze załatać](https://phpsos.de/pl/php2shell/sofortmassnahmen-ohne-patch/).

> **Ważne:**
> Środki przejściowe działają dopiero po restarcie wszystkich workerów PHP. I chronią tylko przed przyszłymi atakami: czy ktoś włamał się wcześniej, nie rozstrzygają.

## Kiedy lepszym wyborem jest praca offline

Wirtualne łatanie nie jest w każdej sytuacji właściwą odpowiedzią. W niektórych konstelacjach radzimy postąpić zgodnie z BSI i czasowo odłączyć serwer WWW od sieci do czasu załatania:

- serwer działa z **Apache i mod_php**, gdzie zespół PHP ocenia ryzyko najwyżej, a exploit pokazano, zanim w ogóle uruchomi się kod aplikacji
- na serwerze znajdują się **dane szczególnie wymagające ochrony**, na przykład dane zdrowotne, dane klientów kancelarii lub dane płatnicze
- **nie ma możliwości** trwałego ustawienia środków przejściowych w konfiguracji serwera, na przykład w niektórych pakietach hostingu współdzielonego
- istnieją już **oznaki**, że serwer został zaatakowany

Czasowa praca offline nie oznacza, że Państwa strona została zhakowana. Niektórzy dostawcy z ostrożności wyłączyli strony. Krótka, rzeczowa strona informacyjna dla odwiedzających jest wtedy zwykle lepszym rozwiązaniem niż niewyjaśniona niedostępność.

## Jak konkretnie pomaga PHP SOS?

1. **Sprawdzenie sytuacji:** Rejestrujemy wersje PHP, tryby pracy i istniejące warstwy ochrony, takie jak CDN, WAF czy reverse proxy. Przy mod_php zwracamy uwagę na podwyższone ryzyko, które widzi tam zespół PHP.
2. **Budowa warstw:** Aktywujemy lub uzupełniamy reguły WAF, ustawiamy środki przejściowe na stałe w konfiguracji serwera i ograniczamy pamięć przez kontener lub cgroup. Dla konfiguracji Nginx opieramy się na [Zabezpieczanie Nginx z PHP-FPM](https://phpsos.de/pl/server/nginx-php-fpm/).
3. **Restart i test:** Wszystkie procesy PHP są restartowane, następnie sprawdzamy uploady, formularze, logowanie i kasę.
4. **Obserwacja:** W okresie przejściowym zwracamy większą uwagę na awarie workerów, skoki zużycia pamięci i nietypowe procesy.
5. **Planowanie poprawki:** Ustalamy, kiedy i jak nastąpi regularna aktualizacja, i wdrażamy ją przez [usługę łatania PHP](https://phpsos.de/pl/leistungen/php-patch-service/).

## Co Państwo otrzymują, czego potrzebujemy i czego nie obiecujemy

Otrzymują Państwo dokumentację wszystkich ustawionych reguł i ustawień wraz z uzasadnieniem, wyniki testów oraz plan terminów i działań dla właściwej poprawki. Od Państwa potrzebujemy dostępu do serwera lub panelu, dostępu do CDN lub WAF, jeśli istnieją, technicznej osoby kontaktowej oraz informacji o funkcjach uploadu w Państwa aplikacjach.

Nie obiecujemy, że wirtualne łatanie zapobiegnie atakowi. Obniża ono ryzyko na ograniczony czas. Przy PHP 8.1 i starszym nie jest stanem trwałym; tu w planie powinna znaleźć się [migracja na wspieraną wersję](https://phpsos.de/pl/leistungen/php-migration-legacy/).


## Częste pytania

**Czym jest wirtualne łatanie?**  
Wirtualne łatanie oznacza osłonięcie znanej luki przed aplikacją zamiast zmieniania samego kodu. Odbywa się to zwykle przez Web Application Firewall lub zmiany konfiguracji. Jest to rozwiązanie pomostowe, a nie zamiennik aktualizacji.

**Czy WAF mojego dostawcy CDN wystarcza przeciw PHP2Shell?**  
Samodzielnie zwykle nie. Cloudflare wdrożył reguły ochronne, ale sam ostrzega, że same reguły oparte na danych żądania nie wystarczają. WAF jest dodatkową warstwą obok środków przejściowych i poprawki.

**Jak długo mogę polegać na wirtualnym łataniu?**  
Jak najkrócej. Ma ono przeczekać czas do regularnej aktualizacji, na przykład do wolnego okna serwisowego lub przetestowania aplikacji. Przy PHP 8.1 i starszym potrzebny jest do tego plan migracji.

**Czy środki przejściowe mogą zakłócić działanie mojej strony?**  
Tak, jest to możliwe. Mniejsze limity uploadu mogą uniemożliwić wysyłanie dużych plików, a wyłączenie session upload progress dotyczy wskaźników postępu przy wysyłaniu. Po każdej zmianie testujemy najważniejsze funkcje.

## Źródła

- [php.net: komunikaty o bezpieczeństwie i środki przejściowe](https://www.php.net/)
- [BSI: Federalny Urząd ds. Bezpieczeństwa Informacji (Niemcy)](https://www.bsi.bund.de/)
- [OWASP Top 10](https://owasp.org/www-project-top-ten/)
- [TechTarget: PHP2Shell, 22M exposed servers at risk](https://www.techtarget.com/cybersecurity/news/366652444/PHP2Shell-22M-exposed-servers-at-risk-as-emergency-patches-released)