# Serwer Plesk: kontrola wersji PHP i instalacja poprawek

> Aktualizacja PHP w Plesk po PHP2Shell: jak sprawdzić handlery, stan pakietów i backporty, zrestartować wszystkie usługi PHP-FPM i udokumentować poprawkę.

Źródło: https://phpsos.de/pl/server/plesk/  
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:** Aktualizacja PHP w Plesk jest zakończona dopiero wtedy, gdy każda zainstalowana wersja PHP ma stan z usuniętą luką, wszystkie usługi PHP-FPM zostały zrestartowane, a Państwo mogą to udowodnić stanem pakietów i czasem startu procesów. Sam numer wersji widoczny w panelu nie wystarcza, ponieważ backporty często zostawiają go bez zmian.

## O co chodzi w PHP2Shell na serwerach Plesk

PHP2Shell oznacza dwie krytyczne luki w samym PHP (CVE-2026-109618 i CVE-2026-109619, każda CVSS v4.0 9.2). Pozwalają one atakującym wykonać kod na serwerze bez logowania. Dotyczą między innymi PHP-FPM oraz Apache z mod_php, czyli dokładnie tych trybów pracy, które Plesk konfiguruje dla stron internetowych.

W dniu 21.10.2026 projekt PHP opublikował wersje z usuniętą luką: 8.5.12, 8.4.27, 8.3.36 i 8.2.35. Dla PHP 8.1 i starszych nie ma już oficjalnych aktualizacji. Serwery Plesk mają pewną osobliwość: często działa na nich obok siebie kilka wersji PHP, część od samego Plesk, część od systemu operacyjnego. Każda z nich wymaga osobnej kontroli.

> **Ważne:**
> Aktualizacja w panelu podmienia pliki na dysku. Dopóki w pamięci działają stare procesy PHP, luka pozostaje otwarta. Bez restartu wszystkich procesów roboczych poprawka nie działa.

## Aktualizacja PHP w Plesk: najpierw spis zasobów

Zanim cokolwiek Państwo zaktualizują, proszę sporządzić listę wszystkich handlerów PHP i domen, które z nich korzystają. Można to zrobić w panelu (Narzędzia i ustawienia, Ustawienia PHP) lub z wiersza poleceń. Poniższe polecenia niczego nie zmieniają, tylko odczytują.

```bash
# Wszystkie zarejestrowane handlery PHP z wersją i ścieżką
plesk bin php_handler --list

# Wersja każdej zainstalowanej przez Plesk wersji PHP (ścieżka jako przykład)
for p in /opt/plesk/php/*/bin/php; do echo "$p"; "$p" -v | head -1; done
```

Dla każdego handlera proszę zanotować: wersję, tryb pracy (FPM, FastCGI, moduł Apache) i liczbę domen. Handler bez domeny nie oznacza dania spokoju. Może zostać przypisany później albo działać na subdomenach testowych.

## Sprawdzać stan pakietów, a nie wskazanie

Plesk pokazuje numer wersji, który zgłasza samo PHP. Jeśli Plesk lub dystrybucja dostarcza poprawkę jako backport, nadal może tam widnieć na przykład 8.2.34, mimo że korekta jest zawarta. I odwrotnie, pozornie aktualny numer może mylić, jeśli pakiet nie został jeszcze zaktualizowany. Rozstrzygają zainstalowany stan pakietu i pisemne potwierdzenie dostawcy.

```bash
# Debian/Ubuntu (nazwy pakietów jako przykład)
dpkg -l | grep -E 'plesk-php|php[0-9.]+-(fpm|cli)'

# AlmaLinux/Rocky/RHEL (nazwy pakietów jako przykład)
rpm -qa | grep -E 'plesk-php|^php' | sort
```

Proszę porównać wersje pakietów z informacjami w dziennikach zmian Plesk i w uwagach Państwa dystrybucji. Jeśli nie jest tam jednoznacznie udokumentowane, że CVE-2026-109618 i CVE-2026-109619 zostały usunięte, proszę zapytać dostawcę. Wzór takiego pytania znajdą Państwo w artykule [Jak zapytać hostera o stan poprawek](https://phpsos.de/pl/ratgeber/hoster-patch-status-erfragen/).

## Instalacja aktualizacji i restart wszystkich procesów roboczych

Właściwa aktualizacja przebiega przez instalator Plesk lub menedżer pakietów systemu. Potem następuje krok, którego najczęściej brakuje: restart. W Plesk każda wersja PHP ma własną usługę FPM. Proszę zrestartować wszystkie, a nie tylko tę dla głównej domeny.

```bash
# Wypisz wszystkie usługi PHP-FPM (nazwy usług jako przykład)
systemctl list-units --type=service | grep -i 'php.*fpm'

# Restart każdej usługi, np.:
systemctl restart plesk-php84-fpm

# Sprawdź czas startu działających procesów PHP
ps -eo pid,lstart,cmd | grep -E 'php-fpm|php-cgi' | grep -v grep
```

Jeśli domena działa na Apache i mod_php, proszę zrestartować Apache w całości. Jeśli czas startu procesu PHP jest wcześniejszy niż aktualizacja, proces nie został jeszcze odnowiony. Więcej o tym kroku znajdą Państwo w artykule [Restart PHP-FPM i wszystkich procesów roboczych](https://phpsos.de/pl/php2shell/php-fpm-neustart/).

## Ochrona przejściowa, gdy aktualizacji jeszcze brakuje

Jeśli dla danej wersji nie ma jeszcze poprawki, php.net zaleca środki przejściowe. Nie są one pełną ochroną. W Plesk wartości, których aplikacje nie mogą nadpisywać, ustawia się jako `php_admin_value` w dodatkowych dyrektywach FPM domeny albo ogólnie dla serwera w pliku php.ini danej wersji.

```ini
; Przykład dodatkowych dyrektyw PHP-FPM w Plesk
php_admin_value[session.upload_progress.enabled] = 0
php_admin_value[post_max_size] = 8M
php_admin_value[upload_max_filesize] = 6M
```

Przy przesyłaniu plików php.net przewiduje `post_max_size = 32M`, a `upload_max_filesize` niższe. W PHP 8.5 dochodzi `fatal_error_backtraces=0`. Ograniczenie pamięci przez `memory_limit=-1` powinno być stosowane wyłącznie razem z limitem na poziomie kontenera lub cgroup. Potem znów następuje restart wszystkich procesów roboczych. Szczegóły podaje artykuł [Środki doraźne bez poprawki](https://phpsos.de/pl/php2shell/sofortmassnahmen-ohne-patch/). BSI (niemiecki Federalny Urząd ds. Bezpieczeństwa w Technice Informatycznej) zaleca czasowe odłączenie serwerów WWW od sieci, jeśli aktualizacja nie jest możliwa od razu.

## Po poprawce: zabezpieczyć logi i szukać śladów

Poprawka zamyka lukę na przyszłość. Nie usuwa złośliwego oprogramowania wprowadzonego wcześniej i nie dowodzi, że nic się nie stało. Dlatego proszę zachować logi serwera WWW od 20.10.2026. Plesk zapisuje je dla każdej domeny w katalogu `logs`; w tej sytuacji nie należy skracać czasu ich przechowywania.

Proszę zwrócić uwagę na nowe lub zmienione pliki PHP w katalogach uploadu, nieznane zadania harmonogramu i nowe konta administratorów. Opublikowanych, potwierdzonych wskaźników naruszenia (Indicators of Compromise) dotąd nie ma; wykrywanie opiera się na analizie zachowania. Jeśli znajdą Państwo nieprawidłowości, nie należy działać dalej na własną rękę, tylko najpierw zabezpieczyć stan systemu.

## Jak konkretnie pomaga PHP SOS?

- Rejestrujemy wszystkie handlery PHP na Państwa serwerze Plesk, przypisujemy do nich domeny i sprawdzamy rzeczywisty stan pakietów dla każdej wersji.
- W ramach naszej [usługi aktualizacji PHP](https://phpsos.de/pl/leistungen/php-patch-service/) instalujemy aktualizacje, restartujemy wszystkie usługi i dokumentujemy czasy startu procesów jako dowód.
- Tam, gdzie brakuje poprawki, ustawiamy środki przejściowe wg php.net ogólnie dla serwera i w sposób niemożliwy do nadpisania.
- Zabezpieczamy logi i szukamy śladów włamania, a w razie ustaleń wdrażamy [reagowanie na incydenty](https://phpsos.de/pl/leistungen/incident-response/).
- Następnie trwale utwardzamy serwer i usuwamy niepotrzebne wersje PHP.


## Częste pytania

**Dlaczego Plesk po aktualizacji nadal pokazuje PHP 8.2.34?**  
Dystrybucje i dostawcy czasem instalują poprawki bezpieczeństwa jako backport, nie zmieniając numeru wersji. Rozstrzygający jest wtedy stan pakietu i potwierdzenie dostawcy. Samo wskazanie w panelu nie dowodzi ani poprawki, ani jej braku.

**Czy wystarczy kliknąć w panelu Plesk przycisk Aktualizuj?**  
Aktualizacja zapisuje nowe pliki, ale działające procesy PHP nadal pracują w pamięci na starym kodzie. Nowy stan jest aktywny dopiero po restarcie wszystkich usług PHP-FPM i serwera WWW. Proszę potem sprawdzić czas startu procesów.

**Czy muszę łatać także wersje PHP, z których nie korzysta żadna domena?**  
Tak, o ile pozostają zainstalowane. Nieużywany handler może zostać później przypadkowo przypisany albo być osiągalny przez środowiska testowe. Niepotrzebne wersje lepiej odinstalować w całości.

**Czy aktualizacja WordPressa w Plesk Toolkit pomaga na PHP2Shell?**  
Nie. PHP2Shell dotyczy samego PHP, a nie CMS. Aktualizacja CMS jest mimo to sensowna, ale tej luki nie zamyka.

## Źródła

- [php.net: komunikaty bezpieczeństwa](https://www.php.net/)
- [PHP 8 ChangeLog](https://www.php.net/ChangeLog-8.php)
- [php.net: obsługiwane wersje](https://www.php.net/supported-versions.php)
- [BSI](https://www.bsi.bund.de/)