Kritinės PHP spragos: kodėl svarbu nedelsti su serverio atnaujinimu?

2026 22 spalio

„PHP2Shell“ – aptiktos dvi kritinės PHP saugumo spragos, kurių pataisymai išleisti 2026 m. spalio 21 d.

„PHP2Shell“ spragos aktualios PHP technologiją naudojančioms interneto svetainėms ir elektroninėms parduotuvėms. Sėkmingai jas išnaudoję užpuolikai gali be prisijungimo duomenų vykdyti kenkėjišką kodą serveryje – tokiomis teisėmis, kokias turi PHP užklausas apdorojantis procesas. Tai gali sudaryti sąlygas pasiekti svetainės duomenis, pakeisti turinį ar įdiegti kenkėjišką kodą, tačiau savaime nereiškia neribotos viso serverio administratoriaus kontrolės. Pažeidžiamos PHP versijos naudojimas taip pat nėra įrodymas, kad į svetainę jau įsilaužta, tačiau saugumo pataisų diegimo atidėlioti nereikėtų. 

Ką apie tai žinome 2026 m. spalio 22 d.?

1. Kas įvyko?

Paviešintos dvi PHP branduolio spragos – CVE-2026-109618 ir CVE-2026-109619. Abi įvertintos 9,2 balo iš 10 pagal CVSS v4.0. Sėkmingai jas išnaudojęs užpuolikas tam tikromis sąlygomis gali nuotoliniu būdu vykdyti kodą, neturėdamas prisijungimo duomenų.

Paprastai paaiškinus:

Spraga	Kas vyksta?
CVE-2026-109618	PHP netinkamai sutvarko tam tikras atminties trūkumo situacijas. Dėl to vidiniai, nevisiškai paruošti duomenys gali būti panaudoti kaip tinkami, sudarant sąlygas kenkėjiško kodo vykdymui.
CVE-2026-109619	Tarp užklausų gali išlikti nuorodos į jau atlaisvintą atmintį. Vėlesnė užklausa gali priversti PHP pasinaudoti šia nebegaliojančia būsena.

2. Kam tai aktualu ir kodėl naujiena nuskambėjo pasaulyje?

Tai ne vien „WordPress“ ir ne vien konkretaus įskiepio problema. Oficialus PHP pranešimas rizikos grupei priskiria žiniatinklio užklausas aptarnaujančias PHP aplinkas, įskaitant PHP-FPM, „Apache“ su mod_php, PHP-CGI, „FrankenPHP“ ir „LiteSpeed“. Didžiausia rizika išskiriama mod_php: pademonstruotas scenarijus, kuriame ataka prasideda dar prieš paleidžiant svetainės programinį kodą. 

Tarptautinį dėmesį paaiškina keli dalykai:

• Platus galimas poveikis. PHP naudojamas ne tik svetainėse, bet ir įvairių produktų viduje. Todėl organizacija gali turėti paveiktų sistemų net tuomet, kai iš pirmo žvilgsnio jos neatrodo susijusios su PHP.
• Oficialūs raginimai veikti nedelsiant. Bendrą perspėjimą paskelbė Europos Komisija, ENISA, CERT-EU ir kitos Europos institucijos. Lietuvoje apie būtinybę skubiai diegti pataisymus informavo NKSC.
• Realūs paslaugų prieinamumo sutrikimai. AP pranešė, kad dalis organizacijų Europoje ir JAV laikinai išjungė svetaines, kol buvo atliekami saugumo atnaujinimai. Tarp pavyzdžių – iš dalies nepasiekiamos Suomijos vyriausybės svetainės. Prevencinis išjungimas nėra tas pats, kas patvirtintas įsilaužimas.

Ar spragos jau išnaudojamos?

Naujosios Zelandijos NCSC spalio 22 d. pranešime nurodo žinanti apie aktyvaus išnaudojimo pranešimus. 

3. Kokį atnaujinimą reikia įdiegti?

Spalio 21 d. išleistos šios pataisytos versijos:

Naudojama PHP šaka	Versija su šių spragų pataisomis
PHP 8.2	8.2.35
PHP 8.3	8.3.36
PHP 8.4	8.4.27
PHP 8.5	8.5.12

Reikia naudoti atitinkamos šakos versiją su pataisomis arba vėlesnį saugumo leidimą. Vadinasi, ne visiems būtina skubiai pereiti būtent į PHP 8.5 – svarbiausia įdiegti pataisytą, palaikomą leidimą. 

• Svetainėms ir elektroninėms parduotuvėms, naudojančioms PHP 8.2–8.5, pirmiausia reikia įdiegti atitinkamos šakos leidimą su saugumo pataisomis: 8.2.35, 8.3.36, 8.4.27 arba 8.5.12. Tai leidžia pašalinti šias spragas nekeičiant naudojamos PHP šakos. Vis dėlto po atnaujinimo rekomenduojame patikrinti svarbiausias svetainės funkcijas – prisijungimą, formas, užsakymų pateikimą ir atsiskaitymą.
• Naudojant PHP 8.0 ar 8.1, reikėtų planuoti perėjimą į palaikomą, su svetaine suderinamą PHP versiją. Vienas galimų variantų – PHP 8.2.35, tačiau pasirinkimą verta įvertinti individualiai: PHP 8.2 saugumo palaikymas baigsis 2026 m. gruodžio 31 d., todėl, jei sistema suderinama, tikslinga svarstyti ir naujesnę palaikomą šaką. Pereinant į kitą PHP šaką gali išryškėti programinio kodo ar naudojamų komponentų nesuderinamumų, todėl negalima iš anksto pažadėti, kad reikalingi pakeitimai bus tik smulkūs.
• Daugiau pasirengimo gali prireikti sistemoms, naudojančioms senesnes nei PHP 8 versijas. Pereinant į PHP 8 ar naujesnę šaką gali tekti koreguoti programinį kodą, atnaujinti turinio valdymo sistemą, įskiepius ar kitus komponentus. Tai nereiškia, kad kiekviena sena svetainė būtinai nustos veikti, tačiau suderinamumą svarbu patikrinti prieš keičiant veikiančią aplinką. Preliminariai tokių sistemų pritaikymas gali užtrukti nuo kelių valandų iki dienos ar ilgiau, tačiau tikslią darbų apimtį ir trukmę galima nustatyti tik įvertinus konkrečią svetainę jau darbų atlikimo metu.

Dar trys svarbūs niuansai:

• Vien „WordPress“ ar įskiepių atnaujinimo nepakanka. „WordPress“ komanda aiškiai nurodo, kad šiai problemai atskiro „WordPress“ atnaujinimo nereikia ir jis neplanuojamas – taisyti reikia serverio PHP aplinką. 
• PHP 8.1 ir senesnės šakos nebepalaikomos paties PHP projekto. Kai kurie distributoriai ir ilgalaikio palaikymo tiekėjai gali pateikti į senesnius paketus perkeltas pataisas. Išimties tvarka paskelbtos ir minimalios PHP 7.4, 8.0 bei 8.1 šaltinio kodo pataisos, tačiau tai neatkuria įprasto šių šakų palaikymo.
• WAF taisyklės ir konfigūracijos pakeitimai nėra visavertis atnaujinimo pakaitalas. Jie gali sumažinti konkrečių atakos kelių riziką, bet PHP komanda ir NKSC pabrėžia, kad visiškai pašalinti šių spragų riziką galima tik įdiegus pataisas.

4. Ar visiems reikia imtis veiksmų?

Ne. Ne visiems bendrai reikalingi papildomi atnaujinimo darbai. Daliai mūsų klientų, naudojančių bendrosios prieglobos (*shared hosting*) paslaugas, pataisas jau įdiegė teikėjai. „Hostinger“ 2026 m. spalio 22 d. oficialiai paskelbė, kad pataisos įdiegtos visose jų administruojamose prieglobos aplinkose, išskyrus VPS, kuriuose PHP prižiūri patys klientai arba jų techniniai partneriai. Svarbu žinoti, kad tiekėjas gali įdiegti pataisą nepakeisdamas rodomo PHP versijos numerio, todėl vertinti reikia ne tik numerį, bet ir tiekėjo patvirtinimą. Jei konkrečioje aplinkoje pataisos jau įdiegtos, papildomai jų diegti nereikia. 

5. Koks čia dirbtinio intelekto vaidmuo?

„OpenAI“ nurodo, kad „Calif“ tyrėjai kritinę problemą identifikavo naudodami jos modelį pagal „Patch the Planet“ iniciatyvą, o „Wiz“ abi spragas taip pat atrado ir pranešė nepriklausomai. Pataisų rengimui ir išleidimui vadovavo PHP prižiūrėtojai.

Kartu PHP Foundation paaiškina, kad pirmieji vienos problemos požymiai buvo aptikti dar 2024 m., o 2026 m. tyrimai atskleidė ir įrodė visą nuotolinio kodo vykdymo poveikį. 

6. Kas gali sutvarkyti PHP spragų problemą?

Enternet.lt komanda gali padėti. Jeigu norite, kad reikalingus PHP atnaujinimo ir svetainės pritaikymo darbus atliktume mes, kviečiame kuo anksčiau susisiekti. Įvertinsime naudojamą aplinką, suderinsime artimiausią galimą jų atlikimo laiką. Jei nesate tikri, ar jūsų svetainei pataisos jau įdiegtos, kreipkitės – padėsime išsiaiškinti, ar reikalingi papildomi veiksmai.