PHP2Shell: kritiska PHP ievainojamība — vai Jūsu vietne ir apdraudēta?

Skartas ir visas PHP versijas, kas savā atzarā ir vecākas par 8.5.12, 8.4.27, 8.3.36 un 8.2.35, un tas nozīmē gandrīz katru PHP vietni, kuru šonedēļ neviens nav atjauninājis. Šodien pirmais darbs ir noskaidrot, kura versija apkalpo Jūsu vietni, un to atjaunināt — pilnīgu apiešanas risinājumu nav, un pats PHP paziņojums saka, ka atjaunināšana ir vienīgā droša izvēle.

Trešdien, 21. oktobrī, PHP komanda vienlaikus izlaida četras ārkārtas versijas. Ievainojamību pāris, ko tās labo, ir ieguvis nosaukumu PHP2Shell, un tas apraksta rezultātu precīzi: no tīkla pieprasījuma līdz koda izpildei uz servera. Šis raksts ir par to, kas tieši ir atrasts, kā saprast, vai tas skar Jūs, un kādā secībā rīkoties — arī tad, ja atjaunināt uzreiz nevar.

Kas ir PHP2Shell un kas notika 21. oktobrī

Oficiālajā paziņojumā teikts, ka 8.5.12, 8.4.27, 8.3.36 un 8.2.35 labo divas kritiskas ievainojamības, kuras var ļaut neautentificētam uzbrucējam attālināti izpildīt kodu, un ka visiem PHP lietotājiem ir stingri ieteicams atjaunināties nekavējoties. Turpat ir arī teikums, kas nosaka visu pārējo šī raksta saturu: pilnīgu apiešanas risinājumu nav, un atjaunināšana ir vienīgā droša izvēle.

Abām ievainojamībām PHP ir piešķīris CVSS v4.0 novērtējumu 9.2 no 10, taču tās ir divas atsevišķas kļūdas ar atšķirīgu mehānismu un, kā redzēsiet tālāk, arī ar atšķirīgu apstiprinājuma pakāpi — un tieši šī otrā atšķirība praksē nosaka, no kura servera sākt.

CVE-2026-109618 — bojāta atmiņa pēc atmiņas trūkuma. Kad PHP pietrūkst atmiņas, tas izmanto longjmp(), lai pārtrauktu pieprasījuma apstrādi. Oficiālais apraksts norāda, ka dažos brīžos pieprasījuma atmiņa ir sasniedzama, pirms tā ir pilnībā inicializēta; ja tieši tad neizdodas atmiņas piešķiršana, pārtraukšana netiek apstrādāta korekti un paliek nederīga atmiņa, ko noslēguma kods vēl nolasa vai pēc kuras pieņem lēmumu.

Svarīga detaļa, kas maina to, kam šis drauds attiecas: atmiņas trūkumu panāk ar īpaši sagatavotu multipart pieprasījumu, un tajā nav jābūt nevienam augšupielādētam failam. Oficiālais apraksts min vairākas multipart apstrādes problēmas — pieprasījumu bez izmantojama deklarēta garuma, daļu ar neierobežotu galveņu skaitu, tukšus failu laukus, kas netiek ieskaitīti ierobežojumos. Tas nozīmē, ka pieprasījums var būt pavisam neliels un iekļauties parastajās post_max_size un memory_limit robežās.

CVE-2026-109619 — novecojis globālais stāvoklis. PHP procesā starp pieprasījumiem saglabājas globāls stāvoklis: kļūdu, sesiju, objektu un paplašinājumu dati. Oficiālais apraksts saka, ka šis stāvoklis ir jāatiestata, pirms pieprasījuma atmiņa tiek atbrīvota. Ja atiestatīšanu pārtrauc fatāla kļūda vai ja noslēguma brīdī diagnostika to aizpilda no jauna, atmiņa tiek atbrīvota, bet norāde uz to paliek. Šo kļūdu klasi starptautiski sauc par use-after-free — lietošana pēc atbrīvošanas.

Tālāk ir nosacījums, kas šo ievainojamību padara grūtāku, nekā izklausās: novecojušo norādi var izmantot tikai darbība, kas notiek pirms parastās pieprasījuma inicializācijas, un oficiālais apraksts nosauc divus apstiprinātus šādus gadījumus — INI diagnostiku un sesijas augšupielādes progresa apstrādi. Turklāt uzbrucēja vēlākajam pieprasījumam ir jānonāk tieši tajā pašā procesā, kurā radās bojātais stāvoklis, tāpēc atsevišķs mēģinājums izdodas reti, un apraksts tieši norāda, ka vairāki procesi un to nomaiņa izredzes samazina, bet pašu nosacījumu nenovērš.

Cik viegli to ir izmantot un pret ko tas ir pierādīts

Šeit ir vērts būt precīziem, jo tieši šajā vietā lielākā daļa rakstu internetā pārspīlē uz vienu vai otru pusi.

Parole nav vajadzīga, un nav vajadzīgs arī, lai kāds vietnē kaut ko nospiestu — CVSS vektorā tas ir redzams kā PR:N un UI:N. Tajā pašā vektorā tomēr ir AC:H un AT:P: uzbrukuma sarežģītība ir novērtēta kā augsta un tam ir papildu priekšnosacījumi. Praksē tas nozīmē atkārtotus mēģinājumus, un izdošanās ir atkarīga no PHP būvējuma, paplašinājumiem, priekšgala uzvedības un atmiņas izkārtojuma. Tātad nē — ar vienu parastu pieprasījumu nepietiek; bet tas uzbrucējam arī neko nemaksā, jo mēģinājumu skaitu neierobežo nekas.

Pierādījuma pakāpe abām kļūdām atšķiras, un šī atšķirība ir svarīga, izvēloties, cik ļoti steigties. CVE-2026-109618 gadījumā pilnīga attālināta koda izpilde ir apstiprināta pret mod_php ar noklusējuma ievades un atmiņas ierobežojumiem; par PHP-FPM tas pats apraksts saka, ka pirmkoda analīze to uzskata par ievainojamu, bet pilnīgs PHP-FPM uzbrukums nav demonstrēts. FrankenPHP tur minēts kā mod_php analogs, bet LSAPI — kā PHP-FPM analogs, abos gadījumos bez pārbaudīta uzbrukuma.

CVE-2026-109619 gadījumā sesijas dzīvescikla ceļš ir pārbaudīts gan pret mod_php, gan PHP-FPM, savukārt otrs ceļš, kas iet caur fatālās kļūdas izsekojumu, ir apstiprināts tikai pret mod_php.

No tā izriet praktiska secība: ja Jūsu vietne strādā uz mod_php, Jūs esat pirmajā rindā, jo tieši tur abas kļūdas ir apstiprinātas. PHP-FPM un LiteSpeed gadījumā risks ir reāls, bet pagaidām daļēji apstiprināts. Nevienā no šiem gadījumiem tas nav iemesls gaidīt — tas ir iemesls zināt, no kura servera sākt.

Kā šī nedēļa izskatījās pa stundām

Hronoloģija nav kuriozs — tā izskaidro, kāpēc ieteikumi pirmajās stundās atšķīrās no tiem, kas ir spēkā tagad, un kāpēc daļa rakstu internetā joprojām ir novecojuši.

20. oktobra vakarā bija zināms, ka kaut kas nāk, bet nebija zināms, kas tieši: PHP bija paziņojis par gaidāmo ārkārtas laidienu, un CloudLinux statusa lapa tajā pašā vakarā fiksē, ka tehniskie dati un skartās versijas ir plānots publiskot nākamās dienas laidiena brīdī. Tehniskais apraksts tobrīd publisks vēl nebija.

Līdz nākamajai dienai situācija bija mainījusies, un ne par labu: 21. oktobra rītā CloudLinux fiksē, ka publiskajā apritē jau ir uzbrukuma paraugs, un plkst. 9.08 pēc UTC izplata ugunsmūra noteikumu kopu, kas bloķē zināmo izmantošanas pieprasījuma paraugu. Astoņpadsmit minūtes vēlāk tajā pašā lapā parādās teikums, kas šo nedēļu raksturo vislabāk — šim paraugam atbilstoši mēģinājumi jau tiek novēroti, tātad kāds jau meklēja serverus, kuriem labojuma vēl nav.

PHP labojumi iznāca plkst. 14.00 pēc UTC, kas nozīmē, ka starp publiski pieejamu uzbrukuma paraugu un publiski pieejamu labojumu pagāja vairākas stundas, un šajās stundās uzbrukuma mēģinājumi jau notika.

Vienu atrunu šeit ir godīgi pateikt: pilnīgi bez labojuma pasaule nebija, jo PHP paziņojumā teikts, ka Linux distribūcijas un ilgtermiņa atbalsta piegādātāji labojumus saņēma iepriekš, tāpēc daļai serveru atjauninājums bija pieejams agrāk nekā pārējiem — publiski pieejams tas gan nebija nevienam.

Pēc tam sākās garākā daļa, kas turpinās joprojām: pakotņu izplatīšana. Operētājsistēmu uzturētāji un hostinga platformas savas pakotnes būvē atsevišķi, un tās parādās stundu vai dienu laikā, katra savā tempā. Tieši šajā posmā atrodas liela daļa koplietošanas hostinga lietotāju, un tieši tāpēc jautājums «vai labojums ir iznācis» un jautājums «vai labojums ir uz mana servera» šonedēļ ir divi dažādi jautājumi ar atšķirīgām atbildēm.

Vai Jūsu vietne ir apdraudēta

Oficiālajos brīdinājumos skarto versiju diapazoni ir uzrakstīti šādi: viss, kas vecāks par 8.2.35, viss, kas vecāks par 8.3.36, viss, kas vecāks par 8.4.27, un viss, kas vecāks par 8.5.12 — katrs savā atzarā.

Svarīga detaļa, kas pieļauj kļūdu: skaitlis, ko rāda php -v, ne vienmēr pasaka visu. Linux distribūcijas un hostinga platformas mēdz pārnest labojumu uz vecāku versiju, nemainot tās numuru — mainās tikai pakotnes laidiena numurs. Tādā gadījumā 8.4.26 var būt jau salabots, bet var arī nebūt. Vienīgais veids, kā to zināt, ir paskatīties pakotnes aprakstā vai pajautāt piegādātājam; pats versijas numurs uz šo jautājumu neatbild.

Atsevišķi par vecākām versijām. PHP 8.1 un vecākas no PHP projekta regulārus atjauninājumus vairs nesaņem, taču, ņemot vērā nopietnību, drošības komanda ir sagatavojusi minimālus pirmkoda labojumus versijām 7.4, 8.0 un 8.1 — tiem, kas būvē no pirmkoda vai kam nav piekļuves uzturētāja atbalstam. Paziņojums turpat iesaka sazināties ar savu piegādātāju, jo daļa distribūciju un ilgtermiņa atbalsta piegādātāju labojumus pārnes. Ja Jūsu vietne strādā uz PHP 7.x, īstā problēma nav šī nedēļa — īstā problēma ir, ka nākamajā reizē labojuma var arī nebūt. Un PHP 8.2, kas šoreiz labojumu saņēma, atbalstu zaudē 2026. gada 31. decembrī.

Kā pārbaudīt versiju, atkarībā no tā, kur vietne dzīvo

Pārbaude aizņem minūtes, un to ir vērts izdarīt katrai vietnei atsevišķi, nevis katram serverim: uz viena servera mēdz dzīvot vietnes ar atšķirīgām PHP versijām, un parasti tieši tā vecākā, par kuru visi ir aizmirsuši, ir publiski sasniedzama.

Koplietošanas hostings ar cPanel. Versiju rāda sadaļa MultiPHP Manager, kurā katram domēnam ir sava rinda; Plesk tai pašai lietai izmanto PHP Settings katra abonementa iekšienē. Abos gadījumos ir vērts pārliecināties, ka skatāties uz to domēnu, par kuru ir runa, nevis uz servera noklusējumu.

Savs serveris vai virtuālais serveris. Komandrindā to parāda php -v, bet ar vienu būtisku atrunu: komandrindas PHP bieži ir pavisam cita versija nekā tā, kas apkalpo tīmekļa pieprasījumus. Ticamāko atbildi dod tas pats ceļš, pa kuru strādā vietne — PHP-FPM konfigurācijas pool sadaļā norādītais izpildāmais fails.

Konteineri. Ja vietne strādā Docker vidē, versiju nosaka attēls, nevis saimniekdators, tāpēc ir divi soļi: pārbūvēt attēlu ar atjauninātu pamatattēlu un pēc tam pārstartēt konteinerus. Attēls, kas būvēts pirms 21. oktobra, labojumu nesatur neatkarīgi no tā, cik bieži konteiners ir pārstartēts.

Ja piekļuves nav nevienam no šiem. Tad jautājums ir hostinga sniedzējam, un šonedēļ tas ir pilnīgi normāls jautājums, uz kuru viņiem jau ir sagatavota atbilde. Formulējums, kas ietaupa saraksti: «Kura PHP versija apkalpo manu domēnu, vai tajā ir PHP2Shell labojums, un, ja vēl nav, kurā datumā tas būs?»

Ko darīt šodien

Šodienas secība ir šāda: vispirms atjaunināt PHP un pārstartēt visu, kas to izpilda, tad pārliecināties, ka apmeklētājus tiešām apkalpo jaunā versija, pēc tam pārbaudīt, vai izmantotā pakotņu krātuve labojumu vispār ir izlaidusi, un tikai pēc tam meklēt pēdas. Pirmais solis aizņem minūtes, pēdējais var aizņemt dienas, un tieši tāpēc tos nav vērts sajaukt vietām.

Pirmkārt, atjauniniet. Pārvaldīta hostinga gadījumā to dara sniedzējs, un Jūsu darbs ir uzdot jautājumu un saņemt datumu. Ja serveri pārvaldāt pats, pēc pakotņu atjaunināšanas ir jāpārstartē tas, kas PHP izpilda: Apache, PHP-FPM vai LSAPI. Šis solis tiek izlaists pārsteidzoši bieži — pakotne ir nomainīta, bet vecie procesi turpina strādāt ar veco kodu, tā ka pārbaude rāda jauno versiju, kamēr apmeklētājus apkalpo vecā.

Otrkārt, pārbaudiet, ka atjauninājums tiešām ir pielietots — pa to pašu ceļu, pa kuru strādā vietne, nevis caur komandrindu.

Treškārt, ja izmantojat brīvprātīgi uzturētu pakotņu krātuvi, pārbaudiet, vai tā labojumu ir izlaidusi. PHP paziņojumā ir atsevišķs brīdinājums par rpms.remirepo.net: tās lietotājiem ieteikts pāriet uz distribūcijas pakotnēm vai būvēt no pirmkoda.

Ceturtkārt, tikai pēc tam pārbaudiet, vai vietnē nav pēdu. Atjaunināšana aizver durvis, bet neatbild uz jautājumu, vai pa tām kāds jau ir ienācis.

Ja atjaunināt uzreiz nevar

Šo sadaļu ir vērts lasīt ar skaidru apziņu, ka neviens no šeit minētajiem soļiem neaizvieto atjauninājumu — PHP paziņojums to saka tieši.

Pret CVE-2026-109618 paziņojums min atmiņas ierobežojuma noņemšanu: memory_limit=-1, un turklāt tā, lai lietotne to nevarētu pārrakstīt — piemēram, ar php_admin_value PHP-FPM vai Apache konfigurācijā, pārliecinoties, ka neviens cits iestatījums galīgo ierobežojumu neatliek atpakaļ. Jāsaprot, ko šī izvēle maksā: uz koplietošanas servera tā apmaina vienu risku pret otru, jo viens pieprasījums tagad var apēst visu pieejamo atmiņu. Ievainojamības aprakstā ir arī brīdinājums neizmantot RLIMIT_AS un RLIMIT_DATA, jo tie var likt atmiņas piešķiršanai neizdoties un tādējādi novest tieši pie ievainojamā ceļa.

Pret CVE-2026-109619 paziņojums min session.upload_progress.enabled=0 un, PHP 8.5 gadījumā, fatal_error_backtraces=0 — abos gadījumos ar norādi pēc tam pārstartēt visus procesus. Pašā ievainojamības aprakstā ir arī pm.max_requests=1, kas liek PHP-FPM pēc katra pieprasījuma procesu nomainīt; tas ir PHP-FPM baseina iestatījums, un tur tas ir minēts ar atrunu «ja veiktspēja nav faktors». Turpat ir teikts arī tas, kas šo pasākumu notur īstajās robežās: procesu nomaiņa samazina izredzes uz vienu pieprasījumu, bet pašu nosacījumu nenovērš.

Noderīgs ir arī tas, kas nav apiešana, bet samazina uzbrukuma virsmu: konservatīvs post_max_size, saprātīgs ievades ligzdošanas dziļums un ierobežots augšupielādes apjoms. Tās ir labas vērtības jebkurā nedēļā, ne tikai šajā.

Kā saprast, vai Jūs jau esat skarti

Pēc atjaunināšanas ir vērts pārskatīt tīmekļa servera žurnālus par pēdējām dienām. Meklējams ir neparasti liels skaits multipart pieprasījumu uz vienu un to pašu adresi — un šeit ir viegli meklēt nepareizi: tie mēdz būt nelieli un iekļauties parastajos ierobežojumos, tāpēc pēc apjoma tos neatradīs. Runīgākas ir pēkšņas 500. kļūdu virknes, kas sākas un beidzas bez redzama iemesla: uzbrukums, kas balstās uz atmiņas trūkumu, neizdodas daudz biežāk, nekā izdodas, un katrs neveiksmīgais mēģinājums atstāj kļūdu.

Failu sistēmā nozīme ir izmaiņu laikiem: PHP fails, kas ir mainīts naktī, kad neviens nestrādāja, ir jāpaskaidro. Vērts pārbaudīt arī plānotos uzdevumus un ierakstus, kas nodrošina automātisku palaišanu pēc pārstartēšanas — uzbrucējam ar koda izpildi pirmais darbs ir nostiprināties, lai piekļuve pārdzīvotu tieši to atjauninājumu, ko Jūs tikko uzstādījāt.

Atsevišķi ir vērts pārbaudīt administratoru kontu sarakstu un lietojumprogrammu paroles un atslēgas. Ja koda izpilde ir notikusi, tad viss, ko serveris zina, ir jāuzskata par izlasītu — arī datubāzes pieslēgšanās dati un API atslēgas konfigurācijas failā.

Ja kaut kas no tā neizskatās pareizi, tīrīšana ir atsevišķs darbs ar savu secību, un to ir vērts darīt metodiski, nevis dzēšot aizdomīgos failus pa vienam. Mēs to esam aprakstījuši atsevišķi — kā notiek uzlauztas vietnes atkopšana, un, ja vēlaties, lai to izdara kāds cits, uzlauztu interneta vietņu atjaunošana ir atsevišķs pakalpojums ar fiksētu secību: izolācija, tīrīšana, cēloņa novēršana un pārbaude, ka vietne no meklētāju brīdinājumu sarakstiem ir noņemta.

Kad notikums kļūst par ziņojamu incidentu

Ja ir pamats domāt, ka uzbrucējs ir piekļuvis personas datiem, tehniskais jautājums kļūst arī juridisks. Vispārīgā datu aizsardzības regula paredz termiņu, kas sākas nevis no uzbrukuma, bet no brīža, kad pārzinis par personas datu aizsardzības pārkāpumu ir uzzinājis: ja iespējams, ne vēlāk kā 72 stundas ziņojumam uzraudzības iestādei. Pienākums neiestājas tad, ja pārkāpums maz ticami radīs risku fizisko personu tiesībām un brīvībām, un, ja risks ir augsts, informējamas ir arī pašas personas — arī šim pienākumam regulā ir savi izņēmumi.

Praktiskā nozīme šai sadaļai ir viena: brīdis, kad žurnālos ir atrasts kaut kas aizdomīgs, nav brīdis, kad sāk tecēt 72 stundas — tas ir brīdis, kad jānoskaidro, vai pārkāpums vispār ir noticis. Atsevišķa 500. kļūdu virkne, kas, kā aprakstīts iepriekš, visbiežāk ir neizdevies mēģinājums, pati par sevi nav pārkāpums. Taču tieši tāpēc šo noskaidrošanu nav vērts atlikt uz «kad būs mazāk darba», un tieši tāpēc žurnāli ir jāsaglabā, pirms tos pārraksta rotācija: tie ir vienīgais pierādījums gan par to, kas notika, gan par to, kas nenotika.

Ja Jūsu pārziņā ir vairākas vietnes

Aģentūrām un uzņēmumiem ar vairākām vietnēm šī nedēļa ir ne tik daudz tehnisks, cik organizatorisks uzdevums, un secība, kas strādā, ir vienkārša: vispirms saraksts, tad versijas, tad atjaunināšana prioritārā kārtībā.

Prioritāti nosaka nevis vietnes svarīgums, bet sasniedzamība un tas, kas to apkalpo. Augšā ir publiski pieejamas vietnes uz mod_php, jo tieši tur abas ievainojamības ir apstiprinātas; tad pārējais publiskais, un tikai pēc tam iekšējās sistēmas aiz ugunsmūra. Testa un izstrādes vides, par kurām visi aizmirst, sarakstā jāiekļauj obligāti — tās bieži strādā uz vecākas PHP versijas un bieži ir sasniedzamas no interneta, jo kādreiz tā bija ērtāk.

Vietnes, kuras pārvalda kāds cits, sarakstā paliek, bet ar citu aili: kam ir nosūtīts jautājums un kurā datumā saņemta atbilde. Šī aile vēlāk izrādās vērtīgāka par pārējām, jo tieši tā parāda, kurš sniedzējs reaģē un kurš ne.

Ko šajā gadījumā nozīmēja pārvaldīts hostings

Šī nedēļa labi parāda, kur ir robeža starp platformu un lietotni, tāpēc ir godīgi pateikt, kā tas izskatījās no mūsu puses.

Mūsu serveri strādā uz CloudLinux, un tajos ir iebūvēts Imunify360. Kad uzbrukuma paraugs sāka cirkulēt publiski, CloudLinux savā statusa lapā fiksēja, ka ugunsmūra noteikumu kopa, kas bloķē zināmo izmantošanas paraugu, ir izplatīta plkst. 9.08 pēc UTC — vairākas stundas pirms PHP izlaida pašu labojumu plkst. 14.00, un pirms tam, kad tajā pašā lapā parādījās ieraksts, ka mēģinājumi jau tiek novēroti. Dienas gaitā sekoja vēl divi papildinājumi, no kuriem otrais bloķē jau publiski pieejamo izmantošanas rīku. Tas viss notika automātiski, bez klienta līdzdalības. Nozarē šādu pasākumu sauc par virtual patching: ugunsmūra noteikums bloķē ievainojamības izmantošanu, nemainot pašu ievainojamo kodu.

Un tagad tas, ko šāds teikums nenozīmē, jo tieši šajā vietā nozarē šonedēļ tika pārdots visvairāk pārspīlējumu. Ugunsmūra noteikums bloķē zināmus uzbrukuma paraugus — to pašu vārdu lieto arī CloudLinux. Tā pati lapa šo pasākumu nosauc par pagaidu risinājumu, nevis pilnīgu labojumu. Tā nav neievainojamība, un pats CloudLinux turpina ieteikt atjaunināt PHP, tiklīdz pakotnes ir pieejamas. Starpība starp «aizsargāts» un «salabots» šonedēļ ir pavisam konkrēta, un pārdot vienu kā otru būtu negodīgi.

Kā izskatās pats labojums, ir laba ilustrācija tam, par ko brīdinājām iepriekš. Mūsu serveri jaunu ea-php84 būvējumu saņēma tās pašas dienas vakarā, dažas stundas pēc PHP laidiena. Versijas numurs nemainījās — php -v joprojām raksta 8.4.26, nevis 8.4.27, un vienīgais, kas no ārpuses liecina par izmaiņām, ir būvējuma datums, kas pārlēca no 9. uz 21. oktobri. Tieši tā izskatās pārnests labojums, un tieši tāpēc jautājums hostinga sniedzējam ir derīgāks par skaitli, ko rāda ekrāns.

Tāpēc vērtība, ko šeit nopirka pārvaldīts hostings, nav neievainojamība, bet sašaurināta sprauga: stundas, kurās uzbrukuma paraugs jau cirkulēja un mēģinājumi jau notika, tika nosegtas ar zināmo paraugu bloķēšanu, nevis nogaidītas. Un pēc tam — ka kāds seko līdzi pakotnēm un pārstartē procesus, nevis gaida, kad klients pamanīs. Mūsu pārvaldītais hostings sākas no €45 mēnesī, un tieši šāda veida nedēļas ir tas, par ko šajā summā maksā.

Ja Jūsu vietne šobrīd strādā kaut kur, kur uz jautājumu par PHP versiju un atjauninājuma datumu atbildi saņemt neizdodas, tas pats par sevi ir atbilde. Pārrunāsim pārcelšanu — migrāciju parasti var izdarīt bez dīkstāves.

Pēc atjaunināšanas jāpārstartē vairāk, nekā šķiet

Process, kas paliek dzīvs starp pieprasījumiem, nav nekāda eksotika — tieši tā strādā parasts PHP-FPM baseins un mod_php, un tieši pret tiem koda izpilde ir apstiprināta. Tāpēc CVE-2026-109619 nav kaut kāds īpašu konfigurāciju drauds; tā ir parastās konfigurācijas problēma.

No tā izriet solis, ko visbiežāk izlaiž: pakotnes nomaiņa neietekmē procesu, kas jau strādā. Pēc atjaunināšanas ir jāpārstartē katrs process, kas izpilda PHP, un tas attiecas arī uz tiem, kurus neviens parasti neaiztiek. Ilgi strādājoši PHP procesi mēdz nepārstartēties nedēļām, tāpēc pēc atjaunināšanas ir vērts tos uzskaitīt atsevišķi un pārliecināties, ka katrs no tiem ir pacelts no jauna.

Pareizais pārbaudes jautājums tāpēc nav «ko rāda php -v», bet «vai katrs process, kas izpilda PHP, ir startēts pēc tam, kad pakotne tika nomainīta».

Kāpēc nepietiek ar «mēs taču neko neaugšupielādējam»

Izplatīts iebildums skan apmēram tā: mūsu vietne ir vizītkarte, tajā nav ne augšupielādes formas, ne lietotāju kontu, tātad šis uz mums neattiecas. Diemžēl attiecas, un iemesls ir tieši tas, kas aprakstīts iepriekš: uzbrukumam nav vajadzīgs augšupielādēts fails, pietiek ar attiecīgi sagatavotu multipart pieprasījumu, un to var nosūtīt jebkurai adresei, kas atbild ar PHP. Formas esamība lapā nav priekšnosacījums, jo uzbrucējs formu neaizpilda.

Tāpat nav nozīmes tam, vai vietne ir maza. Uzbrukumi šādām ievainojamībām notiek plašā tīklā un automātiski, un atlasi pēc apmeklētāju skaita neviens neveic. Palo Alto Networks vienība Unit 42 publiskošanas dienā ziņoja par vairāk nekā 22,6 miljoniem internetā sasniedzamu PHP instanču, kas potenciāli ir skartas; neviena no tām nav izvēlēta īpaši.

Otrs iebildums ir par WordPress un spraudņiem. Arī tas šoreiz neder, tikai pretējā virzienā: ievainojamība ir pašā PHP, nevis WordPress, Laravel vai kādā spraudnī. Tas nozīmē, ka spraudņu atjaunināšana šo problēmu neatrisina, un vienlaikus — ka skarta ir katra PHP vietne neatkarīgi no tā, uz kā tā ir būvēta.

Ko no šīs nedēļas ir vērts paturēt

Tiem, kam viss bija kārtībā, par labu nostrādāja nevis ātra reakcija, bet trīs lietas, kas bija sakārtotas agrāk: bija zināms, kura vietne uz kuras PHP versijas strādā, bija zināms, kurš atbild par atjaunināšanu, un bija dublējumkopijas, no kurām tiešām ir pārbaudīts, ka vietni var atjaunot. Nevienu no tām nevar izdarīt tajā dienā, kad brīdinājums jau ir publicēts, un tieši tāpēc šī nedēļa vienām komandām bija pusstunda darba, bet citām — divas dienas.

Ja no šīs nedēļas jāpaņem viens uzdevums, lai nākamreiz būtu vieglāk, tad tas ir saraksts: katra vietne, tās PHP versija, veids, kā tā tiek izpildīta, tās hostinga sniedzējs un cilvēks, kurš drīkst nospiest «atjaunināt». Nākamais šāds brīdinājums pienāks, un vienīgais jautājums ir, cik ilgi tad vajadzēs, lai atbildētu uz jautājumu «vai mūs tas skar».