PHP2Shell: kritinis PHP pažeidžiamumas — ar Jūsų svetainei gresia pavojus?

Paveiktos yra visos PHP versijos, kurios savo šakoje yra senesnės už 8.5.12, 8.4.27, 8.3.36 ir 8.2.35, ir tai reiškia beveik kiekvieną PHP interneto svetainę, kurią šią savaitę niekas neatnaujino. Šiandien pirmas darbas yra išsiaiškinti, kuri versija aptarnauja Jūsų svetainę, ir ją atnaujinti — visiško apėjimo nėra, ir pats PHP pranešimas sako, kad atnaujinimas yra vienintelis saugus pasirinkimas.

Trečiadienį, spalio 21 dieną, PHP komanda vienu metu išleido keturias neeilines versijas. Pažeidžiamumų pora, kurią jos taiso, gavo pavadinimą PHP2Shell, ir jis rezultatą apibūdina tiksliai: nuo tinklo užklausos iki kodo vykdymo serveryje. Šis straipsnis yra apie tai, kas būtent rasta, kaip suprasti, ar tai liečia Jus, ir kokia tvarka veikti — taip pat ir tada, kai atnaujinti iš karto negalite.

Kas yra PHP2Shell ir kas įvyko spalio 21 dieną

Oficialiame pranešime pasakyta, kad 8.5.12, 8.4.27, 8.3.36 ir 8.2.35 ištaiso du kritinius pažeidžiamumus, kurie gali leisti neautentifikuotam užpuolikui nuotolinį kodo vykdymą (RCE), ir kad visiems PHP naudotojams griežtai rekomenduojama atsinaujinti nedelsiant. Ten pat yra ir sakinys, kuris nulemia visą kitą šio straipsnio turinį: visiško apėjimo nėra, ir atnaujinimas yra vienintelis saugus pasirinkimas.

Abiejų pažeidžiamumų PHP skyrė CVSS v4.0 įvertinimą 9.2 iš 10, tačiau tai dvi atskiros klaidos su skirtingu mechanizmu ir, kaip pamatysite toliau, taip pat su skirtingu patvirtinimo laipsniu — ir būtent šis antrasis skirtumas praktiškai nulemia, nuo kurio serverio pradėti.

CVE-2026-109618 — sugadinta atmintis po out-of-memory (OOM): kai PHP pritrūksta atminties, jis naudoja longjmp(), kad nutrauktų užklausos apdorojimą. Oficialus aprašymas nurodo, kad kai kuriais momentais užklausos atmintis yra pasiekiama anksčiau, nei ji visiškai inicializuota; jei būtent tada atminties skyrimas nepavyksta, nutraukimas apdorojamas neteisingai ir lieka negaliojanti atmintis, kurią užklausos pabaigos kodas vis dar nuskaito arba pagal kurią priima sprendimą.

Svarbi detalė, kuri keičia tai, kam ši grėsmė taikoma: out-of-memory būsena pasiekiama specialiai parengta multipart užklausa, ir joje nebūtinas joks įkeltas failas. Oficialus aprašymas mini kelias multipart apdorojimo problemas — užklausą be panaudojamo deklaruoto ilgio, dalį su neribotu antraščių skaičiumi, tuščius failų laukus, kurie neįskaičiuojami į ribas. Tai reiškia, kad užklausa gali būti visai nedidelė ir tilpti į įprastas post_max_size ir memory_limit ribas.

CVE-2026-109619 — pasenusi globalioji būsena: PHP procese tarp užklausų išlieka globali būsena: klaidų, seansų, objektų ir plėtinių duomenys. Oficialus aprašymas sako, kad ši būsena turi būti atstatyta prieš tai, kai užklausos atmintis yra atlaisvinama. Jei atstatymą nutraukia fatali klaida arba jei pabaigos metu diagnostika ją užpildo iš naujo, atmintis atlaisvinama, bet rodyklė į ją lieka; šią klaidų klasę tarptautiniu mastu vadina use-after-free.

Toliau yra sąlyga, kuri šį pažeidžiamumą padaro sunkesnį, nei skamba: pasenusią rodyklę galima panaudoti tik veiksmu, kuris vyksta prieš įprastą užklausos inicializavimą, ir oficialus aprašymas įvardija du patvirtintus tokius atvejus — INI diagnostiką ir seanso įkėlimo eigos apdorojimą. Be to, vėlesnė užpuoliko užklausa turi patekti būtent į tą patį procesą, kuriame atsirado sugadinta būsena, todėl atskiras bandymas pavyksta retai, ir aprašymas tiesiogiai nurodo, kad keli procesai bei jų keitimas tikimybę sumažina, bet pačios sąlygos nepanaikina.

Kaip lengva tai išnaudoti ir prieš ką tai patvirtinta

Čia verta būti tiksliems, nes būtent šioje vietoje dauguma straipsnių internete perdeda į vieną arba į kitą pusę.

Slaptažodžio nereikia, ir nereikia, kad kas nors svetainėje ką nors paspaustų — CVSS vektoriuje tai matyti kaip PR:N ir UI:N. Tame pačiame vektoriuje vis dėlto yra AC:H ir AT:P: atakos sudėtingumas įvertintas kaip aukštas, ir jai yra papildomų prielaidų. Praktiškai tai reiškia pakartotinius bandymus, o sėkmė priklauso nuo PHP darinio, plėtinių, priekinės dalies elgsenos ir atminties išdėstymo. Taigi ne — vienos paprastos užklausos nepakanka, bet užpuolikui tai taip pat nieko nekainuoja, nes bandymų skaičiaus niekas neriboja.

Įrodymo laipsnis abiem klaidoms skiriasi, ir šis skirtumas svarbus renkantis, kiek skubėti. CVE-2026-109618 atveju visiškas nuotolinis kodo vykdymas yra patvirtintas prieš mod_php su numatytosiomis įvesties ir atminties ribomis; apie PHP-FPM tas pats aprašymas sako, kad pirminio kodo analizė jį laiko pažeidžiamu, bet visiška PHP-FPM ataka nėra pademonstruota. FrankenPHP ten minimas kaip mod_php analogas, o LSAPI — kaip PHP-FPM analogas, abiem atvejais be patikrintos atakos.

CVE-2026-109619 atveju seanso gyvavimo ciklo kelias patikrintas ir prieš mod_php, ir prieš PHP-FPM, o antrasis kelias, einantis per fatalios klaidos pėdsaką, patvirtintas tik prieš mod_php.

Iš to išplaukia praktinė seka: jei Jūsų svetainė veikia ant mod_php, Jūs esate pirmoje eilėje, nes būtent ten abi klaidos patvirtintos. PHP-FPM ir LiteSpeed atveju rizika yra tikra, bet kol kas patvirtinta tik iš dalies; nė vienu iš šių atvejų tai nėra priežastis laukti — tai priežastis žinoti, nuo kurio serverio pradėti.

Kaip ši savaitė atrodė valandomis

Chronologija nėra kuriozas — ji paaiškina, kodėl rekomendacijos pirmosiomis valandomis skyrėsi nuo tų, kurios galioja dabar, ir kodėl dalis straipsnių internete tebėra pasenę.

Spalio 20 dienos vakare buvo žinoma, kad kažkas artėja, bet nebuvo žinoma, kas būtent: PHP buvo paskelbęs apie būsimą neeilinį leidimą, ir CloudLinux būsenos puslapis tą patį vakarą užfiksuoja, kad techninius duomenis ir paveiktas versijas planuojama paskelbti kitos dienos leidimo metu; techninis aprašymas tuo metu dar nebuvo viešas.

Iki kitos dienos padėtis buvo pasikeitusi, ir ne į gerąją pusę: spalio 21 dienos rytą CloudLinux užfiksuoja, kad viešojoje apyvartoje jau yra atakos pavyzdys, ir 9.08 UTC išplatina žiniatinklio programų ugniasienės (WAF) taisyklių rinkinį, kuris blokuoja žinomą išnaudojimo užklausos pavyzdį. Aštuoniolika minučių vėliau tame pačiame puslapyje pasirodo sakinys, kuris šią savaitę apibūdina geriausiai — šį pavyzdį atitinkantys bandymai jau stebimi, taigi kažkas jau ieškojo serverių, kuriems pataisos dar nėra.

PHP pataisos išėjo 14.00 UTC, o tai reiškia, kad tarp viešai prieinamo atakos pavyzdžio ir viešai prieinamos pataisos praėjo kelios valandos, ir per tas valandas atakos bandymai jau vyko.

Vieną išlygą čia sąžininga pasakyti: pasaulis nebuvo visiškai be pataisos, nes PHP pranešime pasakyta, kad Linux distribucijos ir ilgalaikio palaikymo tiekėjai pataisas gavo iš anksto, todėl daliai serverių atnaujinimas buvo prieinamas anksčiau nei kitiems — viešai prieinamas jis vis dėlto nebuvo niekam.

Paskui prasidėjo ilgesnioji dalis, kuri tebesitęsia: paketų platinimas; operacinių sistemų prižiūrėtojai ir talpinimo platformos savo paketus stato atskirai, ir jie pasirodo per valandas arba dienas, kiekviena savo tempu. Būtent šiame etape yra didelė dalis talpinimo naudotojų, ir būtent todėl klausimas „ar pataisa jau išleista“ ir klausimas „ar pataisa jau yra mano serveryje“ šią savaitę yra du skirtingi klausimai su skirtingais atsakymais.

Ar Jūsų svetainei gresia pavojus

Oficialiuose įspėjimuose paveiktų versijų intervalai užrašyti taip: viskas, kas seniau už 8.2.35, viskas, kas seniau už 8.3.36, viskas, kas seniau už 8.4.27, ir viskas, kas seniau už 8.5.12 — kiekviena savo šakoje.

Svarbi detalė, kuri leidžia suklysti: skaičius, kurį rodo php -v, ne visada pasako viską. Linux distribucijos ir talpinimo platformos dažnai perkelia pataisą į senesnę versiją, nekeisdamos jos numerio — keičiasi tik paketo leidimo numeris. Tokiu atveju 8.4.26 jau gali būti pataisyta, bet gali ir nebūti; vienintelis būdas tai žinoti yra pažiūrėti paketo apraše arba paklausti tiekėjo; pats versijos numeris į šį klausimą neatsako.

Atskirai apie senesnes versijas: PHP 8.1 ir senesnės iš PHP projekto reguliarių atnaujinimų nebegauna, tačiau, atsižvelgiant į rimtumą, saugumo komanda parengė minimalias pirminio kodo pataisas versijoms 7.4, 8.0 ir 8.1 — tiems, kurie stato iš pirminio kodo arba neturi prieigos prie prižiūrėtojo palaikymo. Pranešimas ten pat rekomenduoja susisiekti su savo tiekėju, nes dalis distribucijų ir ilgalaikio palaikymo tiekėjų pataisas perkelia. Jei Jūsų svetainė veikia ant PHP 7.x, tikroji problema nėra ši savaitė — tikroji problema yra ta, kad kitą kartą pataisos gali ir nebūti. O PHP 8.2, kuris šį kartą pataisą gavo, palaikymo netenka 2026 metų gruodžio 31 dieną, kai ši versija pasiekia end of life.

Kaip patikrinti versiją pagal tai, kur svetainė veikia

Patikra užtrunka minutes, ir ją verta atlikti kiekvienai svetainei atskirai, ne kiekvienam serveriui: viename serveryje dažnai veikia svetainės su skirtingomis PHP versijomis, ir paprastai būtent ta seniausia, kurią visi yra pamiršę, yra viešai pasiekiama.

Talpinimas su cPanel: versiją rodo skiltis MultiPHP Manager, kurioje kiekvienas domenas turi savo eilutę; Plesk tam pačiam dalykui naudoja PHP Settings kiekvienos prenumeratos viduje. Abiem atvejais verta įsitikinti, kad žiūrite į tą domeną, apie kurį kalbama, o ne į serverio numatytąjį.

Savo serveris arba VPS: komandinėje eilutėje tai rodo php -v, bet su viena esmine išlyga: komandinės eilutės PHP dažnai yra visai kita versija nei ta, kuri aptarnauja žiniatinklio užklausas. Patikimiausią atsakymą duoda tas pats kelias, kuriuo veikia svetainė — PHP-FPM konfigūracijos pool skiltyje nurodytas vykdomasis failas.

Konteineriai. Jei svetainė veikia Docker aplinkoje, versiją lemia atvaizdas, ne pagrindinis kompiuteris, todėl yra du žingsniai: surinkti atvaizdą iš naujo su atnaujintu baziniu atvaizdu ir po to paleisti konteinerius iš naujo. Atvaizdas, surinktas iki spalio 21 dienos, pataisos neturi, kad ir kaip dažnai konteineris buvo paleistas iš naujo.

Jei prieigos nėra nė prie vieno iš šių: tada klausimas yra hostingo teikėjui, ir šią savaitę tai visiškai normalus klausimas, į kurį atsakymą jie jau yra parengę. Formuluotė, kuri sutaupo susirašinėjimą: „Kuri PHP versija aptarnauja mano domeną, ar joje yra PHP2Shell pataisa, ir jei dar nėra, kurią dieną ji bus?“

Ką daryti šiandien

Šiandienos seka yra tokia: pirmiausia atnaujinti PHP ir paleisti iš naujo viską, kas jį vykdo, tada įsitikinti, kad lankytojus tikrai aptarnauja naujoji versija, paskui patikrinti, ar naudojama paketų saugykla pataisą apskritai yra išleidusi, ir tik po to ieškoti pėdsakų. Pirmas žingsnis užtrunka minutes, paskutinis gali užtrukti dienas, ir būtent todėl jų neverta supainioti vietomis.

Pirmiausia, atnaujinkite. Profesionalaus hostingo atveju tai padaro teikėjas, o Jūsų darbas yra užduoti klausimą ir gauti datą. Jei serverį administruojate patys, po paketų atnaujinimo reikia paleisti iš naujo tai, kas vykdo PHP: Apache, PHP-FPM arba LSAPI. Šis žingsnis praleidžiamas stebėtinai dažnai — paketas jau pakeistas, bet seni procesai toliau dirba su senu kodu, todėl patikra rodo naująją versiją, kol lankytojus aptarnauja senoji.

Antra, patikrinkite, kad atnaujinimas tikrai pritaikytas — tuo pačiu keliu, kuriuo veikia svetainė, o ne per komandinę eilutę.

Trečia, jei naudojate savanoriškai prižiūrimą paketų saugyklą, patikrinkite, ar ji pataisą yra išleidusi. PHP pranešime yra atskiras įspėjimas apie rpms.remirepo.net: jos naudotojams rekomenduojama pereiti prie distribucijos paketų arba statyti iš pirminio kodo.

Ketvirta, tik po to patikrinkite, ar svetainėje nėra pėdsakų; atnaujinimas uždaro duris, bet neatsako į klausimą, ar pro jas kas nors jau yra įėjęs.

Jei atnaujinti iš karto negalite

Šį skyrių verta skaityti aiškiai suvokiant, kad nė vienas iš čia minimų žingsnių nepakeičia atnaujinimo — PHP pranešimas tai sako tiesiai.

Prieš CVE-2026-109618 pranešimas mini atminties ribos panaikinimą: memory_limit=-1, ir dar taip, kad programa negalėtų jo perrašyti — pavyzdžiui, su php_admin_value PHP-FPM arba Apache konfigūracijoje, įsitikinus, kad jokia kita nuostata galutinės ribos negrąžina atgal. Reikia suprasti, kiek šis pasirinkimas kainuoja: bendrame serveryje jis iškeičia vieną riziką į kitą, nes viena užklausa dabar gali suvalgyti visą prieinamą atmintį. Pažeidžiamumo apraše yra ir įspėjimas nenaudoti RLIMIT_AS ir RLIMIT_DATA, nes jie gali priversti atminties skyrimą nepavykti ir taip nuvesti tiesiai į pažeidžiamą kelią.

Prieš CVE-2026-109619 pranešimas mini session.upload_progress.enabled=0 ir, PHP 8.5 atveju, fatal_error_backtraces=0 — abiem atvejais su nurodymu po to paleisti visus procesus iš naujo. Pačiame pažeidžiamumo apraše yra ir pm.max_requests=1, kuris liepia PHP-FPM po kiekvienos užklausos pakeisti PHP-FPM worker; tai yra PHP-FPM pool nuostata, ir ten ji paminėta su išlyga „jei našumas nėra veiksnys“. Ten pat pasakyta ir tai, kas šią priemonę išlaiko tikrose ribose: procesų keitimas sumažina tikimybę vienai užklausai, bet pačios sąlygos nepanaikina.

Naudinga ir tai, kas nėra apėjimas, bet sumažina atakos paviršių: konservatyvus post_max_size, protingas įvesties įdėtumo gylis ir ribotas įkėlimo dydis; tai geros reikšmės bet kurią savaitę, ne tik šią.

Kaip suprasti, ar Jūs jau esate paveikti

Po atnaujinimo verta peržiūrėti žiniatinklio serverio žurnalus už paskutines dienas: ieškotinas yra neįprastai didelis multipart užklausų skaičius į vieną ir tą patį adresą — ir čia lengva ieškoti neteisingai: jos dažnai būna nedidelės ir telpa į įprastas ribas, todėl pagal dydį jų nerasite. Iškalbingesnės yra staigios 500 klaidų sekos, kurios prasideda ir baigiasi be matomos priežasties: ataka, kuri remiasi tuo, kad PHP pritrūksta atminties, nepavyksta daug dažniau, nei pavyksta, ir kiekvienas nepavykęs bandymas palieka klaidą.

Failų sistemoje svarbūs yra keitimo laikai: PHP failas, pakeistas naktį, kai niekas nedirbo, turi būti paaiškintas. Verta patikrinti ir suplanuotas užduotis bei įrašus, kurie užtikrina automatinį paleidimą po paleidimo iš naujo — užpuolikui, kuris jau vykdo kodą, pirmas darbas yra įsitvirtinti, kad prieiga išgyventų būtent tą atnaujinimą, kurį ką tik įdiegėte.

Atskirai verta patikrinti administratorių paskyrų sąrašą ir programų slaptažodžius bei raktus; jei kodo vykdymas įvyko, tada viską, ką serveris žino, reikia laikyti perskaitytu — taip pat duomenų bazės prisijungimo duomenis ir API raktus konfigūracijos faile.

Jei kas nors iš to neatrodys teisingai, valymas yra atskiras darbas su sava seka, ir jį verta daryti metodiškai, o ne trinant įtartinus failus po vieną. Tai esame aprašę atskirai — kaip vyksta nulaužtos svetainės atkūrimas, ir jei norite, kad tai padarytų kas nors kitas, nulaužtos svetainės atkūrimas yra atskira paslauga su fiksuota seka: izoliacija, išvalymas, priežasties pašalinimas ir patikra, kad svetainė pašalinta iš paieškos sistemų įspėjimų sąrašų.

Kada įvykis tampa praneštinu incidentu

Jei yra pagrindo manyti, kad užpuolikas pasiekė asmens duomenis, techninis klausimas tampa ir teisiniu. Bendrasis duomenų apsaugos reglamentas numato terminą, kuris prasideda ne nuo atakos, o nuo momento, kai duomenų valdytojas sužinojo apie asmens duomenų saugumo pažeidimą: kai įmanoma, ne vėliau kaip per 72 valandas pranešimui priežiūros institucijai. Pareiga nekyla tada, kai mažai tikėtina, kad pažeidimas kels riziką fizinių asmenų teisėms ir laisvėms, o jei rizika yra didelė, informuotini ir patys asmenys — šiai pareigai reglamentas taip pat numato išimtis.

Praktinė šio skyriaus reikšmė yra viena: momentas, kai žurnaluose rasta kažkas įtartino, nėra momentas, kai pradeda eiti 72 valandos — tai momentas, kai reikia išsiaiškinti, ar pažeidimas apskritai įvyko. Atskira 500 klaidų seka, kuri, kaip aprašyta anksčiau, dažniausiai yra nepavykęs bandymas, pati savaime nėra pažeidimas. Bet būtent todėl šio aiškinimosi neverta atidėti „kai bus mažiau darbo“, ir būtent todėl žurnalus reikia išsaugoti, kol rotacija jų neperrašo: jie yra vienintelis įrodymas ir to, kas įvyko, ir to, kas neįvyko.

Jei Jūsų žinioje yra kelios svetainės

Agentūroms ir įmonėms su keliomis svetainėmis ši savaitė yra ne tiek techninė, kiek organizacinė užduotis, ir seka, kuri veikia, yra paprasta: pirmiausia sąrašas, tada versijos, tada atnaujinimas prioriteto tvarka.

Prioritetą lemia ne svetainės svarba, o pasiekiamumas ir tai, kas ją aptarnauja. Viršuje yra viešai pasiekiamos svetainės ant mod_php, nes būtent ten abu pažeidžiamumai patvirtinti; tada visa kita vieša, ir tik po to vidinės sistemos už ugniasienės. Testavimo ir kūrimo aplinkos, kurias visi pamiršta, į sąrašą turi patekti būtinai — jos dažnai veikia senesne PHP versija ir dažnai yra pasiekiamos iš interneto, nes kadaise taip buvo patogiau.

Svetainės, kurias prižiūri kas nors kitas, sąraše lieka, bet su kitu stulpeliu: kam išsiųstas klausimas ir kurią dieną gautas atsakymas. Šis stulpelis vėliau pasirodo vertingesnis už kitus, nes būtent jis parodo, kuris teikėjas reaguoja ir kuris ne.

Ką šiuo atveju reiškė profesionalus hostingas

Ši savaitė gerai parodo, kur yra riba tarp platformos ir programos, todėl sąžininga pasakyti, kaip tai atrodė iš mūsų pusės.

Mūsų serveriai veikia ant CloudLinux, ir juose įdiegtas Imunify360. Kai atakos pavyzdys pradėjo cirkuliuoti viešai, CloudLinux savo būsenos puslapyje užfiksavo, kad ugniasienės taisyklių rinkinys, kuris blokuoja žinomą išnaudojimo pavyzdį, išplatintas 9.08 UTC — kelios valandos prieš PHP išleidžiant pačią pataisą 14.00, ir prieš tai, kai tame pačiame puslapyje pasirodė įrašas, kad bandymai jau stebimi. Dienos eigoje sekė dar du papildymai, iš kurių antrasis blokuoja jau viešai prieinamą išnaudojimo įrankį. Visa tai įvyko automatiškai, be kliento dalyvavimo; sektoriuje tokią priemonę vadina virtual patching: žiniatinklio programų ugniasienės (WAF) taisyklė blokuoja pažeidžiamumo išnaudojimą, nekeisdama paties pažeidžiamo kodo.

Ir dabar tai, ko toks sakinys nereiškia, nes būtent šioje vietoje sektoriuje šią savaitę buvo parduota daugiausia perdėjimų. Ugniasienės taisyklė blokuoja žinomus atakos pavyzdžius — tą patį žodį vartoja ir CloudLinux. Tas pats puslapis šią priemonę vadina laikinu sprendimu, o ne visiška pataisa; tai nėra nepažeidžiamumas, ir pats CloudLinux toliau rekomenduoja atnaujinti PHP, kai tik paketai yra prieinami. Skirtumas tarp „apsaugota“ ir „pataisyta“ šią savaitę yra visiškai konkretus, ir parduoti vieną kaip kitą būtų nesąžininga.

Kaip atrodo pati pataisa, yra gera iliustracija to, apie ką įspėjome anksčiau. Mūsų serveriai naują ea-php84 darinį gavo tos pačios dienos vakare, praėjus kelioms valandoms po PHP leidimo. Versijos numeris nepasikeitė — php -v vis dar rašo 8.4.26, o ne 8.4.27, ir vienintelis dalykas, kuris iš išorės rodo pokytį, yra darinio data, peršokusi nuo spalio 9-osios iki spalio 21-osios. Būtent taip atrodo perkelta pataisa, ir būtent todėl klausimas hostingo teikėjui yra naudingesnis už skaičių, kurį rodo ekranas.

Todėl vertė, kurią čia nupirko profesionalus hostingas, yra ne nepažeidžiamumas, o susiaurintas tarpas: valandos, kuriomis atakos pavyzdys jau cirkuliavo ir bandymai jau vyko, buvo uždengtos žinomų pavyzdžių blokavimu, o ne išlauktos. Ir po to — kad kažkas seka paketus ir paleidžia procesus iš naujo, o ne laukia, kol klientas pastebės. Mūsų profesionalus hostingas prasideda nuo 45 € per mėnesį, ir būtent tokios savaitės yra tai, už ką šioje sumoje mokama.

Jei Jūsų svetainė šiuo metu veikia ten, kur atsakymo į klausimą apie PHP versiją ir atnaujinimo datą gauti nepavyksta, tai jau savaime yra atsakymas. Aptarkime perkėlimą — migraciją paprastai galima atlikti be prastovos.

Po atnaujinimo reikia paleisti iš naujo daugiau, nei atrodo

Procesas, kuris lieka gyvas tarp užklausų, nėra jokia egzotika — būtent taip veikia įprastas PHP-FPM pool ir mod_php, ir būtent prieš juos kodo vykdymas yra patvirtintas. Todėl CVE-2026-109619 nėra kažkokia ypatingų konfigūracijų grėsmė; tai įprastos konfigūracijos problema.

Iš to išplaukia žingsnis, kurį praleidžia dažniausiai: paketo pakeitimas nepaveikia proceso, kuris jau veikia. Po atnaujinimo reikia paleisti iš naujo kiekvieną procesą, kuris vykdo PHP, ir tai liečia ir tuos, kurių paprastai niekas neliečia. Ilgai veikiantys PHP procesai dažnai nepaleidžiami iš naujo savaitėmis, todėl po atnaujinimo verta juos išvardyti atskirai ir įsitikinti, kad kiekvienas iš jų paleistas iš naujo.

Teisingas tikrinimo klausimas todėl yra ne „ką rodo php -v“, o „ar kiekvienas procesas, kuris vykdo PHP, paleistas po to, kai paketas buvo pakeistas“.

Kodėl nepakanka sakyti „mes juk nieko neįkeliame“

Dažnas prieštaravimas skamba maždaug taip: mūsų svetainė yra reprezentacinė, joje nėra nei įkėlimo formos, nei naudotojų paskyrų, taigi tai mums netaikoma. Deja, taikoma, ir priežastis yra būtent ta, kuri aprašyta anksčiau: atakai nereikia įkelto failo, pakanka atitinkamai parengtos multipart užklausos, ir ją galima nusiųsti bet kuriam adresui, kuris atsako PHP. Formos buvimas puslapyje nėra prielaida, nes užpuolikas formos nepildo.

Taip pat nesvarbu, ar svetainė maža: atakos prieš tokius pažeidžiamumus vyksta plačiame tinkle ir automatiškai, ir atrankos pagal lankytojų skaičių niekas nedaro. Palo Alto Networks padalinys Unit 42 paskelbimo dieną pranešė apie daugiau kaip 22,6 milijono internetu pasiekiamų PHP instancijų, kurios potencialiai yra paveiktos; nė viena iš jų nėra pasirinkta specialiai.

Antrasis prieštaravimas yra apie WordPress ir įskiepius, ir jis šį kartą netinka, tik priešinga kryptimi: pažeidžiamumas yra pačiame PHP, ne WordPress, Laravel ar kokiame nors įskiepyje. Tai reiškia, kad įskiepių atnaujinimas šios problemos neišsprendžia, ir kartu — kad paveikta yra kiekviena PHP svetainė, nesvarbu, ant ko ji pastatyta.

Ką iš šios savaitės verta pasilikti

Tiems, kuriems viskas buvo tvarkoje, gerai suveikė ne greita reakcija, o trys dalykai, kurie buvo sutvarkyti anksčiau: buvo žinoma, kuri svetainė kuria PHP versija veikia, buvo žinoma, kas atsako už atnaujinimą, ir buvo atsarginės kopijos, iš kurių tikrai patikrinta, kad svetainę galima atkurti. Nė vieno iš jų negalima padaryti tą dieną, kai įspėjimas jau paskelbtas, ir būtent todėl ši savaitė vienoms komandoms buvo pusvalandis darbo, o kitoms — dvi dienos.

Jei iš šios savaitės reikia paimti vieną užduotį, kad kitą kartą būtų lengviau, tai yra sąrašas: kiekviena svetainė, jos PHP versija, būdas, kuriuo ji vykdoma, jos hostingo teikėjas ir žmogus, kuriam leidžiama paspausti „atnaujinti“. Kitas toks įspėjimas ateis, ir vienintelis klausimas yra, kiek tada reikės, kad būtų atsakyta į klausimą „ar tai mus liečia“.