PHP2Shell: kāpēc viena PHP ievainojamība apdraud gandrīz katru vietni?

21. oktobrī PHP komanda izlaida labojumus divām kritiskām ievainojamībām, kuras uzbrucēji sāka izmantot vēl pirms to publiskošanas. Skaidrojam, kas ir PHP2Shell, kuras vietnes tas skar un ko vērts izdarīt jau šodien.

9.2CVSS v4.0 vērtējums abām ievainojamībām

0pieteikšanos vajag uzbrucējam

5.4+vecākā skartā PHP versija

1,3 milj.+potenciāli ievainojamu serveru

Lielākā daļa vietņu drošības jaunumu attiecas uz konkrētu spraudni vai platformu: atjaunināt vienu komponentu, un problēma ir atrisināta. PHP2Shell ir citāda. Ievainojamības ir pašā PHP – programmēšanas valodā, uz kuras darbojas WordPress, Joomla, Drupal, Magento, PrestaShop, Laravel un vairums citu vietņu sistēmu. Saskaņā ar W3Techs datiem PHP izmanto gandrīz 70 % vietņu, kuru servera valoda ir zināma.

Tāpēc šoreiz jautājums nav „vai izmantoju ievainojamu spraudni?”, bet „kura PHP versija apkalpo manu vietni un vai tā jau ir labota?”

Kas ir PHP2Shell?

PHP2Shell ir nosaukums, ko pētnieki deva divu ievainojamību ķēdei: CVE-2026-109618 un CVE-2026-109619. PHP drošības komanda abas novērtēja ar 9.2 punktiem pēc CVSS v4.0 skalas. Sākumā internetā izplatītais vērtējums 10.0 bija kļūdains, taču arī 9.2 nozīmē kritisku ievainojamību.

Nosaukums apraksta sekas. Caur PHP uzbrucējs iegūst „shell” – iespēju izpildīt komandas Jūsu serverī. Tam nav vajadzīga ne parole, ne konts vietnē: pietiek ar vienu īpaši sagatavotu HTTP pieprasījumu.

Pētnieki ir apstiprinājuši strādājošus uzbrukumus WordPress, Drupal, Joomla un Magento vietnēm. Skarti visi veidi, kā PHP apkalpo interneta pieprasījumus:

PHP-FPM – visizplatītākais mūsdienu serveros;
Apache mod_php – šeit PHP komanda risku vērtē kā vislielāko;
php-cgi, LiteSpeed un FrankenPHP.

Kāpēc drošības spraudnis Jūs neaizsargās

Svarīgākā PHP2Shell īpašība ir brīdis, kad notiek uzbrukums. PHP apstrādā pieprasījuma datus vēl pirms Jūsu vietnes koda palaišanas. Tāpēc visas aizsardzības, kas darbojas vietnes iekšienē, par uzbrukumu pat neuzzina.

Pieprasījuma ceļš līdz Jūsu vietnei

Nospiediet pogu un apskatiet, kur apstājas uzbrukums. Uzklikšķinot uz slāņa, redzēsiet, ko tas spēj izdarīt.

Īpaši sagatavots HTTP POST pieprasījums. No malas tā ir parasta datplūsma, kurai nav vajadzīga ne pieteikšanās, ne konts.
Var bloķēt zināmus uzbrukumu šablonus, taču tikai tai datplūsmai, kas iet caur to. Jauni varianti var paslīdēt garām, un, ja serveris ir sasniedzams tieši pēc IP adreses, WAF tiek apiets pavisam.
Nodod pieprasījumu PHP. Pieprasījumu izmēra ierobežošana šajā līmenī samazina viena zināma uzbrukuma veida risku, bet ievainojamību nenovērš.
Tieši šeit slēpjas ievainojamība. PHP nolasa un apstrādā pieprasījuma datus vēl pirms Jūsu vietnes koda palaišanas, tāpēc uzbrucēja kods tiek palaists tieši šajā solī.
Vietnes sistēma pat nepaspēj startēt. Nav svarīgi, vai tā ir atjaunināta.
Nav ko apturēt: uzbrukums notika, pirms šīs aizsardzības ieslēdzās.

Secinājums ir vienkāršs: vienīgais pilnīgais risinājums ir atjaunināt pašu PHP. Viss pārējais ir pagaidu pasākumi, kas palīdz iegūt laiku.

Divas ievainojamības, viena ķēde

Abas ievainojamības ir saistītas ar to, kā PHP pārvalda atmiņu, apstrādājot pieprasījumus. Vietnes īpašniekam tehniskās detaļas nav jāzina, taču vērts saprast, ar ko tās atšķiras, jo pagaidu aizsardzības pasākumi katrai ir citi.

Atmiņas trūkuma kļūda · CVSS 9.2

Kad PHP pietrūkst atmiņas tieši brīdī, kad tas sāk lasīt POST pieprasījumu, daļa iekšējo datu paliek līdz galam neizveidoti. Pieprasījuma beigās PHP tos apstrādā tā, it kā tie būtu kārtībā, lai gan to saturu kontrolē uzbrucējs. Tas paver ceļu sava koda palaišanai.

Vienkāršiem vārdiem: uzbrucējs apzināti „pārslogo” PHP un izmanto pēc tam palikušo nekārtību.

Pagaidu pasākums: memory_limit=-1 servera līmenī un pieprasījumu izmēra ierobežojums tīmekļa serverī.

Atbrīvotas atmiņas izmantošana · CVSS 9.2

Pēc viena pieprasījuma PHP procesā var palikt atsauce uz jau atbrīvotu atmiņu. Nākamais pieprasījums, ko apkalpo tas pats process, šo atmiņu izmanto. Tādējādi var nopludināt atmiņas saturu un palaist kodu. Ievainojamība ir sasniedzama caur sesiju augšupielādes progresa funkciju, kas pēc noklusējuma ir ieslēgta.

Vienkāršiem vārdiem: viens pieprasījums atstāj „atkritumus”, bet nākamais tos izmanto.

Pagaidu pasākums: session.upload_progress.enabled=0, bet PHP 8.5 – arī fatal_error_backtraces=0.

Kā viss notika

2024. gadā
Pirmajā pēdējo gadu ārējā PHP drošības auditā komanda pamana pirmās atmiņas problēmas pazīmes – tās, kas vēlāk kļuva par CVE-2026-109618. Strādājošs uzbrukuma veids toreiz netiek atrasts, publiski par to netiek ziņots, un labojums iestrēgst. PHP Foundation vēlāk atzina, ka šāda kavēšanās bija kļūda.
2026. gada 11. augustā
Pētnieki no Calif un OpenAI neatkarīgi viens no otra ziņo PHP komandai, ka caur šo pašu problēmu serverī var palaist kodu. Labojums kļūst par prioritāti.
17. oktobrī
Amazon draudu izlūkošana savā slazdu tīklā fiksē pirmo izmantošanas mēģinājumu – četras dienas pirms publiskošanas.
20. oktobrī
CVE numuri nonāk atklātībā. PHP komanda publicē iepriekšēju paziņojumu par kritisku drošības atjauninājumu.
21. oktobrī
Noplūdes dēļ dienu agrāk nekā plānots tiek izlaistas labotās versijas 8.5.12, 8.4.27, 8.3.36 un 8.2.35. Cloudflare ziņo par pirmajiem uzbrukumiem un ievieš pagaidu WAF noteikumus.
Tagad
Uzbrukumu kļūst arvien vairāk, un tos veic vairāki dažādi dalībnieki. Amazon iesaka uzlaušanas pazīmes meklēt kopš 17. oktobra, nevis kopš publiskošanas dienas.

Ko tas nozīmē Jums: pat ja PHP atjauninājāt vakar, vietne varēja tikt uzlauzta agrāk. Labojums aizver durvis, bet neizmet ārā to, kurš jau paspējis ienākt.

Vai Jūsu vietne ir ievainojama?

Ievainojama ir jebkura vietne, ko apkalpo nelabota PHP versija. Lūk, kurām versijām labojums jau ir:

PHP atzars	Droša versija
PHP 8.5	8.5.12 vai jaunāka
PHP 8.4	8.4.27 vai jaunāka
PHP 8.3	8.3.36 vai jaunāka
PHP 8.2	8.2.35 vai jaunāka
PHP 7.4–8.1	Oficiālas labotas versijas nav. Jāatjaunina uz 8.2+ vai jāizmanto piegādātāja labota pakotne.
PHP 5.4–7.3	Vairs netiek atbalstīta, labojuma nebūs. Atjaunināšana ir obligāta.

Pārbaudiet savu PHP versiju

Ierakstiet PHP versiju

Piemēri:

Kur atrast PHP versiju?

Hostinga vadības panelī (cPanel, DirectAdmin, Plesk) – sadaļā „PHP versija” vai „Select PHP Version”.
WordPress: Rīki → Vietnes veselība → Informācija → Serveris.
Jautājiet hostinga pakalpojumu sniedzējam – un vienlaikus pajautājiet, vai Jūsu PHP pakotnē jau ir uzstādīts labojums.

Ja versijas apskatei izveidojat phpinfo() failu, uzreiz pēc tam to izdzēsiet – tas atklāj daudz informācijas par serveri.

Kāpēc versijas numurs var maldināt

Linux distribūcijas bieži uzstāda labojumu, nemainot versijas numuru. Tāpēc „vecs” numurs vēl nenozīmē, ka PHP ir ievainojams.
Komandrindā redzamais PHP var atšķirties no tā, kas patiesībā apkalpo vietni.
Koplietošanas hostingā vienlaikus var darboties vairākas PHP versijas, un dažādi domēni var izmantot dažādas.

Riska pašpārbaude 30 sekundēs

Atbildiet uz pieciem jautājumiem. Ja atbildi nezināt, izvēlieties „Nezinu” – arī tā ir svarīga atbilde.

Vai zināt, kura tieši PHP versija apkalpo Jūsu vietni?
Vai PHP ir atjaunināts pēc 21. oktobra vai piegādātājs ir apstiprinājis, ka labojums ir uzstādīts?
Vai vietne darbojas ar PHP 8.1 vai vecāku versiju?
Vai kāds jau ir pārskatījis servera žurnālus un failus kopš 17. oktobra?
Vai vietnē ir interneta veikals, klientu konti vai personas dati?

Atbildēti 0 no 5

Pasūtīt PHP2Shell auditu

Ko varat izdarīt jau šodien

Noskaidrojiet precīzu PHP versiju, kas apkalpo Jūsu vietni, un salīdziniet to ar tabulu augstāk.
Atjauniniet PHP uz labotu versiju vai palūdziet, lai to izdara hostinga pakalpojumu sniedzējs. Pirms pārejas uz jaunu atzaru izveidojiet rezerves kopiju un pārbaudiet, vai vietne, tēma un spraudņi ar to darbojas.
Ja nevarat atjaunināt uzreiz, ieslēdziet PHP komandas ieteiktos pagaidu pasākumus (skatīt zemāk) un restartējiet visus PHP procesus.
Pārbaudiet, vai vietne jau nav uzlauzta: nezināmi PHP faili, jauni administratori, vietnes procesu palaisti shell, kļūdas par atmiņas izsīkumu „on line 0” žurnālos – kopš 17. oktobra.
WAF izmantojiet kā papildu slāni, nevis kā labojumu. Tas aizsargā tikai to datplūsmu, kas iet caur to.

Pagaidu pasākumi PHP konfigurācijā:

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

memory_limit jāiestata tā, lai lietotnes to nevarētu mainīt (piem., ar php_admin_value PHP-FPM iestatījumos). Tā kā tas noņem PHP atmiņas ierobežojumu, PHP komanda iesaka to nodrošināt konteinera vai cgroup līmenī un ierobežot pieprasījumu izmēru tīmekļa serverī. Šie pasākumi samazina risku, bet nepadara PHP drošu.

Kad vērts vērsties pie speciālista

PHP atjaunināšana bieži aizņem tikai dažas minūtes. Grūtāk ir atbildēt uz trim jautājumiem: vai labojums tiešām darbojas tieši tajā PHP, kas apkalpo Jūsu vietni, vai vietne strādās ar jauno versiju un vai kāds nav izmantojis ievainojamību agrāk.

Tieši to pārbauda Redfox Cloud PHP2Shell audits. Jūsu vietni manuāli pārbauda serveru inženieris, nevis automātisks skeneris, un rezultātus saņemat rakstiski, saprotamā valodā. Nav obligāti jābūt mūsu hostinga klientam.

PHP2Shell audits

29 € + PVN

Precīza PHP versija un SAPI, kas apkalpo Jūsu domēnu
Vai piegādātājs ir uzstādījis labojumu Jūsu PHP pakotnē
Kļūdu žurnāli un uzlaušanas pazīmes kopš 17. oktobra
Jūsu TVS un spraudņu risks
Rakstisks pārskats un labošanas cena

Pasūtīt par 29 €

Pilns drošības audits

199 € + PVN

Viss, kas ietilpst PHP2Shell auditā
Sistēmas pakotnes, kodols un zināmās CVE
Servera, ugunsmūra, SSH, TLS un PHP konfigurācija
TVS, spraudņu, tēmu un individuālā koda drošības kļūdas
Ļaunprātīgs kods, sētas durvis, nezināmi cron uzdevumi

Pasūtīt par 199 €

Sazināmies 2 darba stundu laikā pēc apmaksas (no pirmdienas līdz piektdienai 9:00–18:00 pēc Viļņas laika). Maksājums ir vienreizējs. Labošanas cenu sniedzam pēc audita, un to, vai darbus veiksim mēs, izlemjat Jūs.

Biežāk uzdotie jautājumi

Vai pietiek ar to, ka hostinga pakalpojumu sniedzējs atjaunināja PHP?

Ja piegādātājs apstiprina, ka labojums ir uzstādīts tieši tai PHP versijai, kas apkalpo Jūsu vietni, svarīgākais solis ir sperts. Taču koplietošanas hostingā bieži darbojas vairākas PHP versijas, un labojums neizdzēš uzlaušanas pēdas, ja uzbrukums notika agrāk. Tāpēc vērts pārbaudīt arī žurnālus kopš 17. oktobra.

Vai Cloudflare vai cits WAF mani aizsargā?

Tikai uz laiku un tikai daļēji. WAF bloķē zināmus uzbrukumu šablonus tai datplūsmai, kas iet caur to. Ja serveris ir sasniedzams tieši pēc IP adreses vai parādās jauns uzbrukuma variants, WAF nepalīdzēs. Problēmu atrisina tikai PHP atjaunināšana.

Mana vietne darbojas ar PHP 7.4, 8.0 vai 8.1. Ko darīt?

Šīm versijām oficiālu labotu laidienu nav – PHP komanda ir publicējusi tikai pirmkoda labojumus tiem, kas PHP kompilē paši. Drošākais ceļš ir atjaunināt uz PHP 8.2 vai jaunāku. Pirms tam vērts pārbaudīt, vai vietne un spraudņi ar jauno versiju darbosies.

Kā saprast, vai vietne jau ir uzlauzta?

Biežākās pazīmes ir nezināmi PHP faili, jauni administratori, dīvainas pāradresācijas, vietnes procesu palaistas komandas un atkārtotas atmiņas izsīkuma kļūdas „on line 0” kļūdu žurnālos. Dažas pazīmes redzamas tikai servera līmenī, tāpēc, vienkārši apskatot vietni, tās var nepamanīt.

Vai varu pārbaudīt savu vietni ar internetā publicētu uzbrukuma kodu?

Mēs to neiesakām. Publiski izplatītā koda darbība nav apstiprināta, un šāds kods dažkārt pats ir inficēts ar ļaunprogrammatūru. Drošāk ir pārbaudīt PHP versiju, labojuma statusu un žurnālus.

Vai zināt, kura PHP versija šobrīd apkalpo Jūsu vietni – un vai neviens to nav izmantojis pirms Jums?