Pe scurt: După actualizarea PHP trebuie să reporniți PHP-FPM și toate celelalte servicii care încarcă PHP. Fișierele noi de pe disc nu sunt suficiente cât timp procese PHP vechi rulează în memorie. Abia după repornire serverul lucrează cu codul corectat din PHP 8.5.12, 8.4.27, 8.3.36, 8.2.35 sau din backportul furnizorului dumneavoastră.
De ce trebuie să reporniți PHP-FPM
O actualizare de pachete înlocuiește fișierele de pe disc. Procesele care rulează deja au însă codul vechi al programului încărcat în memorie și lucrează mai departe cu el. PHP-FPM, Apache cu mod_php sau LiteSpeed își mențin adesea workerii în viață zile întregi.
Pentru PHP2Shell acest lucru este deosebit de important. Vulnerabilitatea CVE-2026-109619 depinde tocmai de starea care persistă între cereri în același worker. Un worker cu cod vechi rămâne vulnerabil, indiferent ce versiune se află pe disc. Potrivit php.net, toți workerii și procesele trebuie, de aceea, repornite.
Unii manageri de pachete repornesc serviciile automat la actualizare, alții nu. Nu vă bazați pe asta, ci verificați rezultatul.
O imagine tipică din viața de zi cu zi: gestionarea pachetelor raportează „PHP actualizat”, monitorizarea nu arată erori, site-ul funcționează. Totuși, workerii vechi deservesc în continuare fiecare cerere, deoarece nimeni nu a repornit serviciul. Din exterior, această stare nu se poate recunoaște. De aceea, verificarea orelor de pornire ale proceselor face parte din fiecare actualizare.
Ce servicii încarcă PHP?
| Mod de operare | Ce se repornește | Comandă tipică (numele diferă în funcție de distribuție) |
|---|---|---|
| PHP-FPM | fiecare serviciu FPM, pentru fiecare versiune instalată | systemctl restart php8.3-fpm sau systemctl restart php-fpm |
| Apache cu mod_php | Apache | systemctl restart apache2 sau systemctl restart httpd |
| php-cgi | serverul web apelant, respectiv wrapperul FastCGI | în funcție de configurație |
| LiteSpeed | LiteSpeed și procesele lsphp | prin administrarea LiteSpeed sau serviciul acesteia |
| FrankenPHP | serviciul FrankenPHP sau containerul | systemctl restart frankenphp sau recrearea containerului |
| Docker, Kubernetes | recrearea containerelor din noua imagine | vezi Cum actualizați PHP în containere Docker |
La mod_php se aplică: actualizarea privește Apache însuși, deoarece PHP se află în fiecare proces Apache. De ce este acest mod de operare deosebit de delicat aflați la De ce mod_php prezintă cel mai mare risc. Pentru LiteSpeed găsiți detalii pe pagina LiteSpeed și LSAPI.
Repornirea PHP-FPM: comenzile
Mai întâi găsiți toate serviciile PHP de pe server. Plesk, cPanel și alte interfețe vin cu propriile servicii PHP, cu nume proprii; lista le arată și pe acestea.
systemctl list-units --type=service | grep -i -E "php|lsws|litespeed|frankenphp|apache2|httpd"
Apoi reporniți fiecare serviciu PHP găsit, nu doar primul:
sudo systemctl restart php8.3-fpm
sudo systemctl restart php8.2-fpm # dacă este instalată o a doua ramură
sudo systemctl restart apache2 # la mod_php; familia RHEL: httpd
Recomandăm restart în loc de reload. La reload, procesul principal rămâne; este gândit pentru modificări de configurație. După o actualizare de securitate doriți să fiți siguri că fiecare proces este nou.
Dacă ați setat suplimentar măsuri provizorii precum session.upload_progress.enabled=0 sau limite fixe de memorie, și acestea acționează abia după repornire. O repornire le rezolvă pe amândouă într-un singur pas.
Verificarea că nu mai rulează niciun worker vechi
Comparați ora de pornire a proceselor cu momentul actualizării. Toate comenzile sunt strict de citire.
ps -o pid,lstart,cmd -C php-fpm8.3 # unter RHEL: -C php-fpm
systemctl status php8.3-fpm # linia „Active: … since …”
needrestart -r l # Debian/Ubuntu, dacă este instalat
Dacă un proces este mai vechi decât actualizarea, el nu a fost cuprins. Cauze frecvente sunt o a doua ramură PHP uitată, un serviciu de pool propriu dintr-un panou de hosting sau un container care a fost doar repornit, în loc să fie creat din noua imagine. Dacă rulează versiunea corectă arată pagina Cum verificați corect versiunea PHP și starea patchului.
Documentarea repornirii
Notați pentru fiecare server momentul actualizării și al repornirii. Acest moment separă perioada în care serverul a fost vulnerabil de perioada de după. Pentru o verificare ulterioară a urmelor, pentru asigurători și pentru o eventuală notificare conform RGPD, este cel mai important punct de referință. Păstrați în plus logurile serverului începând cu 20 octombrie, așa cum recomandă presa de specialitate.
Pe serverele cu multe site-uri merită un tabel scurt: server, serviciu, versiune PHP, versiunea pachetului, momentul repornirii și persoana care a repornit. Astfel lacunele de acoperire se observă repede, de exemplu un pool care a fost trecut cu vederea sau un sistem de test pe care nu-l avea nimeni pe listă.
Cum ajută PHP SOS concret?
În cadrul serviciului de patch PHP preluăm actualizarea și repornirea ca un proces unitar:
- Identificarea serviciilor: Găsim toate procesele care încarcă PHP, inclusiv din panouri de hosting și containere.
- Repornire controlată, în înțelegere cu dumneavoastră, la un moment potrivit și ținând cont de comenzile sau formularele în curs.
- Verificare ulterioară că niciun proces nu este mai vechi decât actualizarea și că site-ul răspunde normal.
- Protocolare: versiuni, stări ale pachetelor și momente ale repornirii pentru fiecare server.
Întrebări frecvente
Este suficient systemctl reload în loc de restart?
Pentru PHP2Shell recomandăm restart. Un reload repornește de obicei workerii, dar procesul principal poate continua să ruleze. Cu restart vă asigurați că nu rămâne niciun proces cu cod vechi. Întreruperii scurte i se opune o dovadă clară.
Trebuie să repornesc tot serverul după actualizarea PHP?
De regulă nu. Este suficient să reporniți toate serviciile care încarcă PHP: PHP-FPM, Apache la mod_php, LiteSpeed, FrankenPHP sau containerele afectate. Repornirea întregului server este varianta simplă dacă nu sunteți sigur ce servicii folosesc PHP.
Repornește furnizorul meu de hosting automat PHP după actualizare?
Depinde de furnizor. Întrebați concret dacă după patch toate procesele PHP au fost repornite și cereți o confirmare scrisă.