21 października 2026 o 16:00 projekt PHP opublikował wydanie bezpieczeństwa z poprawkami dwóch krytycznych podatności: CVE-2026-109618 i CVE-2026-109619 (CVSS 4.0: 9.2). Błędy dotyczą obsługi sesji i pamięci podręcznej opcache i w złośliwie przygotowanym żądaniu mogą prowadzić do zdalnego wykonania kodu – czyli do przejęcia strony. Podatne są wszystkie gałęzie PHP, aż do 5.x.
Projekt PHP łata tylko wersje, które wciąż wspiera: 8.2, 8.3, 8.4 i 8.5. Strony na PHP 8.1, 7.4, 7.0 czy 5.6 poprawek od projektu nie dostaną. A takich stron wciąż jest sporo: sklepy i systemy pisane lata temu, których przepisanie kosztuje więcej, niż są warte, ale które nadal zarabiają.
Poniżej opisujemy, co zrobiliśmy tego dnia i dlaczego mogliśmy to zrobić szybko.
Oś czasu
| Godzina (21.10) | Co się działo |
|---|---|
| 13:30 | Wydanie bezpieczeństwa jest zapowiedziane na 16:00. Decyzja: starszych wersji nie zostawiamy – łatamy je sami. |
| 15:15 | Wszystkie starsze wersje PHP przebudowane na gałęziach z poprawkami bezpieczeństwa – gotowa baza pod nowe łatki. |
| 16:00 | Projekt PHP publikuje poprawki. |
| ok. 18:00 | Nowe buildy wszystkich oferowanych wersji, od 5.3 do 8.5, zbudowane i sprawdzone w środowisku testowym. |
| ok. 19:00 | Nowe buildy działają na całym hostingu. |
Od publikacji poprawek do załatania ostatniej strony minęło niecałe trzy godziny. Klienci nie musieli niczego zmieniać, zgłaszać ani przełączać.
Co dokładnie zrobiliśmy
Wersje wspierane (8.2–8.5) przenieśliśmy na wydania z tego samego dnia: 8.2.35, 8.3.36, 8.4.27 i 8.5.12.
Wersje bez wsparcia (5.3, 5.5, 5.6, 7.0, 7.4, 8.0, 8.1) to siedem gałęzi, których projekt PHP już nie łata. Dla nich:
- przenieśliśmy poprawki do starszego kodu (backport), korzystając z prowadzonych przez społeczność gałęzi z poprawkami bezpieczeństwa dla starszych PHP (php-src-backports – dziękujemy!);
- dla 7.4 i 8.1 porównaliśmy wynik z minimalnymi poprawkami przygotowanymi w samym projekcie PHP;
- łącznie to ponad 12 tysięcy linii zmian w siedmiu gałęziach.
Każda wersja przed wdrożeniem została zbudowana od zera i uruchomiona w środowisku testowym. Na wypadek, gdyby buildy się opóźniły, mieliśmy gotowe obejście w konfiguracji PHP, które blokowało ścieżkę ataku. Nie było potrzebne.
Po wdrożeniu nasz skaner podatności nauczył się rozpoznawać poprawki przeniesione do starszych gałęzi, więc pokazuje to, co naprawdę jest w naszych buildach, a nie tylko numer wersji. Dzięki temu widzimy też starsze krytyczne błędy, których gałęzie społeczności nie obejmują – i te łatamy teraz sami.
Dlaczego mogliśmy to zrobić tak szybko
Trzy decyzje, które podjęliśmy dużo wcześniej:
- Sami budujemy PHP. Nie czekamy, aż dystrybucja systemu wyda paczkę – a dla starszych wersji nigdy by jej nie wydała. Każda wersja PHP, którą oferujemy, powstaje z naszego przepisu, więc nowa łatka to nowy build, a nie prośba do kogoś innego.
- Każdy klient ma własny kontener. Strony różnych klientów nie dzielą jednego środowiska, a nowy build PHP trafia do kontenerów jako nowy obraz – ten sam, sprawdzony wcześniej w testach.
- Wdrożenie to jedna operacja. Przełączenie całego hostingu na nowy obraz robimy z panelu, kontener po kontenerze, z kontrolą, czy każdy wstał poprawnie.
Co to oznacza dla Ciebie
Jeśli Twoja strona działa u nas – na dowolnej oferowanej wersji PHP, od 5.3 do 8.5 – jest już załatana na obie podatności. Nie musisz nic robić.
Jeśli możesz, i tak przejdź na nowszą wersję PHP: dostajesz wtedy poprawki od samego projektu, wyższą wydajność i wsparcie nowych bibliotek. Ale jeśli Twoja aplikacja wymaga starszego PHP, nie musisz wybierać między działaniem a bezpieczeństwem – starsze wersje utrzymujemy i łatamy.
Szukasz hostingu dla starszej aplikacji, z którą inni każą się przeprowadzić? Zobacz nasz hosting – PHP od 5.3 do 8.5, każda oferowana wersja z poprawkami bezpieczeństwa.