Trumpai: Kas nori užsisakyti PHP atnaujinimo diegimą, tam reikia daugiau nei naujų paketų: lemia teisinga paketų būsena, visų PHP procesų paleidimas iš naujo ir tai patvirtinantis įrodymas. Būtent tai teikia mūsų PHP pataisų paslauga. Gaunate rašytinį įrodymą apie kiekvieną serverį, kurį galite pateikti viduje ar trečiosioms šalims.
Kodėl vien PHP atnaujinimo dažnai nepakanka
Nuo 2026 m. spalio 21 d. yra pataisos PHP2Shell spragoms CVE-2026-109618 ir CVE-2026-109619. BSI rekomenduoja nedelsiant atnaujinti. Praktikoje matome tris tipines kliūtis.
Pirma, versijos numeris ne visada rodo tikrąją būseną. Distribucijos ir talpintojai kartais įdiegia atgalinius perkėlimus (backports); tada, pavyzdžiui, Plesk toliau rodo 8.2.34, nors paketų būsena pataisyta. Antra, įdiegus dažnai toliau veikia seni PHP procesai. Nauji failai diske neapsaugo, kol atmintyje dirba seni darbiniai procesai (worker). Trečia, viename serveryje dažnai lygiagrečiai veikia kelios PHP versijos, ir viena jų užmirštama.
PHP atnaujinimo diegimas: ištaisytos versijos
| Šaka | Ištaisyta nuo | Ankstesnė būsena | Pastaba |
|---|---|---|---|
| PHP 8.5 | 8.5.12 | 8.5.11 | papildomai patikrinti fatal_error_backtraces |
| PHP 8.4 | 8.4.27 | 8.4.26 | |
| PHP 8.3 | 8.3.36 | 8.3.35 | |
| PHP 8.2 | 8.2.35 | 8.2.34 | palaikymas baigiasi 2026 m. gruodžio 31 d. |
| PHP 8.1 ir senesnės | oficialių atnaujinimų nėra | – | tik minimalūs šaltinio kodo atgaliniai perkėlimai 7.4, 8.0, 8.1 |
Distribucijų ar talpintojų paketų atveju svarbus ne skaičius po „PHP“, o paketų būsena, kurią teikėjas patvirtina kaip pataisytą. Kaip tai patikrinti patiems, aprašyta puslapyje Kaip teisingai patikrinti PHP versiją ir pataisų būseną.
Kaip PHP SOS padeda konkrečiai?
- Inventorizacija: Surašome visus serverio PHP diegimus, veikimo režimą (PHP-FPM, mod_php, php-cgi, FrankenPHP, LiteSpeed) ir tai, kuri svetainė kokią versiją naudoja.
- Atnaujinimo diegimas: Įdiegiame ištaisytas versijas iš jūsų distribucijos, skydelio ar oficialaus projekto paketų šaltinio. Konteineriams kartu su jumis sukuriame naujus atvaizdus (image).
- Visų procesų paleidimas iš naujo: Visiškai paleidžiame iš naujo PHP-FPM, Apache, LiteSpeed ar atitinkamus darbinius procesus (worker) ir tikriname, kad nė vienas procesas nėra senesnis už atnaujinimą. Pagrindai pateikti puslapyje PHP-FPM ir visų darbinių procesų paleidimas iš naujo.
- Veikimo patikra: Atidarome svarbiausius puslapius ir funkcijas, pavyzdžiui, pradžios puslapį, prisijungimą, formas ir kasą, ir tikriname klaidų žurnalus.
- Įrodymas: Gaunate kiekvieno serverio protokolą su versija, paketų būsena, paleidimo iš naujo laiku ir atvirais punktais.
Tipiškas patikros žingsnis po paleidimo iš naujo atrodo taip:
# PHP CLI ir FPM vykdomojo failo versija (kelias priklauso nuo sistemos)
php -v
php-fpm8.3 -v
# FPM procesų paleidimo laikas: turi būti po atnaujinimo
ps -o pid,lstart,cmd -C php-fpm8.3
Ypatingi atvejai: skydeliai, konteineriai ir kelios PHP versijos
Serveriuose su Plesk ar cPanel PHP versijos dažnai ateina iš skydelio, o ne distribucijos paketų šaltinių. Ten kiekvieną įdiegtą versiją tikriname atskirai, taip pat ir tas, kurios šiuo metu nepriskirtos jokiai svetainei. Nenaudojamas, pasenusias versijas pagal susitarimą pašaliname, kad jos netyčia nebūtų vėl įjungtos.
Docker ir Kubernetes aplinkose nepakanka atnaujinti pagrindinį kompiuterį (host). PHP yra atvaizde (image), todėl spragą uždaro tik naujai sukurtas atvaizdas su pataisyta baze, išleistas į visus veikiančius konteinerius. Kartu tikriname, ar senesni atvaizdai registruose ar diegimuose dar naudojami. Daugiau rasite puslapyje PHP pataisymas Docker konteineriuose.
Su mod_php PHP veikia tiesiai Apache procese. PHP komanda ten riziką vertina didžiausia. Todėl po atnaujinimo pats Apache turi būti visiškai paleistas iš naujo; vien konfigūracijos perkrovimo ne visais atvejais pakanka.
Ką iš mūsų gausite
- kiekvieno serverio pataisų protokolą: įdiegti paketai, versijos, šaltinis, laikas
- įrodymą, kad visi PHP procesai paleisti iš naujo
- patikrintų svetainių ir funkcijų sąrašą
- nuorodas į sistemas, kurių pataisyti nepavyko, su pagrindimu
- rekomendaciją tolesniam keliui, pavyzdžiui, PHP 8.2 atveju dėl artėjančios palaikymo pabaigos
Ko mums reikia iš jūsų
- Prieiga: SSH su administratoriaus teisėmis arba skydelio prieiga (Plesk, cPanel ar pan.)
- Priežiūros langas: kada leidžiama trumpai paleisti iš naujo
- Kontaktinis asmuo: pasiteirauti ir patvirtinti po veikimo patikros
- Atsarginės kopijos: patvirtinimas, kad yra naujausia kopija, arba užsakymas ją prieš tai sukurti
- Pastabos apie nuosavus sprendimus: ypatingi PHP plėtiniai ar konfigūracijos, į kuriuos būtina atsižvelgti
Bendrame talpinime (shared hosting) be savos serverio prieigos patys pataisyti negalime. Tuomet padedame jums užduoti talpintojui tinkamus klausimus ir įvertinti atsakymą.
Ko neapsiimame
Pataisų paslauga uždaro žinomą spragą. Ji neatsako, ar serveris jau buvo kompromituotas prieš atnaujinimą, ir nepašalina įterptos kenkėjiškos programinės įrangos. Jei norite tai sužinoti, tinkamas užsakymas yra PHP2Shell skubi pagalba su pėdsakų paieška.
PHP 8.1 ir senesnėms versijoms oficialių atnaujinimų nebėra. Čia taikome pereinamąsias priemones ir rekomenduojame perėjimą prie palaikomos versijos. Suderinamumo pažado jūsų CMS nesuteikiame atmintinai, o tikriname pagal gamintojo sistemos reikalavimus.
Dažni klausimai
Kodėl po atnaujinimo mano serveris vis dar rodo seną PHP versiją?
Gali būti dvi priežastys. Arba distribucija įdiegė atgalinį perkėlimą (backport), tada versijos numeris lieka tas pats, nors paketų būsena pataisyta. Arba seni PHP procesai dar veikia atmintyje ir juos reikia paleisti iš naujo.
Kurios PHP versijos uždaro PHP2Shell?
Spraga ištaisyta PHP 8.5.12, 8.4.27, 8.3.36 ir 8.2.35 versijose, paskelbtose 2026 m. spalio 21 d. Distribucijų paketų atveju svarbi paketų būsena, kurią teikėjas patvirtina kaip pataisytą.
Ar atnaujinimas gali sustabdyti mano svetainę?
Atnaujinimas toje pačioje pagrindinėje versijoje, pavyzdžiui, nuo 8.3.35 iki 8.3.36, paprastai nekelia problemų. Trumpai paleisti PHP procesus iš naujo vis dėlto reikia. Laiko langą suderiname su jumis, o po to patikriname puslapius.
Ar su pataisa viskas baigta?
Pačios spragos atžvilgiu taip, kai tik visi procesai paleisti iš naujo. Ar prieš pataisą kas nors jau įsilaužė, pataisa neparodo. Tam reikia atskiros patikros.