Trumpai: PHP 8.1 saugumo spragai PHP2Shell oficialaus atnaujinimo nėra. PHP projektas 7.4, 8.0 ir 8.1 versijoms teikia tik minimalius šaltinio kodo atgalinius perkėlimus (backports), o ne paruoštus leidimus. Kas eksploatuoja šias versijas, turi gauti patvirtintą teikėjo atgalinį perkėlimą arba taikyti pereinamąsias priemones ir dabar planuoti perėjimą prie palaikomos versijos.
Ar nuo PHP 8.1 saugumo spragos yra atnaujinimas?
Ne iš PHP projekto. 2026 m. spalio 21 d. oficialūs taisymai pasirodė tik palaikomoms šakoms: 8.5.12, 8.4.27, 8.3.36 ir 8.2.35. PHP 8.1 ir senesnės versijos oficialių atnaujinimų nebegauna.
Vis dėlto jos paveiktos. Pasak specializuotos spaudos, pažeidžiamos versijos beveik nepertraukiamai siekia PHP 5.4. Kas viešai pasiekiamai eksploatuoja vieną iš šių versijų, turi kritinę spragą pagal CVSS v4.0 9,2 be paruoštos pataisos.
Daugeliui įmonių tai staigmena, nes tokios sistemos dažnai metų metus veikia stabiliai ir nepastebimai. Kad versija atnaujinimų nebegauna, kasdienybėje nepastebima, kol neatsiranda tokia spraga kaip PHP2Shell. Šaltinio atgaliniai perkėlimai 7.4, 8.0 ir 8.1 versijoms yra išimtis, o ne įprastos priežiūros atnaujinimas.
Ką reiškia šaltinio atgaliniai perkėlimai
7.4, 8.0 ir 8.1 versijoms yra minimalūs šaltinio kodo atgaliniai perkėlimai. Tai šaltinio kodo taisymai, perkelti į šias senesnes šakas. Tai nėra oficialus leidimas su versijos numeriu, išbandytu paketu ir pakeitimų žurnalu (changelog).
Praktiškai tai reiškia: kas nors turi atgalinį perkėlimą perimti, iš jo iš naujo sukompiliuoti PHP, išbandyti ir išleisti. Tai gali vykti trimis keliais:
- Jūsų distribucija taisymą perima į savo paketus, pavyzdžiui, vykdydama ilgalaikę priežiūrą.
- Jūsų talpintojas kuria savus PHP paketus ir įdiegia atgalinį perkėlimą.
- Jūs patys ar paslaugų teikėjas kompiliuojate PHP iš šaltinių. Tai sudėtinga ir kartojama su kiekviena tolesne spraga.
Ar jūsų sistema gavo atgalinį perkėlimą, patikrinsite paketo pakeitimų žurnale:
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 šeima
Paketų pavadinimai skiriasi pagal distribuciją ir paketų šaltinį. Jei įrašo nėra, klauskite teikėjo. Kaip tiksliai veikia patikra, aprašyta puslapyje Kaip teisingai patikrinti PHP versiją ir pataisų būseną.
Seną serverį iki migracijos apsaugoti
Kol neveikia patvirtintas atgalinis perkėlimas, galioja php.net pereinamosios priemonės: neperrašomas memory_limit=-1 su atminties riba per cgroup, post_max_size 8M ar 32M su upload_max_filesize žemiau ir session.upload_progress.enabled=0 serverio konfigūracijoje, po to paleisti iš naujo visus darbinius procesus. Jos nėra visiška apsauga. Detalės pateiktos puslapyje Skubios priemonės, kai dar negalite pataisyti.
Papildomai taikomos priemonės, mažinančios pasiekiamumą: administravimo sritys tik per VPN ar patvirtintus IP adresus, nereikalingų svetainių išjungimas, serverio prieigų glaudus apribojimas. BSI rekomenduoja serverius be atnaujinimo laikinai atjungti nuo tinklo. Senai, sunkiai migruojamai programai izoliuotas sprendimas gali būti sąžiningesnis atsakymas nei veikimas atvirame internete.
Jei serveris su PHP 8.1 ar senesne versija nuo spalio 17 d. veikė neapsaugotas tinkle, tai vertinkite rimtai: BSI tikėjosi greito plataus išnaudojimo. Išsaugokite žurnalus nuo spalio 20 d. ir prieš migruodami patikrinkite serverį dėl pėdsakų.
Migracijos planavimas: į kurią versiją?
Tikslas yra versija, kurią PHP projektas palaiko ir kurią jūsų programa pakelia. PHP 8.2 nuo 8.2.35 spragą uždaro, bet 2026 m. gruodžio 31 d. pasiekia palaikymo pabaigą. Kas dabar migruoja, todėl, jei programa leidžia, turėtų rinktis 8.3 ar naujesnę. Dabartinę būklę php.net nurodo palaikomų versijų puslapyje.
Kurią PHP versiją palaiko jūsų CMS ar parduotuvė, tikrinkite pagal gamintojo sistemos reikalavimus, pavyzdžiui, wordpress.org, shopware.com ar typo3.org. Dažnai pirmiausia reikia atnaujinti pačią programą, kad būtų galima keisti PHP. Tipiškas atvejis yra senesnės parduotuvės, kurias aprašome puslapyje Shopware 5. Pasenusių versijų pasekmių pagrindus rasite puslapyje PHP gyvavimo pabaiga: pasenusių versijų rizikos.
| Žingsnis | Turinys |
|---|---|
| Esama būklė | PHP versija, programa, plėtiniai, nuosavi pritaikymai |
| Reikalavimai | palaikomos PHP versijos pagal gamintoją |
| Bandomoji aplinka | kopija su nauja PHP versija, klaidų žurnalo vertinimas |
| Perjungimas | suplanuotas priežiūros langas, paruoštas grįžimo kelias |
| Pokontrolė | pereinamųjų reikšmių patikra, stebėsenos įrengimas |
Kaip PHP SOS padeda konkrečiai?
Per PHP 8.1 ir senesnių migraciją vedame jus nuo senos versijos iki palaikomos:
- Nedelsiant apsaugoti: patikrinti atgalinio perkėlimo būklę, nustatyti pereinamąsias priemones, sumažinti pasiekiamumą.
- Patikrinti pėdsakus: išsaugoti žurnalus nuo spalio 20 d. ir įvertinti dėl neįprastumų.
- Paruošti migraciją: išsiaiškinti suderinamumą pagal gamintoją, įrengti bandomąją aplinką, šalinti klaidas.
- Perjungti ir įrodyti: įdiegti naują PHP versiją, paleisti iš naujo visus procesus, dokumentuoti būklę.
Dažni klausimai
Ar PHP 8.1 paveikta PHP2Shell?
Pasak specializuotos spaudos, paveiktos beveik visos versijos iki pat PHP 5.4, įskaitant PHP 8.1. PHP projektas 8.1 oficialių atnaujinimų neskelbia, tik minimalius šaltinio kodo atgalinius perkėlimus (backports).
Kas yra šaltinio atgalinis perkėlimas?
Šaltinio kodo taisymas, perkeltas į senesnę versijų šaką. Tai nėra paruoštas leidimas: kas nors turi jį perimti, perkompiliuoti PHP, išbandyti ir išleisti. Tai gali padaryti jūsų distribucijos teikėjas, talpintojas ar paslaugų teikėjas.
Ar pakanka pereiti prie PHP 8.2?
Trumpam PHP 8.2.35 spragą uždaro. Tačiau PHP 8.2 palaikymas baigiasi 2026 m. gruodžio 31 d. Kas vis tiek migruoja, turėtų patikrinti, ar programa pagal gamintoją palaiko ir 8.3 ar naujesnę.
Mano parduotuvė veikia tik su PHP 7.4. Ką dabar?
Tuomet lygiagrečiai reikia dviejų dalykų: serverį apsaugoti pereinamosiomis priemonėmis ir izoliacija bei programą perkelti į versiją, kuri palaiko palaikomą PHP versiją. Kuri tai versija, nurodyta gamintojo sistemos reikalavimuose.