PHP2Shell: kritinė PHP spraga Lietuvoje. Kaip sužinoti, ar jūsų svetainė jau atnaujinta

Spalio 21 d. 16:52 Lietuvos laiku PHP projektas išleido pataisas dviem kritinėms spragoms, kurias žiniasklaida pavadino PHP2Shell. Per kitą parą Registrų centras išjungė dalį savo sistemų, NKSC paskelbė DUK, o jo vadovas Antanas Aleknavičius suskaičiavo apie šimtą pažeidžiamų Lietuvos svetainių. Jei turite svetainę ir nežinote, kas joje nutiko tą savaitę, šis tekstas skirtas jums.

Trumpas atsakymas: iš išorės, atsidarę savo svetainę naršyklėje, to nesužinosite. Spraga yra ne WordPress, ne įskiepiuose ir ne jūsų tekstuose, o pačiame PHP, kuris veikia serveryje. Atnaujina tas, kas valdo serverį: prieglobos paslaugų teikėjas arba jūsų administratorius. Žemiau surašėme, kas įvyko, kaip reagavo Lietuvos institucijos, ką parodė mūsų pačių patikra ir kaip per dešimt minučių išsiaiškinti, ar jūsų svetainė jau saugi.

Kas įvyko per keturias dienas

• Spalio 17 d. „Amazon“ grėsmių žvalgybos tarnyba vėliau nustatė, kad jos spąstų serveriuose (angl. honeypot) pirmas bandymas išnaudoti spragą buvo užfiksuotas jau šią dieną, keturiomis dienomis anksčiau, nei apie spragą paskelbta viešai.
• Spalio 20 d., vakare. PHP projekto komanda pranešė, kad kitą dieną išleis pataisas dviem kritiniams pažeidžiamumams CVE-2026-109618 ir CVE-2026-109619. Tą patį vakarą dalis techninių detalių nutekėjo į viešumą anksčiau laiko.
• Spalio 21 d., rytas. NKSC dar prieš pataisų išleidimą išplatino informaciją kibernetinio saugumo subjektams, vėliau paskelbė ją viešai. „Cloudflare“ savo tinkle įjungė laikinas užkardos taisykles.
• Spalio 21 d., 16:52. Išleistos pataisytos versijos PHP 8.5.12, 8.4.27, 8.3.36 ir 8.2.35. Registrų centras tą vakarą išjungė dalį savo sistemų ir pradėjo atnaujinimą.
• Spalio 22 d. NKSC paskelbė DUK ir įvertino situaciją kaip didelę grėsmę Lietuvos kibernetinei erdvei. Registrų centras pranešė atkuriantis paslaugas. Aleknavičius BNS sakė, kad nustatyta apie šimtą pažeidžiamų svetainių ir vyksta pakartotinis visų Lietuvos svetainių skenavimas.
• Spalio 23 d. Didieji Lietuvos prieglobos paslaugų teikėjai, NKSC duomenimis, bendrosios prieglobos klientams pataisas jau pritaikė. Lieka tie, kas turi savo serverius, ir tie, kurių PHP versija nebepalaikoma.

Ekrano kopija: php.net pranešimas, kuriame įvardytos pataisytos versijos ir rizikos grupės.

Kuo ši spraga skiriasi nuo įprastų

Dauguma įsilaužimų į Lietuvos svetaines, kuriuos matome savo darbe, prasideda nuo neatnaujinto įskiepio arba silpno slaptažodžio. Čia kitaip. Spraga yra pačiame PHP interpretatoriuje, programoje, kuri serveryje vykdo WordPress, Joomla, Drupal, PrestaShop, Moodle ir tūkstančių kitų sistemų kodą. PHP komanda rašo, kad pavojus didžiausias serveriams su Apache ir mod_php: ten parodyta ataka, kai neautentifikuota užklausa suveikia dar prieš pradedant veikti bet kokiam svetainės kodui. Kitaip tariant, jūsų svetainė gali būti atnaujinta iki paskutinio įskiepio, su stipriais slaptažodžiais ir dviejų veiksnių autentifikacija, ir vis tiek būti pažeidžiama, jei po ja veikia sena PHP versija.

NKSC vadovas tai pasakė paprasčiau: „Tas pažeidžiamumas techninis – nėra tiesiogiai svetainė pažeidžiama, tai susiję su serveriais, tomis vietomis, kur talpinamos svetainės. Išleisti atnaujinimai yra kritiniai ir juos reikėtų įsidiegti nedelsiant“, – 15min sakė A. Aleknavičius.

Techniškai tai dvi klaidos atminties valdyme. Pirmoji (CVE-2026-109618): kai užklausai pritrūksta atminties, PHP nutraukia jos apdorojimą pusiaukelėje, o vėliau tvarkydamas likučius pasitiki duomenimis, kurie niekada nebuvo iki galo paruošti. Antroji (CVE-2026-109619): vienos užklausos vidinė būsena gali išlikti po to, kai jai skirta atmintis jau atlaisvinta, ir kita to paties serverio proceso aptarnaujama užklausa ją panaudoja. Abiem atvejais rezultatas tas pats: piktavalis gali priversti serverį vykdyti jo atsiųstą kodą. PHP komanda abu pažeidžiamumus įvertino 9,2 balo iš 10 pagal CVSS v4.0, o NKSC institucijoms pranešė apie 9,5 balo grėsmės lygį.

Ekrano kopija: oficialus pranešimas PHP šaltinio kodo saugykloje. Paveiktos visos versijos iki 8.2.35, 8.3.36, 8.4.27 ir 8.5.12.

Ką tai reiškia praktiškai, BNS paaiškino Registrų centro IT direktorius Antanas Raguotis: išnaudojus pažeidžiamumą buvo galima be autorizacijos prisijungti prie sistemų, keisti ar pavogti duomenis, iš esmės perimti sistemų valdymą. Pridursime iš savo patirties: perimtas serveris retai lieka tuščias. Dažniausiai į jį įkeliamas backdoor (paslėpta prieiga), kuris veikia ir po to, kai PHP jau atnaujintas. Apie tai dar grįšime.

Kaip reagavo Lietuva

NKSC spalio 22 d. DUK pažymėjo, kad PHP naudoja apie 80 proc. Lietuvos interneto svetainių, o Aleknavičius žurnalistams kalbėjo apie 80–90 proc. „Mūsų žiniomis, tai yra labai populiari programavimo kalba ir, mūsų vertinimu, 80–90 proc. visų Lietuvos svetainių, ar tai būtų privataus verslo, ar tai būtų valstybės institucijų, remiasi būtent PHP kalba“, – sakė jis M1 informacijos tarnybai. Centras nuo spalio 20 d. renka informaciją, pirmiausia informuoja pažeidžiamų svetainių valdytojus ir skenuoja visas Lietuvos svetaines pakartotinai. Tikslios statistikos, kiek įstaigų jau susitvarkė, NKSC neturi.

Du dalykai iš NKSC DUK verti dėmesio kiekvienam svetainės savininkui. Pirma: didžioji dalis svetainių laikoma pas kelis didžiausius Lietuvos prieglobos paslaugų teikėjus, ir šie bendrosios prieglobos klientams bendrus technologinius sprendimus jau pritaikė. Antra: jei naudojama nebepalaikoma PHP versija, kuriai pataisų nėra, NKSC rekomenduoja sistemą izoliuoti nuo interneto ir planuoti migraciją į palaikomą versiją. Tai ne patarimas „kada nors“, tai rekomendacija dabar.

Ekrano kopija: NKSC DUK nksc.lt svetainėje. Šeši klausimai, įskaitant „ką daryti, jeigu nėra galimybės įdiegti reikiamos versijos atnaujinimo“.

Registrų centras pasielgė taip, kaip rekomenduoja visi pasaulio kibernetinio saugumo centrai: išjungė tai, ko negalėjo iš karto atnaujinti. „Kibernetinio saugumo srityje ypač svarbi greita ir atsakinga reakcija. Gavę informaciją apie galimas rizikas dėl tarptautinio masto pažeidžiamumo, nedelsdami ją įvertinome ir ėmėmės prevencinių veiksmų – operatyviai ėmėmės atnaujinti susijusias platformas bei sustiprinome stebėseną“, – pranešime cituojamas generalinis direktorius Vytautas Bitinas. Raguotis BNS pridūrė, kad apie spragą įmonė sužinojo ne iš NKSC, o iš gamintojo svetainės: „Mes de facto pradėjom reaguoti anksčiau ir kaupti informaciją.“ Spalio 22 d. paslaugos buvo atkuriamos, o dėl įvykio bus atliktas tyrimas.

Aleknavičius tokį elgesį pagyrė ir kartu paaiškino, kodėl neveikianti paslauga tomis dienomis buvo geras ženklas: „Tad jeigu viena kita paslauga neveiks, reiškia, šaunuoliai, ėmėsi veiksmų čia ir dabar ir tvarkosi. Kitų gal vartotojai net nepajus tų sutrikimų, tų paslaugų neveikimo, nes bus įdiegta greičiau.“ Jis neslėpė ir blogesnio scenarijaus: „Vėlgi, priklausomai nuo to, kokias svetainės turi versijas, jeigu tos naujesnės versijos, bus greičiau, o kai kam gali tekti svetaines perkurti iš naujo.“

Lietuva čia ne išimtis. Pagal užsienio žiniasklaidos pranešimus, kol laukė pataisų, Nyderlandų vyriausybės portalas Overheid.nl, Suomijos valstybės viešosios e. paslaugos ir Prancūzijos vidaus reikalų ministerijos svetainės buvo laikinai išjungtos, „Wikimedia“ fondas sustabdė dalį pagalbinių paslaugų, o Internet Archive trumpam užsidarė. Didžiosios Britanijos NCSC ir JAV NSA viešai rekomendavo neatnaujinamas sistemas atjungti nuo interneto.

Ką parodė mūsų pačių patikra

Spalio 23 d. rytą patikrinome 112 Lietuvos viešojo sektoriaus svetainių: savivaldybių, ministerijų, didžiųjų valstybės įstaigų ir universitetų pagrindinius puslapius. Tikrinome tik tai, ką mato bet kuris lankytojas: HTTP atsakymo antraštes ir pirmo puslapio kodą, be jokių užklausų į sistemų vidų.

• 104 svetainės atsakė įprastai, 3 užblokavo automatinę užklausą, 5 nepavyko pasiekti.
• 30 svetainių veikia su WordPress, dvi su Drupal, viena su Joomla, dar 14 turi matomus .php adresus. Tai patvirtina NKSC vertinimą: PHP čia visur.
• Tik 3 svetainės iš 112 antraštėse atskleidžia PHP versiją. Viena rodo pataisytą 8.3.36, viena 8.3.35, viena 7.4.33, kurios PHP projektas nebepalaiko nuo 2022 m. pabaigos.

Svetainių nevardinsime, nes versijos numeris antraštėje dar nereiškia, kad serveris pažeidžiamas, apie tai kitame skyriuje. Išvada kita: apie 109 svetaines iš 112 iš išorės neįmanoma pasakyti nieko. Tai gerai, nes piktavaliams neatskleidžiama versija, bet tai reiškia, kad savininkas neturi kito kelio, kaip paklausti to, kas valdo serverį. Lygiai tas pats galioja jūsų svetainei.

Kodėl versijos numeris gali klaidinti

Čia dažniausia klaida, kurią matėme per šias dienas, ir ji veikia į abi puses. Ubuntu, Debian, RHEL ir kitos Linux distribucijos saugumo pataisas dažnai perkelia į tą versiją, kurią jau platina, ir numerio nekeičia. Pavyzdys iš mūsų pačių serverio su Ubuntu 24.04: komanda php -v rodo PHP 8.3.6, pagal php.net sąrašą tai pažeidžiama versija. Tačiau paketo versija yra 8.3.6-0ubuntu0.24.04.13, o jo pakeitimų sąraše (changelog) įrašyta pataisa CVE-2026-109618_109619. Serveris saugus, nors skaičius sako priešingai.

Ekrano kopija: tikra išvestis iš atnaujinto Ubuntu 24.04 serverio. Pirma eilutė gąsdina, trečia nuramina.

Atvirkštinis atvejis irgi pasitaiko. Valdymo skydeliai (ISPmanager, cPanel, Plesk) ir kai kurie prieglobos teikėjai naudoja savo PHP rinkinius, kurie atnaujinami atskirai nuo operacinės sistemos. Serveryje gali būti vienu metu sisteminis PHP, kuris jau pataisytas, ir skydelio PHP, kuris aptarnauja svetaines ir dar ne. Būtent tokią situaciją šią savaitę radome dviejuose iš keturių mūsų prižiūrimų serverių: sisteminis PHP jau buvo pataisytas, o skydelio rinkinys, kuris aptarnauja svetaines, dar ne.

Kas atnaujina PHP, priklauso nuo to, kur veikia svetainė:

• Bendroji priegloba (hostingas). Atnaujina prieglobos paslaugų teikėjas. Įsitikinti: paklausti teikėjo raštu; NKSC teigimu, didieji Lietuvos teikėjai pataisas jau pritaikė.
• VPS ar dedikuotas serveris su valdymo skydeliu. Atnaujina jūsų administratorius arba jūs. Įsitikinti: tikrinti ir sisteminį, ir skydelio PHP, nes jie atnaujinami atskirai.
• VPS ar dedikuotas serveris be skydelio. Atnaujina jūsų administratorius arba jūs. Įsitikinti: paketo pakeitimų sąrašas arba versija iš php.net sąrašo.
• Debesijos platforma (Kinsta, WordPress.com, Cloudways ir pan.). Atnaujina platforma. Įsitikinti: platformos būsenos puslapis arba pranešimas klientams.

Kaip sužinoti, ar jūsų svetainė atnaujinta

Pirmas žingsnis visiems vienodas: parašykite tam, kas valdo serverį, ir paprašykite atsakymo raštu. Klausimas gali būti vienas sakinys: „Ar mūsų svetainės serveryje PHP atnaujintas dėl CVE-2026-109618 ir CVE-2026-109619, kokia tiksli paketo versija ir kada atnaujinta?“ Rimtas teikėjas atsakys tą pačią dieną. Jei atsakymas skamba „mes nieko nekeitėme, nes niekas nelūžo“, perskaitykite šį straipsnį dar kartą kartu su juo.

Antras žingsnis, jei turite WordPress: administravimo skydelyje atidarykite Įrankiai, Svetainės būklė, Informacija, skiltį Serveris. Ten rodoma PHP versija, kurią iš tikrųjų naudoja svetainė. Jei ji yra 8.2.35, 8.3.36, 8.4.27, 8.5.12 ar naujesnė, viskas gerai. Jei mažesnė, bet svetainė laikoma pas teikėją, jis turi patvirtinti, kad pataisa perkelta į jo rinkinį. Jei versija prasideda 7.4, 8.0 arba 8.1, PHP projektas oficialių pataisytų leidimų jai neišleido. Ubuntu savo paketams php8.1 pataisą perkėlė, kitais atvejais tai reikia pasitikrinti pas teikėją, o nesant pataisos galioja NKSC rekomendacija: izoliuoti ir migruoti.

Trečias žingsnis, jei svetainė naudoja ne WordPress, o kitą sistemą ar programą: Nyderlandų NCSC kartu su partneriais tvarko viešą sąrašą programinės įrangos, kurioje PHP yra vienas iš komponentų: nuo el. parduotuvių iki tinklo įrenginių. Į jį nuorodą pateikia ir NKSC.

Ekrano kopija: sąrašas suskirstytas abėcėlės tvarka, kiekvienai programai nurodyta, ar gamintojas jau išleido pataisą.

Ketvirtas žingsnis, kai nenorite rašyti niekam: mūsų nemokama svetainės patikra parodo, ar jūsų serveris viešai atskleidžia PHP versiją antraštėse ir kokią. Tai neatsako į klausimą, ar pataisa įdiegta, bet dažnai atsako į kitą: ar serveris apskritai prižiūrimas.

Jei iki šiol neatnaujinote

Pirmiausia tai, ką sako ir PHP komanda, ir NKSC: jokia konfigūracija rizikos nepanaikina, tik atnaujinimas. Dalinės priemonės turi prasmę tik tam laikui, kol atnaujinimas vyksta: apriboti arba užblokuoti POST užklausas su multipart/form-data turiniu, jei svetainei jos nereikalingos, ir įjungti žiniatinklio programų užkardą (angl. WAF). „Cloudflare“ savo taisykles įjungė dar prieš viešą paskelbimą ir pats pavadino jas laikina priemone, be to, jos veikia tik tam srautui, kuris eina per „Cloudflare“, o ne tiesiai į serverį.

Antra, atnaujinimas uždaro duris, bet neišveda to, kas jau įėjo. Jei serveris buvo pasiekiamas iš interneto nuo spalio 17 d. iki atnaujinimo, po atnaujinimo verta patikrinti:

• Ar neatsirado naujų administratorių, naujų .php failų wp-content/uploads/, wp-includes/ ar šakniniame kataloge, pakeitimų wp-config.php.
• Ar serverio žurnaluose nėra neįprastų POST užklausų su multipart/form-data turiniu ir labai didelėmis antraštėmis, ypač spalio 17–23 d.
• Ar nėra nežinomų cron užduočių ir išeinančių jungčių į nepažįstamus IP adresus. NKSC rekomendavo stebėti būtent tai: nestandartinius procesus, sistemines komandas, sesijas į nežinomus adresus.
• Po patikros pakeisti prisijungimo duomenis: duomenų bazės, FTP ir SSH, administratorių slaptažodžius ir API raktus: tyrėjai parodė, kad per šias spragas galima perskaityti PHP proceso atmintį, kurioje jie laikomi.

Kaip atpažinti, kad svetainė jau nulaužta, rašėme atskirai: požymiai, kuriuos galima pastebėti be specialistų, ir kur WordPress svetainėje slepiasi backdoor.

Trečia, jei PHP versija nebepalaikoma ir teikėjas pataisos neturi, nebandykite laimėti laiko. Aleknavičius teisus: daliai svetainių teks ne atnaujinimas, o perkėlimas į naują serverį su palaikoma PHP versija, o kai kurioms ir kodo pritaikymas. Tai darbas dienoms, ne valandoms, todėl tuo laikotarpiu svetainė turi būti arba už užkardos, arba išjungta.

Kuo galime padėti

AGuard šią savaitę tikrina ir atnaujina klientų serverius. Jei neturite administratoriaus arba teikėjas neatsako, susisiekite: patikrinsime, kuri PHP versija iš tikrųjų aptarnauja jūsų svetainę, atnaujinsime ją serveryje ar suderinsime atnaujinimą su teikėju ir patikrinsime, ar per tas dienas į svetainę niekas neįėjo. Jei svetainė jau rodo įsilaužimo požymius, kenkėjiško kodo šalinimas apima ir serverio PHP atnaujinimą, kad infekcija nepasikartotų tuo pačiu keliu. Ilgesniam laikui tinka svetainės saugumo auditas, kuriame PHP ir serverio atnaujinimų tvarka yra vienas iš tikrinamų punktų.

Dažnai užduodami klausimai

Šaltiniai

Pirminiai šaltiniai ir institucijos:

• PHP projektas: saugumo pranešimas, 2026-10-21 – pataisytos versijos, rizikos grupės, pažeidžiamumų aprašymas.
• GitHub Security Advisory GHSA-w8hw-w9fx-j79w (CVE-2026-109618) ir GHSA-6wmf-4rv5-p3rp (CVE-2026-109619) – oficialūs pažeidžiamumų įrašai.
• NKSC: DUK apie PHP kritinius pažeidžiamumus, 2026-10-22 ir NKSC: svarbi informacija apie 2026 m. spalio 21 d. PHP atnaujinimą.
• NCSC-NL (Nyderlandų nacionalinis kibernetinio saugumo centras): php2shell, paveiktos programinės įrangos sąrašas.
• Ubuntu USN-8948-1: PHP vulnerabilities – pataisos Ubuntu paketams php8.1 ir php8.3.
• Amazon Threat Intelligence: PHP2Shell exploitation prior to public disclosure – išnaudojimo bandymai iki viešo paskelbimo.

Žiniasklaida (institucijų atstovų citatos):

• 15min: Kibernetinio saugumo centro vadovas įspėjo: spraga gali paliesti 80–90 proc. Lietuvos interneto svetainių, 2026-10-22.
• BNS per tv3.lt: NKSC įspėja: paveiktą programinę kalbą naudoja apie 80–90 proc. šalies svetainių, 2026-10-22 – A. Aleknavičiaus ir A. Raguočio citatos.
• Registrų centro pranešimas per Regionų žinias: Registrų centras imasi prevencinių veiksmų, 2026-10-22.

Savi duomenys:

• AGuard patikra: 112 Lietuvos viešojo sektoriaus svetainių HTTP antraščių ir pradinio puslapio analizė, 2026-10-23, 11:06 Lietuvos laiku. Duomenys apibendrinti, svetainės neįvardijamos.

Pastebėjote klaidą ar pasenusį skaičių? Parašykite, pataisysiu ir pažymėsiu. Kaip rašomi šie straipsniai