PHP2Shell: kodėl viena PHP spraga kelia grėsmę beveik kiekvienai svetainei?

Spalio 21 d. PHP komanda išleido pataisas dviem kritinėms spragoms, kurias įsilaužėliai pradėjo išnaudoti dar prieš jų paskelbimą. Paaiškiname, kas yra PHP2Shell, kurias svetaines tai liečia ir ką verta padaryti jau šiandien.

9.2CVSS v4.0 balas, abi spragos

0prisijungimų reikia įsilaužėliui

5.4+seniausia paveikta PHP versija

1,3 mln.+potencialiai pažeidžiamų serverių

Dauguma svetainių saugumo naujienų liečia konkretų įskiepį ar platformą: atnaujinate vieną komponentą ir problema išspręsta. PHP2Shell kitokia. Spragos yra pačiame PHP – programavimo kalboje, kuria veikia WordPress, Joomla, Drupal, Magento, PrestaShop, Laravel ir dauguma kitų svetainių sistemų. W3Techs duomenimis, PHP naudoja beveik 70 proc. svetainių, kurių serverio kalba žinoma.

Todėl šįkart klausimas ne „ar naudoju pažeidžiamą įskiepį?“, o „kokia PHP versija aptarnauja mano svetainę ir ar ji jau pataisyta?“

Kas yra PHP2Shell?

PHP2Shell – tai pavadinimas, kurį tyrėjai davė dviejų spragų grandinei: CVE-2026-109618 ir CVE-2026-109619. PHP saugumo komanda abi įvertino 9.2 balo pagal CVSS v4.0 skalę. Iš pradžių internete sklandęs 10.0 balas buvo neteisingas, tačiau ir 9.2 reiškia kritinę spragą.

Pavadinimas apibūdina pasekmę. Per PHP įsilaužėlis gauna „shell“ – galimybę vykdyti komandas jūsų serveryje. Tam jam nereikia nei slaptažodžio, nei paskyros svetainėje: užtenka vienos specialiai paruoštos HTTP užklausos.

Tyrėjai patvirtino veikiančias atakas prieš WordPress, Drupal, Joomla ir Magento svetaines. Pažeidžiami visi būdai, kuriais PHP aptarnauja interneto užklausas:

PHP-FPM – dažniausias šiuolaikiniuose serveriuose;
Apache mod_php – čia PHP komanda riziką vertina kaip didžiausią;
php-cgi, LiteSpeed ir FrankenPHP.

Kodėl saugumo įskiepis jūsų neapsaugos

Svarbiausia PHP2Shell savybė – momentas, kada įvyksta ataka. PHP apdoroja užklausos duomenis dar prieš paleisdamas jūsų svetainės kodą. Todėl visos apsaugos, veikiančios svetainės viduje, apie ataką net nesužino.

Užklausos kelias iki jūsų svetainės

Paspauskite mygtuką ir pažiūrėkite, kur sustoja ataka. Paspaudę ant sluoksnio, pamatysite, ką jis gali padaryti.

Specialiai paruošta HTTP POST užklausa. Iš pažiūros tai eilinis srautas, kurio nereikia nei prisijungti, nei turėti paskyros.
Gali blokuoti žinomus atakų šablonus, bet tik per jį einančiam srautui. Nauji variantai gali praslysti, o jei serveris pasiekiamas tiesiogiai per IP adresą, WAF apeinamas visai.
Perduoda užklausą PHP. Užklausų dydžio ribojimas šiame lygyje sumažina vieno žinomo atakos būdo riziką, bet spragos nepašalina.
Čia ir slypi spraga. PHP skaito ir apdoroja užklausos duomenis dar prieš paleisdamas jūsų svetainės kodą, todėl įsilaužėlio kodas pasileidžia būtent šiame žingsnyje.
Svetainės sistema nespėja net pasileisti. Nesvarbu, ar ji atnaujinta, ar ne.
Neturi ką stabdyti: ataka įvyko anksčiau, nei šios apsaugos įsijungė.

Išvada paprasta: vienintelis visiškas sprendimas – atnaujinti patį PHP. Visa kita – laikinos priemonės, kurios padeda laimėti laiko.

Dvi spragos, viena grandinė

Abi spragos susijusios su tuo, kaip PHP tvarko atmintį apdorodamas užklausas. Techninių detalių svetainės savininkui žinoti nebūtina, bet verta suprasti, kuo jos skiriasi, nes laikinos apsaugos priemonės kiekvienai kitokios.

Atminties trūkumo klaida · CVSS 9.2

Kai PHP pritrūksta atminties vos pradėjęs skaityti POST užklausą, dalis jo vidinių duomenų lieka iki galo nesukurti. Užklausos pabaigoje PHP juos tvarko taip, lyg jie būtų tvarkingi, nors jų turinį valdo įsilaužėlis. Tai atveria kelią savo kodui paleisti.

Paprastai tariant: įsilaužėlis sąmoningai „perkrauna“ PHP ir pasinaudoja netvarka, kuri lieka po to.

Laikina priemonė: memory_limit=-1 serverio lygiu ir užklausų dydžio riba interneto serveryje.

Atlaisvintos atminties naudojimas · CVSS 9.2

Po vienos užklausos PHP procese gali likti nuoroda į jau atlaisvintą atmintį. Kita užklausa, kurią aptarnauja tas pats procesas, šią atmintį panaudoja. Taip galima nutekinti atminties turinį ir paleisti kodą. Spraga pasiekiama per sesijų įkėlimo eigos funkciją, kuri įjungta pagal nutylėjimą.

Paprastai tariant: viena užklausa palieka „šiukšlių“, o kita jomis pasinaudoja.

Laikina priemonė: session.upload_progress.enabled=0, o PHP 8.5 – ir fatal_error_backtraces=0.

Kaip viskas vyko

2024 m.
Per pirmąjį per kelerius metus išorinį PHP saugumo auditą komanda pastebi pirmuosius atminties problemos ženklus – tos, kuri vėliau tapo CVE-2026-109618. Veikiančio atakos būdo tada nerasta, viešai apie tai neskelbta, o taisymas užstringa. PHP Foundation vėliau pripažino, kad toks delsimas buvo klaida.
2026 m. rugpjūčio 11 d.
Tyrėjai iš Calif ir OpenAI, nepriklausomai vienas nuo kito, praneša PHP komandai, kad per tą pačią problemą galima paleisti kodą serveryje. Taisymas tampa prioritetu.
Spalio 17 d.
Amazon grėsmių žvalgyba savo spąstų tinkle užfiksuoja pirmąjį išnaudojimo bandymą – keturias dienas iki viešo paskelbimo.
Spalio 20 d.
CVE numeriai nuteka į viešumą. PHP komanda paskelbia išankstinį pranešimą apie kritinį saugumo atnaujinimą.
Spalio 21 d.
Dėl nutekėjimo diena anksčiau nei planuota išleidžiamos pataisytos versijos 8.5.12, 8.4.27, 8.3.36 ir 8.2.35. Cloudflare praneša apie pirmąsias atakas ir įdiegia laikinas WAF taisykles.
Dabar
Atakų daugėja, jas vykdo keli skirtingi veikėjai. Amazon rekomenduoja įsilaužimo požymių ieškoti nuo spalio 17 d., o ne nuo paskelbimo dienos.

Ką tai reiškia jums: net jei PHP atnaujinote vakar, svetainė galėjo būti pažeista anksčiau. Pataisa uždaro duris, bet neišmeta to, kas jau spėjo įeiti.

Ar jūsų svetainė pažeidžiama?

Pažeidžiama bet kuri svetainė, kurią aptarnauja nepataisyta PHP versija. Štai kurios versijos jau turi pataisą:

PHP šaka	Saugi versija
PHP 8.5	8.5.12 ar naujesnė
PHP 8.4	8.4.27 ar naujesnė
PHP 8.3	8.3.36 ar naujesnė
PHP 8.2	8.2.35 ar naujesnė
PHP 7.4–8.1	Oficialios pataisytos versijos nėra. Reikia atnaujinti į 8.2+ arba naudoti tiekėjo pataisytą paketą.
PHP 5.4–7.3	Nebepalaikoma, pataisos nebus. Būtina atnaujinti.

Patikrinkite savo PHP versiją

Įrašykite PHP versiją

Pavyzdžiai:

Kur rasti PHP versiją?

Hostingo valdymo panelėje (cPanel, DirectAdmin, Plesk) – skiltyje „PHP versija“ arba „Select PHP Version“.
WordPress: Įrankiai → Svetainės sveikata → Informacija → Serveris.
Paklauskite hostingo tiekėjo – ir kartu paklauskite, ar į jūsų PHP paketą jau įdiegta pataisa.

Jei versijai pažiūrėti kuriate phpinfo() failą, iškart po to jį ištrinkite – jis atskleidžia daug informacijos apie serverį.

Kodėl versijos numeris gali klaidinti

Linux distribucijos dažnai įdiegia pataisą nepakeisdamos versijos numerio. Tad „senas“ numeris dar nereiškia, kad PHP pažeidžiamas.
Komandinėje eilutėje matomas PHP gali skirtis nuo to, kuris iš tikrųjų aptarnauja svetainę.
Bendrame hostinge vienu metu gali veikti kelios PHP versijos, o skirtingi domenai gali naudoti skirtingas.

Rizikos savitikra per 30 sekundžių

Atsakykite į penkis klausimus. Jei atsakymo nežinote, rinkitės „Nežinau“ – tai irgi svarbus atsakymas.

Ar žinote, kokia tiksli PHP versija aptarnauja jūsų svetainę?
Ar PHP atnaujintas po spalio 21 d., arba tiekėjas patvirtino, kad pataisa įdiegta?
Ar svetainė veikia su PHP 8.1 ar senesne versija?
Ar kas nors jau peržiūrėjo serverio žurnalus ir failus nuo spalio 17 d.?
Ar svetainėje yra el. parduotuvė, klientų paskyros ar asmens duomenys?

Atsakyta 0 iš 5

Užsakyti PHP2Shell auditą

Ką galite padaryti šiandien

Sužinokite tikslią PHP versiją, kuri aptarnauja jūsų svetainę, ir palyginkite ją su lentele aukščiau.
Atnaujinkite PHP į pataisytą versiją arba paprašykite, kad tai padarytų hostingo tiekėjas. Prieš atnaujindami į naują šaką, pasidarykite atsarginę kopiją ir patikrinkite, ar svetainė, tema ir įskiepiai su ja veikia.
Jei atnaujinti iškart negalite, įjunkite laikinas priemones, kurias rekomenduoja PHP komanda (žr. žemiau), ir perkraukite visus PHP procesus.
Patikrinkite, ar jau neįsilaužta: nežinomi PHP failai, nauji administratoriai, svetainės procesų paleisti shell'ai, klaidos apie atminties išsekimą „on line 0“ žurnaluose – nuo spalio 17 d.
WAF naudokite kaip papildomą sluoksnį, o ne kaip pataisą. Jis saugo tik per jį einantį srautą.

Laikinos priemonės PHP konfigūracijoje:

memory_limit = -1                  ; CVE-2026-109618
session.upload_progress.enabled = 0  ; CVE-2026-109619
fatal_error_backtraces = 0         ; tik PHP 8.5

memory_limit turi būti nustatytas taip, kad programos negalėtų jo pakeisti (pvz., per php_admin_value PHP-FPM nustatymuose). Kadangi tai panaikina PHP atminties ribą, PHP komanda pataria ją užtikrinti konteinerio ar cgroup lygiu ir apriboti užklausų dydį interneto serveryje. Šios priemonės sumažina riziką, bet nepadaro PHP saugaus.

Kada verta kreiptis į specialistą

Atnaujinti PHP dažnai užtrunka vos kelias minutes. Sudėtingiau atsakyti į tris klausimus: ar pataisa tikrai veikia būtent jūsų svetainę aptarnaujančiame PHP, ar svetainė veiks su nauja versija ir ar kas nors nepasinaudojo spraga anksčiau.

Būtent tai patikrina Redfox Cloud PHP2Shell auditas. Jūsų svetainę rankiniu būdu tikrina serverių inžinierius, o ne automatinis skeneris, o rezultatus gaunate raštu, suprantama kalba. Nebūtina būti mūsų hostingo klientu.

PHP2Shell auditas

29 € + PVM

Tiksli PHP versija ir SAPI, aptarnaujanti jūsų domeną
Ar tiekėjas įdiegė pataisą į jūsų PHP paketą
Klaidų žurnalai ir įsilaužimo požymiai nuo spalio 17 d.
Jūsų TVS ir įskiepių rizika
Rašytinė ataskaita ir taisymo kaina

Užsakyti už 29 €

Pilnas saugumo auditas

199 € + PVM

Viskas, kas įeina į PHP2Shell auditą
Sistemos paketai, branduolys ir žinomi CVE
Serverio, ugniasienės, SSH, TLS ir PHP konfigūracija
TVS, įskiepių, temų ir individualaus kodo saugumo klaidos
Kenkėjiškas kodas, užpakalinės durys, nežinomos cron užduotys

Užsakyti už 199 €

Susisiekiame per 2 darbo valandas nuo apmokėjimo (I–V 9:00–18:00). Mokėjimas vienkartinis. Taisymo kainą pateikiame po audito, o ar darbus atliksime mes, sprendžiate jūs.

Dažni klausimai

Ar užtenka, kad hostingo tiekėjas atnaujino PHP?

Jei tiekėjas patvirtina, kad pataisa įdiegta būtent jūsų svetainę aptarnaujančiai PHP versijai, svarbiausias žingsnis atliktas. Tačiau bendrame hostinge dažnai veikia kelios PHP versijos, o pataisa neištrina įsilaužimo pėdsakų, jei ataka įvyko anksčiau. Todėl verta patikrinti ir žurnalus nuo spalio 17 d.

Ar Cloudflare ar kitas WAF mane apsaugo?

Tik laikinai ir tik iš dalies. WAF blokuoja žinomus atakų šablonus tam srautui, kuris per jį eina. Jei serveris pasiekiamas tiesiogiai per IP adresą arba pasirodo naujas atakos variantas, WAF nepadės. Problemą išsprendžia tik PHP atnaujinimas.

Mano svetainė veikia su PHP 7.4, 8.0 ar 8.1. Ką daryti?

Šioms versijoms oficialių pataisytų leidimų nėra – PHP komanda paskelbė tik pataisas išeities kodui, skirtas tiems, kas PHP kompiliuoja patys. Saugiausias kelias – atnaujinti į PHP 8.2 ar naujesnę. Prieš tai verta patikrinti, ar svetainė ir įskiepiai su nauja versija veiks.

Kaip suprasti, ar svetainė jau nulaužta?

Dažniausi požymiai – nežinomi PHP failai, nauji administratoriai, keisti peradresavimai, svetainės procesų paleistos komandos ir pasikartojančios atminties išsekimo klaidos „on line 0“ klaidų žurnaluose. Kai kurie požymiai matomi tik serverio lygiu, todėl vien pažiūrėjus į svetainę jų galima nepastebėti.

Ar galiu savo svetainę patikrinti internete paskelbtu atakos kodu?

Nerekomenduojame. Viešai platinamo kodo veikimas nepatvirtintas, o toks kodas kartais pats būna užkrėstas kenkėjiška programa. Saugiau patikrinti PHP versiją, pataisos būklę ir žurnalus.

Ar žinote, kuri PHP versija šią akimirką aptarnauja jūsų svetainę – ir ar niekas ja nepasinaudojo anksčiau už jus?