Lühidalt: Kes kasutab veel PHP 8.1 või vanemat, ei saa PHP projektilt enam ametlikke turvauuendusi, ka mitte PHP2Shelli vastu. PHP 8.1 uuendus toetatud versioonile ei ole seetõttu lisa, vaid tegelik lahendus. Kontrollime teie rakendusi, testime koopias, viime kontrollitult üle ja kindlustame aja selle ajani.
Miks PHP 8.1 ja vanemad on nüüd ägedaks riskiks
PHP2Shelli turvaaugud CVE-2026-109618 ja CVE-2026-109619 lubavad koodi käivitada ilma sisselogimata. Parandatud on need versioonides PHP 8.5.12, 8.4.27, 8.3.36 ja 8.2.35. PHP 8.1 ja vanemate jaoks ametlikke uuendusi enam pole, ainult minimaalsed lähtekoodi tagasiportimised versioonidele 7.4, 8.0 ja 8.1. Erialaajakirjanduse andmetel on mõjutatud peaaegu kõik versioonid kuni PHP 5.4-ni.
Mõned distributsioonid ja veebimajutajad paigaldavad oma tagasiportimisi. Kas teie süsteem sinna kuulub, peab pakkuja kinnitama teie konkreetse paketi seisu kohta. Ilma selle kinnituseta tuleks lähtuda sellest, et server on lahti. Mida see üksikasjalikult tähendab, kirjeldab PHP 8.1 ja vanemad: mis nüüd kehtib.
PHP 8.1 uuendus: milline sihtversioon?
Sihtversioon peaks olema selline, mida PHP projekt veel toetab ja mille teie rakendus heaks kiidab. Toe praeguse seisu avaldab php.net toetatud versioonide lehel. PHP 8.2 lõpeb 31.12.2026; üleminek 8.2-le oleks seega vaid vahesamm peagi järgneva projektiga.
Millist PHP versiooni teie CMS või poesüsteem toetab, kontrollime tootja süsteeminõuete järgi, näiteks wordpress.org-il, shopware.com-il või typo3.org-il, mitte mälu põhjal. Sageli tuleb kõigepealt uuendada CMS ise. Vanad poed on tüüpiline juhtum, vt Shopware 5: vanad poed vanal PHP versioonil.
Kuidas PHP SOS konkreetselt aitab?
- Inventuur ja kindlustamine: Kaardistame kõik rakendused, nende PHP versiooni, CMS-i seisu, laiendused ja oma koodi. Paralleelselt rakendame php.net-i järgi ajutised meetmed, et risk migratsioonini väheneks; üksikasjad lehel WAF ja virtuaalne paikamine.
- Ühilduvuse kontroll: Võrdleme tootjate süsteeminõudeid, kontrollime Composeriga sõltuvusi ja otsime oma koodist aegunud funktsioone. Kuidas see sõltuvuste puhul välja näeb, kirjeldab Composeri sõltuvuste kontroll turvaaukude suhtes.
- Test koopias: Rakendus töötab kõigepealt testkeskkonnas uue PHP versiooniga. Vead kõrvaldame seal või dokumenteerime need teie agentuurile.
- Üleminek koos tagasiteega: Live-üleminek toimub kokkulepitud hooldusaknas värske varukoopia ja kindlaks määratud tagasiteega.
- Järelkontroll: Kontrollime pärast üleminekut vealogisid ja keskseid funktsioone ning eemaldame vana PHP versiooni, kui seda enam ei vajata.
Ohutu pilk sellele, millised veebisaidid millist PHP versiooni kasutavad, on paljudes süsteemides võimalik töötavate FPM-i poolide kaudu:
# töötavate PHP-FPM-i põhiprotsesside ja poolide kuvamine
ps -eo pid,cmd | grep -E "php-fpm: (master|pool)" | grep -v grep
# paigaldatud PHP versioonid (Debian/Ubuntu)
ls /etc/php/
Uuendus uuele PHP versioonile ei eemalda kahjulikku tarkvara, mis enne sisse toodi. Kui server oli alates 17.10.2026 kaitsmata võrgus, kuulub juurde jälgede kontroll.
Tüüpilised komistuskivid uuendusel
Enamik probleeme PHP versiooni vahetusel on ettenähtavad, kui teatakse, kust otsida:
- Aegunud laiendused: Pluginad või moodulid, mida enam ei hooldata, uuematel PHP versioonidel sageli ei tööta. Nende jaoks on vaja asendust või kohandust.
- Oma kood: Funktsioonid, mille PHP on vahepeal aegunuks märkinud või eemaldanud, põhjustavad hoiatusi või katkestusi. Rangemad tüübikontrollid toovad päevavalgele vanu programmeerimisvigu.
- Sõltuvused: Composeri kaudu kaasatud teegid nõuavad osaliselt ise uusi versioone ja toovad kaasa muid muudatusi.
- PHP laiendused serveris: Mitte iga laiendus, mis oli vana versiooni all paigaldatud, ei ole uue jaoks automaatselt olemas.
- Cron-tööd ja käsurida: Veebisait töötab juba uuel versioonil, kuid ajastatud ülesanded kutsuvad endiselt vana PHP versiooni.
Kes need punktid eelnevalt kontrollib, lühendab üleminekut ja väldib üllatusi live-töös.
Mida te saate ja mida me vajame
Saate ülevaate kõigist rakendustest algus- ja sihtversiooniga, migratsiooniplaani järjekorra ja riskidega, testiprotokolli, ülemineku dokumentatsiooni ning loendi punktidest, mille teie agentuur või arendaja peab veel tegema.
Teilt vajame:
- server- või paneeliligipääsu ning ligipääsu CMS-i halduskeskkondadele
- juurdepääsu lähtekoodile ja hoidlale oma arenduste puhul
- kontakti agentuuri või arendajaga, kes rakendust tunnevad
- testkeskkonda või nõusolekut see luua
- hooldusakent ja kontaktisikut vastuvõtuks
Mida me ei luba
Me ei luba, et iga vana rakendus töötab uuel PHP versioonil ilma muudatusteta. Edasiarenduseta süsteemide puhul võib olla vajalik suurem ümberehitus või vahetus; ütleme seda avameelselt, niipea kui see hakkab ilmnema. Ühilduvusväited toetame tootjate andmetel. Ja ajutised meetmed ei ole migratsiooni asendus, vaid ületavad ainult aja. Aegunud versioonide pikaajalisi riske kirjeldab PHP End of Life: aegunud versioonide riskid.
Korduma kippuvad küsimused
Kas PHP 8.1 on PHP2Shelli poolt mõjutatud?
Erialaajakirjanduse andmetel on mõjutatud peaaegu kõik versioonid kuni PHP 5.4-ni. PHP 8.1 ja vanemate jaoks PHP projekt ametlikke uuendusi ei anna, ainult minimaalsed lähtekoodi tagasiportimised versioonidele 7.4, 8.0 ja 8.1. Mõned distributsioonid paigaldavad oma tagasiportimisi, seda peab vastav pakkuja kinnitama.
Millisele PHP versioonile peaksin uuendama?
Versioonile, mida PHP projekt veel aktiivselt toetab ja mille teie rakendus tootja süsteeminõuete järgi heaks kiidab. PHP 8.2 jõuab toe lõppu 31.12.2026 ja on seetõttu sihtversioonina vaid tingimisi mõistlik.
Kas ma ei või lihtsalt PHP versiooni majutuspaneelis ümber lülitada?
Tehniliselt sageli ühe klõpsuga. Kas rakendus pärast seda veel töötab, sõltub CMS-i versioonist, laiendustest ja oma koodist. Ilma testita riskite rikete või vigaste funktsioonidega, näiteks poe kassas.
Mis saab siis, kui mu CMS uut PHP versiooni ei toeta?
Siis tuleb kõigepealt CMS-i uuendada, teatud juhtudel uuele põhiversioonile. Edasiarenduseta süsteemide puhul võib olla vajalik vahetus. Seni kindlustame serveri ajutiste meetmetega.