23.10.2026

PHP2Shell: vai atkārtojas Log4Shell scenārijs?

Kā novērst kritiskās PHP ievainojamības un ierobežot incidentu risku.

Datakom kiberdrošības komandas novērotais:

Divas kritiskas PHP ievainojamības (CVE-2026-109618 un CVE-2026-109619, CVSS v4 9.2) ļauj attālināti izpildīt kodu bez autentifikācijas. Atjauniniet PHP uz 8.5.12, 8.4.27, 8.3.36 vai 8.2.35 un restartējiet visus PHP procesus. Līdz tam izmantojiet WAF un konfigurācijas pagaidu pasākumus

Ja jūsu uzņēmuma tīmekļa vietnes, e-komercija vai iekšējās sistēmas darbojas ar PHP, tās jāatjaunina tuvāko dienu laikā. 21. oktobrī PHP izstrādātāji izlaida ārkārtas drošības atjauninājumu divām kritiskām ievainojamībām, kas kopā pazīstamas kā PHP2Shell. Uzbrucējs, izmantojot tās, var attālināti izpildīt kodu serverī bez jebkādas autentifikācijas.

PHP darbina lielu daļu interneta, tostarp WordPress, Drupal, Magento, Joomla un Laravel risinājumus. Šīs ievainojamības atrodas pašā PHP interpretatorā, nevis kādā spraudnī vai lietotnē, tāpēc ir skarta praktiski katra PHP instalācija, kas apkalpo tīmekļa pieprasījumus. Informācija par ievainojamībām noplūda vēl pirms ielāpu publicēšanas, tāpēc laiks reaģēšanai ir īss.

Vēsture atkārtojas:
no Log4Shell līdz PHP2Shell

Situācija ļoti atgādina 2021. gada decembri, kad atklāja Log4Shell (CVE-2021-44228, CVSS 10.0). Toreiz kritiskā kļūda bija Java žurnālošanas bibliotēkā Apache Log4j. Lai pārņemtu serveri, uzbrucējam pietika iesūtīt vienu speciāli veidotu teksta virkni jebkurā laukā, kas nonāca žurnālā.

Ievainojamību publiskoja 9. decembrī. Masveida skenēšana sākās nākamajā dienā, un daļa uzbrukumu tika novērota jau pirms publiskošanas. 17. decembrī CISA izdeva ārkārtas direktīvu ED 22-02, kas federālajām iestādēm noteica novērst ievainojamību līdz 23. decembrim. Dažu nedēļu laikā sekoja vēl trīs saistītas CVE, jo pirmie ielāpi nebija pilnīgi. Kopējie zaudējumi tiek lēsti vairāk nekā 10 miljardu ASV dolāru apmērā, un uzbrukumi turpinājās vēl gadiem.

Lielākā mācība no Log4Shell nebija tehniska. Daudzas organizācijas nedēļām ilgi nespēja atbildēt uz jautājumu "kur mums vispār ir Log4j?". Ar PHP ir tieši tāpat: tas bieži ir iebūvēts hostingā, konteineros, piegādātāju produktos un aizmirstās vietnēs.

	Log4Shell (2021)	PHP2Shell (2026)
Kas skarts	Java bibliotēka Log4j, iebūvēta tūkstošos produktu	PHP interpretators, uz kura darbojas liela daļa tīmekļa vietņu
Bīstamība	CVSS 10.0, RCE bez autentifikācijas	CVSS v4 9.2, RCE bez autentifikācijas
Publiskošana	Detaļas izplatījās pirms visi bija gatavi	Noplūda dienu pirms plānotā ielāpa
"Exploit" sarežģītība	Ļoti vienkāršs: viena teksta virkne	Sarežģīts atmiņas bojājums, kam parasti vajag ekspertu darbu
Laiks līdz uzbrukumiem	Stundas pēc publiskošanas	Pirmie mēģinājumi jau ielāpa dienā
Galvenā problēma	Nezināja, kur Log4j ir izmantots	Nezina, kur un kādas versijas PHP darbojas

Kas šoreiz ir citādi?

Toreiz uzbrukumi sākās ātri tāpēc, ka exploit bija triviāls. PHP2Shell ir atmiņas bojājuma ievainojamības, un vēl pirms dažiem gadiem uzticama exploit izstrāde tām prasīja nedēļas specializēta darba. Šoreiz vairākas komandas ievainojamības atkārtoja jau pirmajā dienā.

Tas atbilst plašākai tendencei. Pēc Mandiant datiem vidējais laiks no ievainojamības publiskošanas līdz tās izmantošanai 2018.–2019. gadā bija aptuveni 63 dienas, bet 2025. gadā tas kļuva negatīvs: aptuveni −7 dienas, tas ir, uzbrukumi bieži sākas pirms ielāpa. Pētījumi rāda, ka AI rīki spēj sagatavot strādājošu exploit no ievainojamības apraksta dažās minūtēs. Tikmēr organizāciju vidējais kritisko ievainojamību novēršanas laiks joprojām ir ap 55–60 dienām.

Arī Log4Shell gadījumā CISA reaģēja dažu dienu laikā. Ārkārtas direktīva un iekļaušana KEV katalogā tomēr sekoja jau notiekošiem uzbrukumiem. Šodien šī plaisa ir vēl lielāka, tāpēc nevar gaidīt oficiālu apstiprinājumu par izmantošanu. Pirmās stundas jāizmanto inventarizācijai, kompensējošajām kontrolēm un WAF pielāgošanai, bet pirmās dienas ielāpu uzstādīšanai.

Īsumā par ievainojamībām

Abas ievainojamības ir novērtētas kā kritiskas (CVSS v4 9.2), un tās var izmantot bez autentifikācijas.

CVE	Būtība	Augstākais risks
CVE-2026-109618	Atmiņas bojājums, kad serverim pietrūkst atmiņas; to var izraisīt ar speciāli sagatavotu multipart pieprasījumu	Apache mod_php, kur uzbrukums nostrādā vēl pirms lietotnes koda
CVE-2026-109619	Atmiņas izmantošana pēc atbrīvošanas, jo starp pieprasījumiem saglabājas novecojis stāvoklis	Vides, kur worker procesi tiek lietoti atkārtoti; ceļi caur session upload progress un PHP 8.5 kļūdu izsekošanu

Skartās vides:
PHP-FPM, Apache mod_php, php-cgi, FrankenPHP un LiteSpeed.

Drošā versija

PHP versija	Patched version
8.5	8.5.12
8.4	8.4.27
8.3	8.3.36
8.2	8.2.35
7.4, 8.0, 8.1	Oficiālu atjauninājumu NAV; nepieciešams distributīva vai LTS piegādātāja ielāps, vai pāreja uz jaunāku versiju

Situācija uz 23. oktobri.

CERT.lv un EU- Cert ziņo par pirmajiem uzbrukuma mēģinājumiem. Vairākas pētnieku komandas ievainojamības jau ir atkārtojušas, un publisks exploit tiek gaidīts drīzumā. Uz 21. oktobri ievainojamības vēl nebija iekļautas CISA KEV katalogā, bet jau uzbrucēji izmantoja to uzbrukumos ar automātisku izpildes faila pielietošanu.

Rekomendācijas: rīcības plāns

Ievainojamības pilnībā novērš tikai PHP atjaunināšana un visu PHP worker procesu restartēšana. Pārējie pasākumi samazina risku līdz brīdim, kad atjauninājums ir uzstādīts.

Pirmajās 24 stundās

Apzināt visas PHP instalācijas: tīmekļa vietnes, e-veikalus, klientu portālus, iekšējās sistēmas, konteinerus un hostinga pakalpojumus. Katrai jānosaka versija un darbības režīms (FPM, mod_php, CGI).
Prioritāti piešķirt publiski pieejamām sistēmām un tām, kas darbojas ar Apache mod_php.
Atjaunināt uz 8.5.12, 8.4.27, 8.3.36 vai 8.2.35, vai uzstādīt operētājsistēmas distributīva ielāpu. Pēc tam restartēt visus PHP procesus.
Ja hostingu nodrošina ārējs piegādātājs, rakstiski pieprasīt apstiprinājumu par atjaunināšanu un tās termiņu.

72 stundu laikā

Sistēmām ar PHP 7.4, 8.0 vai 8.1 atrast piegādātāja ielāpu vai sagatavot migrācijas plānu. Līdz tam piemērot pagaidu aizsardzību, kas aprakstīta nākamajā sadaļā.
Pārbaudīt, vai kopš 20. oktobra nav notikušas aizdomīgas darbības: neparasti PHP procesu avārijas, atmiņas izsīkuma kļūdas, jauni faili tīmekļa direktorijās, negaidīti izejošie savienojumi. Jāņem vērā, ka tukši žurnāli vēl nenozīmē, ka sistēma ir droša.
Ar ievainojamību skenēšanu pārliecināties, ka atjauninājums ir uzstādīts visur.

Nedēļas laikā

Informēt vadību par skartajām sistēmām, veiktajiem pasākumiem un atlikušo risku.
Ieviest pastāvīgu PHP un citu platformu versiju uzraudzību, lai nākamajā līdzīgā situācijā skarto sistēmu saraksts būtu pieejams uzreiz.
Pārskatīt ārkārtas ielāpu procesu: kas pieņem lēmumu, cik ātri var veikt restartu ražošanas vidē un kā tiek informēti klienti.

Risku mazinošie faktori

Web application firewall (WAF) un servera konfigurācija nevar aizstāt atjauninājumu. Tomēr pareizi pielāgoti tie būtiski apgrūtina uzbrukumu un neļauj vienai ievainojamībai pārvērsties nopietnā incidentā.

Adjusting WAF rules

Virtuālais ielāps. Pēc iespējas ātrāk aktivizēt WAF piegādātāja noteikumus pret CVE-2026-109618 un CVE-2026-109619, kad tie tiek publicēti. Pārbaudīt, vai tie darbojas bloķēšanas, nevis tikai novērošanas režīmā.
Multipart pieprasījumu kontrole. Viens no uzbrukuma ceļiem ir speciāli sagatavoti multipart pieprasījumi. Lietotnēs, kurām failu augšupielāde nav vajadzīga, šādus pieprasījumus bloķēt pilnībā. Pārējās ierobežot augšupielādi tikai uz konkrētiem URL.
Pieprasījumu izmēra ierobežojumi. WAF vai reversā starpniekservera līmenī ierobežot pieprasījuma ķermeņa izmēru, daļu skaitu un parametru ligzdojuma dziļumu atbilstoši tam, ko lietotne patiešām izmanto.
Pieprasījumu biežuma ierobežošana. Uzbrukumam var būt nepieciešami vairāki secīgi pieprasījumi, kas sasniedz vienu un to pašu worker procesu. Biežuma ierobežojumi no viena avota samazina uzbrukuma panākumu iespējas.
Lieko galapunktu slēgšana. Bloķēt piekļuvi administrācijas paneļiem, testa skriptiem un neizmantotiem PHP failiem no publiskā interneta.

Servera konfigurācija

Iestatījumus nosaka php.ini vai FPM pool līmenī un pēc tam restartē procesus. Ar ini_set() vai .user.ini tie iedarbojas par vēlu.

session.upload_progress.enabled=0 aizver apstiprināto sesiju ceļu.
fatal_error_backtraces=0 attiecas uz PHP 8.5.
memory_limit=-1 drīkst lietot tikai kopā ar stingriem post_max_size, upload_max_filesize un pieprasījumu izmēra ierobežojumiem.

Uzraudzība un ierobežošana

Iestatīt brīdinājumus par PHP procesu avārijām, atmiņas izsīkuma kļūdām un neparastiem 5xx kļūdu pieaugumiem. Web servera procesam piešķirt minimālas tiesības un ierobežot tā izejošos savienojumus. Tad pat veiksmīgs uzbrukums neļaus uzbrucējam tikt tālāk iekšējā tīklā.

Avoti

Kā Datakom var palīdzēt?

Datakom komanda var palīdzēt jums ātri noskaidrot, vai jūsu sistēmas ir apdraudētas, un tās aizsargāt. Kiberdrošības pakalpojumus sniedzam jau vairāk nekā 10 gadus.

Ievainojamību novērtējums. Apzinām visas jūsu PHP instalācijas un to versijas, un sagatavojam prioritizētu atjaunināšanas sarakstu.
Atjaunināšana un WAF pielāgošana. Palīdzam uzstādīt ielāpus, konfigurēt pagaidu aizsardzību un pielāgot WAF noteikumus tā, lai netiktu traucēta lietotņu darbība.
Kompromitācijas pārbaude. Pārbaudām, vai pirms atjauninājuma uzstādīšanas sistēmās nav bijusi nesankcionēta piekļuve.
SOC uzraudzība. Mūsu drošības operāciju centrs nepārtraukti uzrauga jūsu sistēmas, lai uzbrukuma mēģinājumi tiktu pamanīti un apturēti laikus.
Kiberdrošības vadītājs (vCISO). Palīdzam izveidot ielāpu pārvaldības procesu un sagatavot informāciju vadībai, lai nākamajā kritiskajā situācijā rīcība būtu ātra un saskaņota.