Dabartinė padėtis: PHP2Shell. Du kritiniai PHP pažeidžiamumai (CVSS 9,2) leidžia vykdyti kenkėjišką kodą be prisijungimo. Pataisos nuo 2026-10-21.Ką dabar daryti →

Ilgalaikis senų PHP versijų palaikymas: galimybės ir ribos

Kas negali nedelsdamas pereiti nuo PHP 8.1 ar senesnės, ilgalaikį palaikymą randa distribucijose, trečiųjų šalių teikėjuose ir komerciniuose sprendimuose. Ką šie keliai duoda, ką reikia gauti raštu ir kur jų ribos.

Būsena 4 min. skaitymoHostingas ir distribucijos

Trumpai: PHP 8.1 ir senesnėms PHP projektas oficialių atnaujinimų nebeteikia. Ilgalaikį palaikymą, vadinamą ir Extended Support, teikia Linux distribucijos, trečiųjų šalių saugyklos arba komerciniai sprendimai, tokie kaip TuxCare ELS ar Zend/HeroDevs. Jis gali užpildyti laiką iki atnaujinimo, jei teikėjas raštu patvirtina jūsų versijos aprėptį. Tačiau jis nepakeičia nei atnaujinimo, nei CMS ir nuosavo kodo priežiūros.

Kodėl klausimas iškyla būtent dabar

2026 m. spalio 21 d. PHP2Shell pataisos pasirodė tik palaikomoms šakoms 8.5, 8.4, 8.3 ir 8.2. 7.4, 8.0 ir 8.1 PHP projektas pateikė tik minimalius šaltinio kodo atgalinius perkėlimus, t. y. pataisas šaltinio kode be paruošto leidimo. Pasak specializuotos spaudos, paveiktos beveik visos versijos iki pat PHP 5.4.

Kokio dydžio yra šis kiekis, rodo CybelAngel analizė: apie 2,24 mln. iš interneto pasiekiamų PHP serverių, iš jų, pasak CybelAngel, 59 proc. su versijomis, kurioms oficialaus ištaisymo nebus. Daugeliui įmonių klausimas dėl ilgalaikio palaikymo tampa ne teorinis. Ir jis dar didės: PHP 8.2 palaikymo pabaigą pasiekia 2026-12-31.

Ko senai sistemai reikia nedelsiant, aprašo PHP 8.1 ir senesnės: kas dabar galioja. Šis straipsnis padeda atsakyti į vidutinio laikotarpio klausimą: kuris kelias išlaiko iki atnaujinimo ir ką jis turi užtikrinti?

PHP Extended Support: kelių apžvalga

Kelias Ką jis teikia Ribos
Distribucijos ilgalaikė priežiūra atgaliniai perkėlimai paketuose, kol palaikoma distribucijos versija tik PHP versijai, kurią ši distribucija pateikia
Trečiosios šalies saugykla pvz., sury.org, pasak pranešimų, su kūriniais nuo 5.6 iki 8.5 tai ne distribucijos saugumo archyvas, pasitikėjimo klausimas
Komercinis ilgalaikis palaikymas pataisyti paketai pasibaigusioms versijoms, pvz., TuxCare ELS, Zend/HeroDevs aprėptį kiekvienai versijai ir CVE reikia patvirtinti, nuolatinės išlaidos
Savarankiškas kūrimas iš šaltinio atgalinių perkėlimų savi kūriniai iš PHP projekto pataisų imlu darbui, kiekvieną kartą pasirodžius pažeidžiamumui reikia iš naujo

Dėl komercinių pasiūlymų: TuxCare savo svetainėje aprašo CVE pataisas pasibaigusioms versijoms nuo PHP 5.2 iki 8.x, pateikiamas per esamą paketų valdymą, skirtas Windows ir paplitusioms Linux distribucijoms. Pastaba tame pačiame puslapyje praneša apie PHP2Shell pataisas pasibaigusioms PHP versijoms. Pasak cPanel dokumentacijos, TuxCare pažeidžiamumams nuo CVSS 7 žada pataisas per 14 dienų nuo paskelbimo; cPanel serveriuose tam domenai perjungiami iš ea-php į alt-php. Dėl Zend/HeroDevs PHP2Shell aprėpties pareiškimo neturėjome.

Pastabas dėl trečiųjų šalių kelio pateikia straipsnis sury.org saugykla.

Ką raštu reikia gauti iš teikėjo

Ilgalaikis palaikymas yra pasitikėjimo paslauga. Perkate pažadą, kad ateities pažeidžiamumai bus uždaryti. Todėl prieš sprendimą paprašykite raštu atsakyti:

  1. Kurios PHP versijos, operacinės sistemos ir paketų pavadinimai tiksliai aprėpiami?
  2. Ar CVE-2026-109618 ir CVE-2026-109619 jūsų versijai uždaryti, su kokia paketo versija ir nuo kada?
  3. Kaip elgiamasi su CVE-2026-115560 ir būsimais tolesniais pranešimais?
  4. Ar jūsų naudojami plėtiniai įtraukti, ar tik PHP branduolys?
  5. Kaip patys patikrinate, kad pataisa įdiegta, pavyzdžiui, per paketo pakeitimų žurnalą?
  6. Kiek laiko trunka jūsų versijos aprėptis ir kaip skelbiama pabaiga?
  7. Kas atsitinka su įdiegtais paketais, kai sutartis baigiasi?

Atsakymų, kurie tik bendrai nurodo „visus saugumo pažeidžiamumus“, nepakanka. Auditoriams, draudikams ir jūsų pačių dokumentacijai svarbus yra konkretus versijos, paketo ir CVE priskyrimas.

Ribos: ko ilgalaikis palaikymas neišsprendžia

Ilgalaikis palaikymas išlaiko PHP vykdymo aplinką naujausios būsenos. Viskas, kas virš jos, lieka jūsų užduotis. O būtent ten senų sistemų atveju paprastai slypi didesnė problema.

  • Programa toliau sensta: CMS ar parduotuvė, kuriai reikia PHP 8.1, dažnai pati nebenaudojama naujausios versijos.
  • Bibliotekos ir plėtiniai: Composer paketai ir įskiepiai senoms PHP versijoms dažnai nebegauna atnaujinimų.
  • Neatstoja paleidimo iš naujo ir patikros: pataisyti paketai veikia tik po visų PHP procesų paleidimo iš naujo ir jie nepašalina kenkėjiškos programinės įrangos, kuri buvo įterpta anksčiau.
  • Techninė skola auga: kuo ilgesnis tiltas, tuo didesnis šuolis vėlesnės migracijos metu.
  • Įrodymai tampa imlesni: auditoriai, klientai ir draudikai vis dažniau klausia apie pataisų būseną. Pasibaigusią PHP versiją su trečiųjų šalių pataisomis galima pagrįsti, bet tai reikalauja daugiau paaiškinimų nei palaikoma versija.

Kada ilgalaikis palaikymas vis dėlto yra tinkamas pasirinkimas? Tipinės trys padėtys: specializuota programa, kurios gamintojas naujesnių PHP versijų dar neatrakino; sena sistema, kurios pakeitimas jau nuspręstas ir kuri turi veikti dar tik kelis mėnesius; arba didelė kodo bazė, kurios perėjimą reikia kruopščiai suplanuoti. Visais trimis atvejais ilgalaikis palaikymas nupirkia laiko tvarkingam sprendimui. Tai nėra sprendimas sistemoms, kuriomis niekas nebenori rūpintis.

Svarbu

Jei sena sistema tarp spalio 17 ir 21 d. be apsaugos veikė internete, pirmiausia išsiaiškinkite, ar ji pažeista. Ilgalaikis palaikymas jau užkrėstai sistemai nieko neapsaugo.

Išėjimo planas yra būtinas

Ilgalaikis palaikymas yra geras sprendimas, kai jis baigiasi data. Nustatykite, iki kada programa turi veikti palaikomoje versijoje, kas atsakingas už migraciją ir kokie tarpiniai tikslai galioja. Kiek laiko PHP šakos oficialiai prižiūrimos, paaiškina PHP leidimų ciklas.

Ar jūsų sistemai labiau apsimoka atnaujinimas, ar atgalinis perkėlimas, apsvarsto straipsnis PHP atnaujinimas ar atgalinis perkėlimas?.

Kaip PHP SOS padeda konkrečiai?

  • Įvertinti padėtį: tikriname jūsų senų sistemų versiją, paketų šaltinį ir pataisų būseną bei ar jos rodo atakos pėdsakų.
  • Patikrinti pasiūlymus: ilgalaikio palaikymo teikėjo rašytinius pažadus palyginame su jūsų faktine įranga.
  • Apsaugoti tiltą: iki atnaujinimo taikome php.net pereinamąsias priemones ir apribojame pasiekiamumą.
  • Įgyvendinti išėjimą: su PHP 8.1 ir senesnių versijų migracija planuojame ir išbandome perėjimą prie palaikomos versijos.

Dažni klausimai

Kas yra PHP Extended Support?

Tai pasiūlymai, kurie PHP versijas po oficialios palaikymo pabaigos toliau aprūpina saugumo pataisomis. Tai gali būti Linux distribucijos, trečiųjų šalių saugyklos arba komerciniai sprendimai, tokie kaip TuxCare ELS ar Zend/HeroDevs.

Ar komercinis ilgalaikis palaikymas apima PHP2Shell?

TuxCare savo svetainėje nurodo pateikęs PHP2Shell pataisas pasibaigusioms PHP versijoms. Vis tiek paprašykite tai raštu patvirtinti jūsų konkrečiai versijai, paketui ir operacinei sistemai bei patikrinkite pakeitimų žurnale.

Ar ilgalaikis palaikymas yra alternatyva atnaujinimui?

Tik laikinai. Jis išlaiko PHP vykdymo aplinką pataisytą, bet ne CMS, plėtinius ir nuosavą kodą, kurie dažnai taip pat pasenę. Todėl išėjimo data turi priklausyti kiekvienam sprendimui dėl ilgalaikio palaikymo.

Kas bus, kai ilgalaikio palaikymo sutartis baigsis?

Pagal cPanel dokumentaciją apie TuxCare, įdiegti paketai toliau veikia, bet naujų saugumo atnaujinimų nebegauna. Sistema tuomet atsiduria tokioje pačioje padėtyje kaip anksčiau, tik vėliau.

Ar tema galioja ir PHP 8.2?

Taip, netrukus. PHP 8.2 su 8.2.35 dar gauna PHP2Shell pataisą, bet 2026-12-31 pasiekia palaikymo pabaigą. Kas eksploatuoja 8.2, perėjimą turėtų planuoti dabar.

Šaltiniai

Skubus kontaktas

Kiekviena valanda svarbi. Parašykite mums dabar.

Trumpai aprašykite sistemą, PHP versiją ir pastebėjimus. Mes atsakysime, išsiaiškinsime padėtį ir dirbsime nuotoliu, kol incidentas bus užbaigtas ir dokumentuotas.

Skubi pagalba