PHP2Shell: kritinės PHP spragos nutekėjo – kaip pasiruošti pataisoms

Kas nutiko?

2026 m. spalio 20 d. internete pasirodė informacija apie dvi kritines PHP spragas anksčiau, nei buvo planuotas suderintas jų atskleidimas. Tyrėjai patvirtino, kad spragos tikros; viešame pranešime jos įvardijamos kaip CVE-2026-109618 ir CVE-2026-109619. PHP saugumo komanda paskelbė apie skubų saugumo leidimą spalio 21 d. 14:00 UTC (17:00 Lietuvos laiku), kuriame numatyta pateikti paveiktas ir pataisytas versijas. Oficialus PHP pranešimas ↗

„Huntress“ spragas apibūdina kaip galinčias leisti nuotoliniu būdu vykdyti kodą. Jos spalio 20 d. apžvalgoje pabrėžiama, kad tuo metu nebuvo paskelbta techninė priežastis ar tikslus atakos kelias, todėl negalima patikimai spręsti, kokios konkrečios konfigūracijos pažeidžiamos. Tame pačiame pranešime PHP komandai priskiriamas 9,2 balo CVSS 4.0 įvertinimas. „Huntress“ analizė ↗

Kodėl PHP spraga gali pasiekti daugiau nei vieną svetainę?

PHP naudojamas daugelyje turinio valdymo sistemų ir el. prekybos platformų, prieglobos valdymo skydeliuose bei kitų gamintojų programose. Kai kuriais atvejais organizacija gali nežinoti, kad įrenginyje ar programoje yra atskiras PHP vykdymo aplinkos egzempliorius. Todėl vien atnaujinti pagrindinę svetainę ar jos papildinius gali neužtekti – reikia patikrinti ir pačią PHP aplinką bei tiekėjo pateiktus komponentus.

Ką žinome, o kas dar nepatvirtinta?

• PHP komanda patvirtino, kad rengia du kritinius saugumo pataisymus; viešame išankstiniame pranešime detalių ar paveiktų versijų sąrašo dar nėra.
• Ankstyvuose pranešimuose minimos ir senesnės PHP šakos, tačiau tikslų paveiktų bei pataisytų versijų sąrašą reikia tikrinti oficialiame PHP leidime ir savo distribucijos ar prieglobos tiekėjo biuleteniuose.
• „Huntress“ spalio 20 d. rašė, kad jos partnerių aplinkose tuo metu šių konkrečių spragų išnaudojimo nepastebėjo. Tai nėra patvirtinimas, kad išnaudojimo nėra kitose sistemose.

CERT-EU taip pat ragina iš anksto nustatyti PHP naudojančias sistemas, kad pataisą būtų galima įdiegti iškart, kai tik ji bus prieinama. Jei internetinės sistemos negalima greitai atnaujinti, rekomenduojama svarstyti jos izoliavimą nuo viešo tinklo iki pataisymo. CERT-EU saugumo pranešimas ↗

Ką organizacija gali padaryti dabar?

1. Surašyti PHP aplinkas. Patikrinkite viešus serverius ir svetaines, TVS bei el. prekybos sistemas, prieglobos valdymo skydelius, taip pat tiekėjų programas ir įrenginius, kuriuose PHP gali būti įdiegtas kartu.
2. Pasiruošti pataisų diegimui. Stebėkite PHP pranešimus, operacinės sistemos platintojo, programinės įrangos tiekėjo ir prieglobos paslaugos teikėjo informaciją. Prieš keitimą turėkite atsarginę kopiją, suplanuokite diegimo langą ir patikrinkite, ar atnaujinta versija iš tikrųjų naudojama po paslaugų perkrovimo.
3. Įvertinti nebepalaikomas versijas. Senoms PHP šakoms pataisų gali nebūti. Tokias internetines sistemas reikėtų perkelti į palaikomą versiją arba, kol tai padaryta, apriboti viešą pasiekiamumą pagal veiklos poreikius.
4. Stebėti netikėtus PHP procesų paleidimus. Atkreipkite dėmesį, jei php-fpm, php-cgi, httpd ar apache2 paleidžia apvalkalus, pavyzdžiui, sh, bash, cmd.exe, powershell.exe, ar parsisiuntimo ir tinklo įrankius, tokius kaip curl, wget ar nc. Tai bendri įtartino elgesio požymiai, o ne vien šių CVE patvirtinimo indikatoriai.
5. Įtarus įsilaužimą, išsaugoti įrodymus. Apribokite serverio ryšį, išsaugokite žiniatinklio ir PHP žurnalus, patikrinkite naujus failus, suplanuotas užduotis, paskyras ir neįprastus išorinius ryšius. Prieš valydami sistemą nustatykite pažeidimo apimtį ir pakeiskite galimai atskleistus prisijungimo duomenis.

Atnaujinkite PHP, o ne vien svetainės papildinius

Šis atvejis primena, kad svetainės saugumą sudaro keli sluoksniai: pati programa, jos papildiniai, serverio operacinė sistema, PHP vykdymo aplinka ir tiekėjo priežiūra. Pataisykite PHP versiją pagal oficialų paveiktų bei pataisytų versijų sąrašą, o po diegimo patikrinkite visas svetaines ir programas, kurios tą aplinką naudoja.