Na kratko: Po posodobitvi PHP morate znova zagnati PHP-FPM in vse druge storitve, ki nalagajo PHP. Nove datoteke na disku ne zadoščajo, dokler stari procesi PHP tečejo v pomnilniku. Šele po ponovnem zagonu strežnik dela s popravljeno kodo PHP 8.5.12, 8.4.27, 8.3.36, 8.2.35 ali z backportom vašega ponudnika.
Zakaj morate znova zagnati PHP-FPM
Posodobitev paketa zamenja datoteke na disku. Procesi, ki že tečejo, pa so staro programsko kodo že naložili v pomnilnik in z njo delajo naprej. PHP-FPM, Apache z mod_php ali LiteSpeed svoje workerje pogosto ohranjajo pri življenju več dni.
Za PHP2Shell je to posebej pomembno. Ranljivost CVE-2026-109619 je vezana prav na stanje, ki med zahtevami ostane v istem workerju. Worker s staro kodo ostane ranljiv, ne glede na to, katera različica leži na disku. Po navedbah php.net je zato treba znova zagnati vse workerje in procese.
Nekateri upravljalniki paketov storitve ob posodobitvi samodejno znova zaženejo, drugi ne. Ne zanašajte se na to, ampak preverite rezultat.
Tipična slika iz vsakdana: upravljanje paketov javi „PHP posodobljen“, nadzor ne kaže napak, spletna stran teče. Kljub temu stari workerji še naprej obdelujejo vsako zahtevo, ker nihče ni znova zagnal storitve. Od zunaj tega stanja ni mogoče prepoznati. Zato k vsaki posodobitvi sodi preverjanje časov zagona procesov.
Katere storitve nalagajo PHP?
| Način delovanja | Kaj znova zagnati | Tipičen ukaz (imena se po distribuciji razlikujejo) |
|---|---|---|
| PHP-FPM | vsako storitev FPM, za vsako nameščeno različico | systemctl restart php8.3-fpm ali systemctl restart php-fpm |
| Apache z mod_php | Apache | systemctl restart apache2 ali systemctl restart httpd |
| php-cgi | kličoči spletni strežnik oziroma ovojnico FastCGI | glede na postavitev |
| LiteSpeed | LiteSpeed in procese lsphp | prek upravljanja LiteSpeed ali njegove storitve |
| FrankenPHP | storitev FrankenPHP ali container | systemctl restart frankenphp ali container znova ustvariti |
| Docker, Kubernetes | container znova ustvariti iz nove slike | glejte Popravljanje PHP v containerjih Docker |
Pri mod_php velja: posodobitev zadeva sam Apache, ker PHP tiči v vsakem procesu Apache. Zakaj je ta način delovanja posebej občutljiv, piše na strani Zakaj ima mod_php najvišje tveganje. Za LiteSpeed najdete podrobnosti na strani LiteSpeed in LSAPI.
Ponovni zagon PHP-FPM: ukazi
Najprej poiščite vse storitve PHP na strežniku. Plesk, cPanel in drugi vmesniki prinašajo lastne storitve PHP z lastnimi imeni; seznam jih prikaže.
systemctl list-units --type=service | grep -i -E "php|lsws|litespeed|frankenphp|apache2|httpd"
Nato znova zaženite vsako najdeno storitev PHP, ne samo prve:
sudo systemctl restart php8.3-fpm
sudo systemctl restart php8.2-fpm # če je nameščena še druga veja
sudo systemctl restart apache2 # pri mod_php; družina RHEL: httpd
Priporočamo restart namesto reload. Pri reloadu glavni proces ostane; to je namenjeno spremembam konfiguracije. Po varnostni posodobitvi želite biti prepričani, da je vsak proces nov.
Če ste dodatno uvedli vmesne ukrepe, kot sta session.upload_progress.enabled=0 ali trdne omejitve pomnilnika, tudi ti delujejo šele po ponovnem zagonu. Ponovni zagon opravi oboje v enem koraku.
Preverjanje, da noben star worker ne teče več
Čas zagona procesov primerjajte s časom posodobitve. Vsi ukazi so izključno bralni.
ps -o pid,lstart,cmd -C php-fpm8.3 # unter RHEL: -C php-fpm
systemctl status php8.3-fpm # vrstica „Active: … since …“
needrestart -r l # Debian/Ubuntu, če je nameščen
Če je proces starejši od posodobitve, ni bil zajet. Pogosti vzroki so pozabljena druga veja PHP, lastna storitev poola iz panela gostovanja ali container, ki je bil samo znova zagnan namesto ustvarjen iz nove slike. Ali teče prava različica, pokaže stran Pravilno preverjanje različice PHP in stanja popravkov.
Dokumentiranje ponovnega zagona
Za vsak strežnik zapišite čas posodobitve in ponovnega zagona. Ta trenutek loči čas, ko je bil strežnik ranljiv, od časa po tem. Za poznejši pregled sledi, za zavarovalnice in za morebitno prijavo po GDPR je to najpomembnejša referenčna točka. Poleg tega hranite dnevnike strežnika od 20. oktobra dalje, kot svetuje strokovni tisk.
Na strežnikih z veliko spletnimi stranmi se splača kratka tabela: strežnik, storitev, različica PHP, različica paketa, čas ponovnega zagona in oseba, ki je znova zagnala. Tako se vrzeli v pokritosti hitro opazijo, na primer spregledan pool ali testni sistem, ki ga nihče ni imel na listku.
Kako konkretno pomaga PHP SOS?
V okviru storitve popravljanja PHP posodobitev in ponovni zagon prevzamemo kot povezan potek:
- Ugotoviti storitve: najdemo vse procese, ki nalagajo PHP, tudi iz panelov gostovanja in containerjev.
- Nadzorovano znova zagnati, po dogovoru z vami ob primernem času in z mislijo na tekoča naročila ali obrazce.
- Naknadno preveriti, da noben proces ni starejši od posodobitve in da spletna stran normalno odgovarja.
- Zapisniško beležiti: različice, stanja paketov in čase ponovnega zagona za vsak strežnik.
Pogosta vprašanja
Ali zadošča systemctl reload namesto restart?
Za PHP2Shell priporočamo restart. Reload workerje sicer večinoma znova zažene, glavni proces pa lahko teče naprej. Z restartom zagotovite, da ne ostane noben proces s staro kodo. Kratki prekinitvi stoji nasproti jasno dokazilo.
Ali moram po posodobitvi PHP znova zagnati celoten strežnik?
Praviloma ne. Dovolj je znova zagnati vse storitve, ki nalagajo PHP: PHP-FPM, Apache pri mod_php, LiteSpeed, FrankenPHP ali prizadete containerje. Ponovni zagon celotnega strežnika je preprosta različica, če niste prepričani, katere storitve uporabljajo PHP.
Ali moj ponudnik gostovanja po posodobitvi PHP samodejno znova zažene?
To je odvisno od ponudnika. Vprašajte konkretno, ali so bili po popravku znova zagnani vsi procesi PHP, in si to pisno potrdite.