PHP2Shell: ką svetainės savininkui padaryti šiandien
PHP2Shell pataisos jau išleistos. Kaip patikrinti svetainės PHP versiją, ką paklausti talpinimo teikėjo ir kodėl laikinos apsaugos nepakeičia atnaujinimo.
Šiame straipsnyje · 2 dalys
PHP kūrėjai išleido skubius atnaujinimus, užtaisančius dvi kritines PHP2Shell spragas, todėl svetainės savininkui šiandien svarbiausia patikrinti serverio PHP pataisų būklę. Spalio 21 dieną paskelbtos versijos 8.5.12, 8.4.27, 8.3.36 ir 8.2.35; vien turinio valdymo sistemos atnaujinimu pasikliauti negalima.
Apie tai, kaip spragas aptikti padėjo DI, jau rašėme ryto straipsnyje apie OpenAI ir Google tyrimus. Šis tekstas skirtas kitam klausimui: kaip nustatyti savo svetainės padėtį ir pasirūpinti, kad būtinos pataisos būtų įdiegtos.
PHP2Shell rizika ir pataisytos versijos
PHP pranešime įvardytos CVE-2026-109618 ir CVE-2026-109619 spragos įvertintos po 9,2 balo pagal CVSS v4.0 skalę. Jos kritinės ir leidžia nuotolinį kodo vykdymą be prisijungimo, todėl užpuolikui nebūtina turėti svetainės administratoriaus paskyros.
Pirmoji susijusi su atminties gedimu, kai PHP pritrūksta atminties apdorojant užklausą. Antroji leidžia vienos užklausos būsenai išlikti ir būti panaudotai kitoje užklausoje, kurią aptarnauja tas pats procesas.
Rizika apima interneto užklausas aptarnaujančias PHP instaliacijas: PHP-FPM, Apache mod_php, php-cgi, FrankenPHP ir LiteSpeed. Didžiausia rizika nurodoma Apache mod_php aplinkoje, tačiau tai nereiškia, kad kiti išvardyti veikimo būdai yra saugūs.
Wiz tyrėjai pademonstravo nuotolinį kodo vykdymą be prisijungimo prieš naujausius WordPress, Drupal ir Joomla konteinerius. Pažeidžiama gali būti net paprasta „Hello World“ PHP programa: vertinti reikia serverio PHP, ne vien svetainės funkcijų sudėtingumą.
Oficialiame php.net pranešime nurodytos keturios pataisytos stabilios versijos. Savo svetainės šakoje ieškokite atitinkamai PHP 8.5.12, 8.4.27, 8.3.36 arba 8.2.35; bendro įrašo „PHP 8“ patikrai nepakanka.
Pataisas taip pat turi PHP 8.6.0 RC4, tačiau šis leidimas pažymėtas kaip kandidatinė versija. Praktinis svetainės savininko tikslas šiandien yra gauti patvirtinimą apie įdiegtą pataisą, o ne vien pasirinkti didžiausią versijos numerį.
Pavyzdžiui, naudojant PHP 8.4 šaką aktualus pataisytas leidimas yra 8.4.27, o naudojant PHP 8.3 – 8.3.36. Tai du atskiri atnaujinimo keliai, todėl nebūtina painioti skubios saugumo pataisos su sprendimu pereiti į kitą šaką. Jei talpinimo skydelyje matomas tik šakos pavadinimas, paprašykite teikėjo nurodyti visą versiją ir patvirtinti pataisų būklę.
PHP 8.1, 8.0 ir 7.4 nebepalaikomos: naujų leidimų jos negavo, pateiktos tik šaltinio pataisos. Todėl senas numeris savaime neatsako, ar talpinimo teikėjas jas pritaikė; būtinas tiesioginis patvirtinimas. PHP 8.2 palaikymas baigiasi 2026 metų gruodžio 31 dieną, tad šios šakos pataisymas nepanaikina artėjančio perėjimo klausimo.
WordPress atnaujinimas nėra PHP atnaujinimo pakaitalas: spragos yra serverio vykdymo aplinkoje, o ne vien turinio valdymo sistemoje. Todėl net naujausią WordPress naudojančios svetainės savininkui reikia atskirai patikrinti, kokia PHP versija aptarnauja interneto užklausas.
PHP patikra, atnaujinimas ir laikina apsauga
Pirmasis žingsnis – nustatyti visą PHP versijos numerį: WordPress administravimo skydelyje jis pateikiamas skiltyje Įrankiai → Svetainės sveikata → Informacija → Serveris. Palyginimui reikalingas visas numeris, pavyzdžiui, 8.4.27, o ne vien bendras PHP 8 ar PHP 8.4 pavadinimas.
Antrasis žingsnis – gauti talpinimo paslaugos teikėjo patvirtinimą, jei svetainės savininkas negali pats atnaujinti serverio aplinkos. Užklausoje galima įvardyti abi spragas, CVE-2026-109618 ir CVE-2026-109619, ir paprašyti patvirtinti, ar jų pataisos jau įdiegtos konkrečią svetainę aptarnaujančioje PHP aplinkoje.
Trečiasis žingsnis – suderinti PHP atnaujinimą, nes tai vienintelis pilnas sprendimas, o laikinos apsaugos tik sumažina riziką. Prieš keičiant pagrindinę versiją būtina patikrinti WordPress įskiepių ir temos suderinamumą; šį darbą galima derinti su svetainės prižiūrėtoju.
Ketvirtasis žingsnis – patvirtinti rezultatą, dar kartą patikrinant rodomą PHP versiją arba gaunant aiškų teikėjo atsakymą apie pritaikytas pataisas. Senesnėse šakose vien numeris gali neparodyti šaltinio pataisos, todėl pažadas atnaujinti ir patvirtinimas, kad atnaujinta, nėra tas pats.
Wiz pateikta laiko juosta rodo, kad spragos rastos rugpjūčio 19 dieną, PHP komandai pranešta rugpjūčio 24 dieną, o viešai atskleistos kartu su pataisomis spalio 21 dieną. Dabar svetainės savininko užduotis yra ne laukti paskelbimo, o išsiaiškinti, ar parengtos pataisos jau pasiekė jo serverį.
PHP nurodo laikinas rizikos mažinimo priemones: memory_limit=-1, mažesnį post_max_size, session.upload_progress.enabled=0, o PHP 8.5 aplinkoje – fatal_error_backtraces=0. Tai nėra lygiaverčiai pataisos pakaitalai; dėl jų taikymo konkrečioje aplinkoje reikia tartis su serverio administratoriumi.
Wiz taip pat nurodo, kad Cloudflare, Fastly, Vercel ir kiti paslaugų teikėjai paskelbė laikinas apsaugas negalintiems atnaujinti iš karto. Tokia apsauga nepakeičia klausimo, ar pats svetainę aptarnaujantis PHP jau pataisytas. Su prižiūrėtoju verta aiškiai atskirti du darbus: kokia laikina priemonė taikoma dabar ir kada bus užbaigtas PHP atnaujinimas.
Žurnaluose Wiz siūlo ieškoti neįprastų multipart užklausų kartu su atminties ribos klaidomis, pasikartojančių HTTP 500 atsakymų, neįprastai didelių ar sugadintų PHPSESSID slapukų ir nepaaiškinamų PHP procesų persikrovimų. Tai požymiai, į kuriuos verta atkreipti administratoriaus dėmesį, o ne savarankiškas įsilaužimo patvirtinimas.
Cybersecuritynews praneša apie viešą koncepcijos įrodymą ir Cloudflare užfiksuotus pirmus išnaudojimo bandymus. Wordify savo ruožtu teigia nuo 08:44 UTC mačiusi atakas prieš savo talpinamas svetaines; tai pačios bendrovės pranešimas, ne visų svetainių užkrėtimo įrodymas.
Rašome apie dirbtinį intelektą lietuviškai. Kiekvienas straipsnis parengtas pagal nurodytą šaltinį, o nuorodą į originalą rasite kortelėje „Šaltinis“.
