php2shell: kritiska PHP ievainojamība un kā pārbaudīt savu mājaslapu

PHP izstrādātāji 2026. gada 20. oktobrī paziņoja par ārkārtas drošības atjauninājumu un nākamajā dienā to izlaida. Abas kļūdas, ko tas labo, sauc par php2shell, un tās var ļaut jebkuram apmeklētājam palaist savu kodu serverī, kurā darbojas PHP. Pieteikties nevajag, spraudnis nav vajadzīgs, un nekas īpašs servera iestatījumos arī ne.

Ar WordPress drošības trauksmēm, kas atkārtojas ik pēc dažiem mēnešiem, šim gadījumam ir maz kopīga. Kļūda nav spraudnī vai satura pārvaldības sistēmā, bet pašā PHP, valodā, ar kuru darbojas WordPress, WooCommerce, Laravel, Drupal, Magento un lielākā daļa pēc pasūtījuma izstrādāto Latvijas mājaslapu. Ja jūsu mājaslapa ir veidota ar PHP, jautājums nav par mājaslapas kodu, bet par to, vai hostinga uzņēmums ir atjauninājis PHP.

Īsumā

Atjauniniet PHP uz 8.5.12, 8.4.27, 8.3.36 vai 8.2.35 (vai uz savas Linux distribūcijas salaboto pakotni) un restartējiet visus PHP procesus. Mājaslapas ar PHP 8.1, 8.0 vai 7.4 oficiālu labojumu nesaņem un paliek atvērtas, ja vien hostinga uzņēmums nav pats izveidojis salabotu pakotni. Tām ilgtermiņa risinājums ir pāreja uz PHP 8.3 vai jaunāku. Koda paraugi uzbrukumam jau ir publiski pieejami, un Cloudflare jau labojuma izlaišanas dienā novēroja uzbrukumus saviem klientiem.

Kādas ir abas kļūdas

PHP drošības paziņojums 21. oktobrī apraksta divas atsevišķas kļūdas. Abas ir kritiskas, un abām uzbrucējam nav jāpiesakās:

CVE	Nosaukums paziņojumā	Kas notiek
CVE-2026-109618	RCE via OOM corruption	Ja PHP pieprasījuma vidū beidzas atmiņa, pieprasījuma dati var palikt nepabeigti, un pēc tam PHP tos apstrādā kā derīgus
CVE-2026-109619	RCE via stale global state	Viena pieprasījuma iekšējie dati var palikt arī pēc tam, kad to atmiņa ir atbrīvota, un nākamais pieprasījums tajā pašā procesā tos var izmantot

Abas kļūdas rodas brīdī, kad PHP apstrādā pieprasījumu, vēl pirms sāk darboties mājaslapas kods. Tāpēc tās skar visu, kas ir uzrakstīts PHP, un labi uzrakstīta mājaslapa no tām nepasargā.

Kuras versijas ir apdraudētas

Visas atbalstītās PHP versijas līdz labotajām un visas neatbalstītās.

• PHP 8.2 līdz 8.5: labots 8.2.35, 8.3.36, 8.4.27 un 8.5.12. Visas zemākas versijas tajā pašā zarā ir apdraudētas.
• PHP 8.6 testa versijas: labots 8.6.0 RC4.
• PHP 8.1, 8.0 un 7.4: apdraudētas, oficiāla labojuma nav. PHP projekts publicēja tikai minimālus ielāpus pirmkodā. Vai jūsu mājaslapa ir drošībā, atkarīgs no tā, vai hostinga uzņēmums no tiem izveidoja jaunu pakotni.
• PHP 7.3 un vecākas: apdraudētas, un labojuma nebūs. CERT.LV norāda, ka kļūdas skar visas versijas, sākot ar PHP 5.

PHP 8.2 atbalsts beidzas 2026. gada 31. decembrī. Ja mājaslapu šodien pārceļ uz 8.2, pēc desmit nedēļām tas pats jautājums būs jārisina vēlreiz.

Kā pārbaudīt savu mājaslapu

Vispirms sastādiet sarakstu, jo mājaslapa reti ir vienīgā PHP sistēma uzņēmuma serveros. Jāpārbauda arī interneta veikals (WooCommerce, Magento, PrestaShop, OpenCart), klientu portāls, Moodle, Nextcloud, Roundcube e-pasts, phpMyAdmin un iekšējās sistēmas.

Katrai no tām svarīga ir PHP versija, ar kuru to darbina tīmekļa serveris, nevis tā, ko parāda servera komanda.

1. WordPress: atveriet Rīki → Vietnes veselība → Informācija → Serveris. Tur norādītā PHP versija ir tā, ar kuru darbojas jūsu mājaslapa.
2. Citas PHP mājaslapas: hostinga vadības panelī PHP versija ir redzama katrai mājaslapai vai domēnam. cPanel tā parasti ir sadaļā MultiPHP Manager vai Select PHP Version.
3. Salīdziniet numuru ar labotajām versijām. Ja jums ir 8.1 vai vecāka versija, jautājiet hostinga uzņēmumam tieši, vai tam ir salabota pakotne. Pēc versijas numura vien to uzzināt nevar.
4. Ja serveri uztur kāds cits, palūdziet hostinga uzņēmumam vai izstrādātājam rakstiski apstiprināt, kādu PHP versiju izmanto katra mājaslapa un kurā datumā uzstādīts labojums.

Ja jums ir savs serveris, php -v terminālī neko nepierāda. Komandrindas PHP bieži ir atsevišķa instalācija, un atjaunināta pakotne sāk darboties tikai pēc tam, kad restartē PHP-FPM, Apache vai LiteSpeed. Ja PHP darbojas Docker konteinerā, attēli jāpārbūvē ar laboto versiju.

Ko darīt

Koplietošanas vai pārvaldītā hostingā PHP atjaunina hostinga uzņēmums, bet versiju parasti izvēlaties jūs. Ja mājaslapa joprojām darbojas ar 7.4 vai 8.1, jo neviens to nav pārcēlis, hostinga uzņēmumam var nebūt, ar ko to salabot. Vadības panelī pārslēdziet versiju uz 8.3 vai jaunāku un pirms tam izveidojiet rezerves kopiju, jo, mainot versiju, visbiežāk salūzt tieši veci spraudņi un tēmas.

Savā serverī atjauniniet PHP no avota, no kura tas uzstādīts (distribūcija, Ondřej Surý pakotņu krātuve, LiteSpeed pakotnes, vadības paneļa versijas), restartējiet visus PHP procesus un pārbaudiet versiju caur tīmekļa serveri, nevis terminālī.

Ja sistēmu šodien atjaunināt nevar, jo tai ir PHP 8.1 vai vecāka versija bez salabotas pakotnes, CERT.LV iesaka ierobežot piekļuvi tai, vismaz no ārvalstīm, līdz to var atjaunināt. Iekšējo rīku vai vecu administrācijas paneli bieži vienkāršāk pavisam atslēgt no publiskā interneta.

Ugunsmūris mājaslapas priekšā pagaidām palīdz. Cloudflare dažas stundas pirms paziņojuma ieslēdza aizsardzības noteikumus pret php2shell visiem plāniem, arī bezmaksas plānam. Pats Cloudflare tos sauc par pagaidu risinājumu, un uzbrucēji jau mainīja pieprasījumus, lai tos apietu. Mājaslapai aiz Cloudflare ir vairāk laika, bet labojuma tā nav.

Kamēr atjauninājums vēl nav uzstādīts, PHP projekts kā pagaidu soli iesaka šo iestatījumu php.ini vai PHP-FPM pūla konfigurācijā, pēc tam restartējot PHP:

session.upload_progress.enabled = 0

Iestatījumam jābūt tieši tur. ini_set() kodā un .user.ini datnes sāk darboties par vēlu. WordPress augšupielādes progresu neizmanto, tāpēc WordPress mājaslapā nekas redzams nemainās. PHP paziņojums gan skaidri saka, ka iestatījums bloķē apstiprinātos uzbrukuma ceļus, bet ne visus variantus, un pilnīgas aizsardzības bez atjaunināšanas nav.

Vēl viena lieta: nepalaidiet neko no GitHub krātuvēm ar nosaukumu “php2shell PoC”. Vismaz viena no tām piedāvā ātrā labojuma skriptu, kas prasa sudo tiesības. Šeit vajag tikai pakotnes atjauninājumu un vienu konfigurācijas rindu.

Pazīmes, ka mājaslapa jau ir uzlauzta

Uzbrukuma kods ir publisks, tāpēc neatjauninātu mājaslapu kāds var būt jau mēģinājis uzlauzt. PHP atjaunināšana aptur jaunus uzbrukumus, bet neizdzēš to, kas jau ir iestādīts. Pārbaudiet:

• jaunas vai mainītas PHP datnes mājaslapas mapē, wp-content/uploads vai /tmp;
• administratorus, kurus neviens nepazīst;
• PHP procesus, kas avarē bez iemesla, vai HTTP 500 kļūdu virknes pēc lielu formu iesniegšanas;
• surogātpastu, ko sūta mājaslapa, vai hostinga uzņēmuma brīdinājumu par ļaunatūru.

Ja kaut ko atrodat, saglabājiet žurnālus, nomainiet datubāzes paroles un API atslēgas un aiciniet palīgā kādu, kas tīra uzlauztas mājaslapas. Tieši ar to nodarbojamies, kad salabojam uzlauztu mājas lapu.

Par PHP versiju bieži neviens neatbild

Lielāko daļu mājaslapu uzlauž nevis gudri uzbrucēji, bet caur atjauninājumu, ko neviens neuzstādīja. Ar php2shell atjauninājums nav WordPress vai satura pārvaldības sistēmas administrācijas panelī, kur kāds varētu vismaz pamanīt paziņojumu. Tas ir līmeni zemāk, serverī, un daudzās mājaslapās to kopš palaišanas neviens nav skatījies. Regulāri atrodam uzņēmumu mājaslapas, kas joprojām darbojas ar PHP 7.4, lai gan aktuāla tā bija pirms pieciem gadiem, jo mājaslapa strādāja un neviens negribēja būt tas, kurš to salauž.

21. oktobrī pārbaudījām visus serverus, kurus uzturam, un katrai mājaslapai PHP versiju, ar kuru tā tiešām darbojas. Šī pārbaude ir daļa no mūsu uzturēšanas plāniem līdzās WordPress, tēmu un spraudņu atjauninājumiem.

Ja nezināt, ar kuru PHP versiju darbojas jūsu mājaslapa, vai zināt, ka tā ir veca, bet pāreju atliekat, jo baidāties kaut ko salauzt, atsūtiet mums adresi. Pārbaudīsim versiju, pateiksim, vai mājaslapa ir apdraudēta, un, ja tā jāpārceļ uz PHP 8.3 vai jaunāku, pārcelsim to un salabosim to, ko vecā versija slēpa.

Lasiet arī: vai WordPress ir drošs un kas to patiesībā apdraud.