PHP2Shell – paprastai ir aiškiai.

Trumpai

• Pažeidžiamumai: CVE-2026-109618 ir CVE-2026-109619, viešai žinomi kaip PHP2Shell, kuriuos 2026 m. spalio 21 d. paskelbė PHP saugumo komanda.
• Pavojingumas: kritinis, kiekvienas įvertintas 9.2 (CVSS v4.0). Abu gali leisti nuotoliniu būdu vykdyti kodą be autentifikacijos.
• Pažeidžiamos sistemos: žiniatinklio užklausas apdorojantys PHP diegimai. Tyrėjai rado pažeidžiamų versijų net nuo PHP 5.4.
• Sprendimas: atnaujinkite PHP. PHP projektas nurodo, kad visiškai apsaugančių priemonių nėra, o atnaujinimas – vienintelis saugus pasirinkimas.

Kokie tai pažeidžiamumai

Abi spragos yra atminties saugumo klaidos PHP vykdymo aplinkoje, o ne WordPress, Drupal, Laravel ar kitose joje veikiančiose programose. Svetainė gali būti pažeidžiama net tada, kai jos kodas ir įskiepiai visiškai atnaujinti.

• Duomenų sugadinimas pritrūkus atminties, CVE-2026-109618: pritrūkus atminties, PHP darbas gali būti nutrauktas, kol vidiniai užklausos duomenys inicializuoti tik iš dalies. Tada užklausos išvalymo metu šie netinkami duomenys gali būti laikomi tinkamais.
• Pasenusi užklausos būsena, CVE-2026-109619: vienai užklausai priklausanti vidinė būsena gali išlikti ilgiau nei jai skirta atmintis. Vėlesnė to paties PHP proceso apdorojama užklausa gali panaudoti šią pasenusią būseną, todėl gali būti atskleista proceso atmintis arba įvykdytas kodas.

Tyrėjai pademonstravo nuotolinį kodo vykdymą be autentifikacijos WordPress ir Drupal sistemose, o pirmosios spragos atveju – ir Joomla. Pažeidžiama gali būti net minimali „Hello World“ programa, veikianti pažeidžiamoje vykdymo aplinkoje.

Kam kyla grėsmė

Remiantis PHP saugumo pranešimu, spragos paveikia visus žiniatinklio užklausas apdorojančius PHP diegimus, įskaitant PHP-FPM, Apache su mod_php, php-cgi, FrankenPHP ir LiteSpeed. Didžiausia rizika kyla Apache su mod_php: pademonstruotas išnaudojimo būdas ataką sukelia neautentifikuota užklausa dar prieš pradedant vykdyti bet kokį programos kodą.

PHP 8.1 ir senesnės versijos nebegauna PHP projekto atnaujinimų. Saugumo pranešime pateiktos nuorodos į minimalias išeitinio kodo pataisas, perkeltas į PHP 7.4, 8.0 ir 8.1, tačiau senesnes vykdymo aplinkas geriausia perkelti į palaikomą versiją.

Pataisytos versijos

Ankstesnės kiekvienos palaikomos šakos versijos laikytinos pažeidžiamomis.

PHP 8.2 palaikymas baigiasi 2026 m. gruodžio 31 d.

Distribucijų paketai

Linux distribucijos pataisas gavo iš anksto ir pataisytus paketus skelbia su savais versijų numeriais. Distribucijos paketas gali būti pataisytas, net jei jo versija atrodo senesnė nei PHP projekto išleista versija. Pavyzdžiui, Ubuntu 24.04 LTS pataisytas paketas yra 8.3.6-0ubuntu0.24.04.13, o ne 8.3.36.

Tikslias paketų versijas rasite savo distribucijos saugumo pranešime. PHP saugumo pranešime taip pat prašoma remirepo saugyklos naudotojų pereiti prie distribucijos paketų arba sukompiliuoti PHP iš išeitinio kodo, nes išleidimo dieną šioje saugykloje atnaujinimų nebuvo.

Laikinos apsaugos priemonės

Jei negalite atnaujinti nedelsiant, PHP saugumo pranešime nurodyti nustatymai, mažinantys tam tikrų atakos būdų riziką. Jie nepadaro diegimo saugaus, ir juos reikia nustatyti faile php.ini, PHP-FPM procesų grupėje arba serverio konfigūracijoje, o po to iš naujo paleisti visus PHP procesus.

• Išjunkite sesijos įkėlimo eigos sekimą: session.upload_progress.enabled = 0. Nepasikliaukite ini_set() arba .user.ini failais.
• Panaikinkite PHP atminties ribą parametru memory_limit = -1, įrašytu taip, kad programos negalėtų jo pakeisti, ir vietoj jos naudokite konteinerio arba cgroup atminties ribą. Nenaudokite RLIMIT_AS arba RLIMIT_DATA; jie gali aktyvuoti pažeidžiamą kodo kelią.
• Apribokite užklausų dydį, pavyzdžiui, post_max_size = 8M, arba 32M prireikus įkelti failus, ir užklausų ribas taikykite žiniatinklio serveryje arba tarpiniame serveryje.
• Naudodami PHP 8.5, nustatykite fatal_error_backtraces = 0.

Klaidų slėpimas nepadeda. Šiuos nustatymus laikykite trumpalaike priemone iki atnaujinimo, o ne sprendimu.

Žiniatinklio programų užkardos

Cloudflare dar prieš viešą paskelbimą įdiegė valdomas WAF taisykles nuo PHP2Shell, taip pat ir nemokamame plane. WAF – naudingas papildomas apsaugos sluoksnis, kol atnaujinate, tačiau pastebėta, kad užpuolikai keičia atakų turinį, kad išvengtų aptikimo, o vien svetainės kodo ar įskiepių atnaujinimas vykdymo aplinkos spragos nepašalina. Atnaujinkite PHP net ir naudodami WAF.

Atnaujinus

• Paleiskite PHP iš naujo: iš naujo paleiskite PHP-FPM, Apache arba PHP programų serverį, kad visi procesai įkeltų pataisytą kodą.
• Patikrinkite svetainę aptarnaujančią vykdymo aplinką: komandinės eilutės PHP versija gali skirtis nuo versijos, apdorojančios žiniatinklio užklausas, o serveriuose dažnai vienu metu veikia kelios PHP versijos.
• Patikrinkite visus serverius ir prieglobos paskyras: testavimo svetaines, senus diegimus ir antrinius serverius lengva praleisti.
• Peržiūrėkite ribas: pataisa prideda griežtą atminties ribą, kurią pasiekus procesas nutraukiamas, todėl peržiūrėkite atminties ir užklausų dydžio nustatymus teisėtoms didelėms užklausoms.

Jei naudojate valdomą prieglobą, paprašykite tiekėjo patvirtinti, kad įdiegta pataisyta vykdymo aplinka.

Požymiai, kuriuos verta ištirti

Tyrėjai nurodo požymius, į kuriuos verta atidžiau pažiūrėti. Patys savaime jie neįrodo, kad serveris buvo atakuotas.

• Neįprastai dideli arba netinkamo formato PHPSESSID slapukai.
• Multipart užklausos, po kurių seka atminties ribos klaidos arba pasikartojantys HTTP 500 atsakymai.
• Nepaaiškinami PHP procesų avariniai sustojimai.

Jei įtariate įsilaužimą, PHP atnaujinimas nepašalina to, ką užpuolikas galėjo palikti. Tam reikia atskiro tyrimo.

Kaip galime padėti

Mūsų patikra nustato PHP vykdymo aplinką, kuri iš tikrųjų aptarnauja jūsų svetainę, patikrina tiekėjo pataisų būseną ir pateikia rašytines išvadas su aiškiu tolesniu žingsniu. Jūsų serveryje niekas nekeičiama, kol su jumis nesuderiname darbų apimties.

Šaltiniai

• PHP saugumo pranešimas, 2026 m. spalio 21 d.
• PHP2Shell tyrimo santrauka
• Ubuntu saugumo pranešimas USN-8948-1
• Cloudflare: WAF apsauga nuo PHP pažeidžiamumų

Peržiūrėta 2026 m. spalio 22 d. Ši santrauka yra bendro pobūdžio informacija, o ne patarimas dėl jūsų sistemų. Naujausios informacijos ieškokite PHP saugumo pranešime.