Lühidalt: PHP 8.1 turvaaugu PHP2Shell vastu ametlikku uuendust ei ole. PHP projekt pakub versioonidele 7.4, 8.0 ja 8.1 ainult minimaalseid lähtekoodi tagasiportimisi, mitte valmis väljalaskeid. Kes neid versioone kasutab, vajab pakkuja kinnitatud tagasiportimist või ajutisi meetmeid ning peaks üleminekut toetatud versioonile nüüd planeerima.
Kas PHP 8.1 turvaaugu vastu on uuendus?
PHP projektilt mitte. 21. oktoobril 2026 ilmusid ametlikud parandused ainult toetatud harudele: 8.5.12, 8.4.27, 8.3.36 ja 8.2.35. PHP 8.1 ja vanemad versioonid ei saa enam ametlikke uuendusi.
Mõjutatud on need siiski. Erialaajakirjanduse andmetel ulatuvad haavatavad versioonid peaaegu katkematult PHP 5.4-ni. Kes kasutab ühte neist versioonidest avalikult ligipääsetavana, on seega kriitilise turvaaugu (CVSS v4.0 9,2) ees ilma valmis paigata.
Paljudele ettevõtetele on see üllatus, sest sellised süsteemid töötavad sageli aastaid stabiilselt ja märkamatult. Et versioon enam uuendusi ei saa, igapäevaselt ei märka, kuni ilmub turvaauk nagu PHP2Shell. Versioonide 7.4, 8.0 ja 8.1 lähtekoodi tagasiportimised on erand, mitte tavapärase hoolduse taasalustamine.
Mida lähtekoodi tagasiportimised tähendavad
Versioonidele 7.4, 8.0 ja 8.1 on olemas minimaalsed lähtekoodi tagasiportimised. Need on lähtekoodi parandused, mis on üle viidud nendele vanematele harudele. Need ei ole ametlik väljalase versiooninumbri, testitud paketi ja muudatuslogiga.
Praktikas tähendab see: keegi peab tagasiportimise üle võtma, PHP selle põhjal uuesti ehitama, testima ja juurutama. See võib toimuda kolmel viisil:
- Teie distributsioon võtab parenduse oma pakettidesse, näiteks pikaajalise hoolduse raames.
- Teie veebimajutaja ehitab oma PHP paketid ja paigaldab tagasiportimise.
- Teie ise või teenusepakkuja ehitab PHP lähtekoodist. See on nõudlik ja tuleb iga järgneva turvaaugu korral korrata.
Kas teie süsteem on tagasiportimise saanud, kontrollite paketi muudatuslogist:
apt changelog php8.1-fpm | grep -i -E "CVE-2026-109618|CVE-2026-109619" # Debian/Ubuntu
rpm -q --changelog php-fpm | grep -i -E "CVE-2026-109618|CVE-2026-109619" # RHEL-i perekond
Paketinimed erinevad distributsiooni ja paketiallika kaupa. Kui kirje puudub, küsige pakkujalt. Kuidas kontroll üksikasjalikult toimub, on kirjas lehel PHP versiooni ja paigatud seisu õige kontroll.
Vana serveri kindlustamine kuni migratsioonini
Kuni kinnitatud tagasiportimist ei tööta, kehtivad php.net-i ajutised meetmed: üle kirjutamatu memory_limit=-1 mälupiiranguga cgroupi kaudu, post_max_size 8M või 32M koos sellest väiksema upload_max_filesize-ga ja session.upload_progress.enabled=0 serveri seadistuses, seejärel kõigi tööprotsesside taaskäivitus. Need ei ole täielik kaitse. Üksikasjad lehel Kohesed meetmed, kui te veel paigata ei saa.
Lisaks tulevad meetmed, mis vähendavad kättesaadavust: haldusalad ainult VPN-i või lubatud IP-aadresside kaudu, mittevajalike veebisaitide väljalülitamine, serveri ligipääsude range piiramine. BSI soovitab serverid ilma uuenduseta ajutiselt võrgust maha võtta. Vana, raskesti migreeritava rakenduse puhul võib isoleeritud lahendus olla ausam vastus kui töö avatud internetis.
Kui server PHP 8.1 või vanemaga töötas alates 17. oktoobrist kaitsmata võrgus, võtke seda tõsiselt: BSI arvestas kiire laiaulatusliku ärakasutamisega. Kindlustage logid alates 20. oktoobrist ja laske serveril jälgi kontrollida, enne kui migreerite.
Migratsiooni planeerimine: millisele versioonile?
Eesmärk on versioon, mida PHP projekt toetab ja mida teie rakendus talub. PHP 8.2 sulgeb turvaaugu alates 8.2.35, kuid jõuab 31.12.2026 toe lõppu. Kes nüüd migreerib, peaks seetõttu võimalusel valima 8.3 või uuema, kui rakendus seda lubab. Toe praeguse seisu nimetab php.net toetatud versioonide lehel.
Millist PHP versiooni teie CMS või pood toetab, kontrollite tootja süsteeminõuete järgi, näiteks wordpress.org-il, shopware.com-il või typo3.org-il. Sageli tuleb kõigepealt uuendada rakendus ise, enne kui PHP saab vahetuda. Tüüpiline juhtum on vanemad poed, mida kirjeldame lehel Shopware 5. Taustateavet aegunud versioonide tagajärgede kohta leiate lehelt PHP End of Life: aegunud versioonide riskid.
| Samm | Sisu |
|---|---|
| Seis | PHP versioon, rakendus, laiendused, oma kohandused |
| Nõuded | toetatud PHP versioonid tootja järgi |
| Testkeskkond | koopia uue PHP versiooniga, vealogi analüüs |
| Üleminek | planeeritud hooldusaken, tagasitee ette valmistatud |
| Järeltöö | üleminekuväärtuste kontroll, seire sisseseadmine |
Kuidas PHP SOS konkreetselt aitab?
PHP 8.1 ja vanemate migratsiooniga juhime teid vanalt versioonilt toetatud versioonile:
- Kohe kindlustada: kontrollida tagasiportimise seisu, seada ajutised meetmed, vähendada kättesaadavust.
- Jälgi kontrollida: kindlustada logid alates 20. oktoobrist ja analüüsida kõrvalekaldeid.
- Migratsiooni ette valmistada: selgitada ühilduvus tootja järgi, ehitada testkeskkond, kõrvaldada vead.
- Üle minna ja tõendada: paigaldada uus PHP versioon, käivitada kõik protsessid uuesti, dokumenteerida seis.
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 kaasa arvatud. PHP projekt ei avalda 8.1 jaoks enam ametlikke uuendusi, vaid ainult minimaalseid lähtekoodi tagasiportimisi.
Mis on lähtekoodi tagasiportimine?
Lähtekoodi parandus, mis on üle viidud vanemale versiooniharule. See ei ole valmis väljalase: keegi peab selle üle võtma, PHP uuesti ehitama, testima ja juurutama. Seda võib teha teie distributsiooni pakkuja, veebimajutaja või teenusepakkuja.
Kas piisab PHP 8.2-le üleminekust?
Lühiajaliselt sulgeb PHP 8.2.35 turvaaugu. PHP 8.2 jõuab aga 31.12.2026 toe lõppu. Kes niikuinii migreerib, peaks seetõttu kontrollima, kas rakendus toetab tootja andmetel ka 8.3 või uuemat.
Minu pood töötab ainult PHP 7.4-ga. Mida nüüd?
Siis on vaja kahte asja paralleelselt: kindlustada server ajutiste meetmete ja isoleerimisega ning viia rakendus versioonile, mis talub toetatud PHP versiooni. Milline see on, on kirjas tootja süsteeminõuetes.