2026 m. spalio 21 d. nuo 7 ryto kavos nebuvo. Taisėm PHP spragas. Naktį mus pasiekė pranešimai apie dvi kritines PHP spragas ir jų išnaudojimo koncepcijos kodą (PoC). CVE-2026-109618 nurodytas 9,2 balo CVSS įvertinimas. Kol oficialaus pataisymo dar laukėme, reikėjo reaguoti, o ne laukti perspėjimo.
2
kritinės PHP spragos
pagal pranešimus
9,2
CVSS įvertinimas
CVE-2026-109618
07:00
pradėjome reagavimą
Iki pietų
pritaikėme laikiną priemonę
1. Kas nutiko ir ką padarėme
Viešuose pranešimuose minimos CVE-2026-109618 ir CVE-2026-109619 – PHP atminties valdymo klaidos, tam tikromis sąlygomis galinčios leisti nuotoliniu būdu vykdyti kodą be autentifikacijos. Pranešta, kad rizika gali kilti ir su numatytaisiais nustatymais. Vis dėlto ne kiekviena PHP svetainė automatiškai pažeidžiama: svarbios PHP versija, konfigūracija ir konkreti serverio aplinka.
Iki pietų atsargumo sumetimais išjungėme session.upload_progress visose mūsų ir klientų sistemose, patikrinome žurnalus ir laukėme oficialaus atnaujinimo. Tai mūsų spalio 21 d. ryto darbų eiga. Vėliau tą pačią dieną PHP paskelbė oficialias saugumo pataisas: 8.2.35, 8.3.36, 8.4.27 ir 8.5.12.
Atsargumo priemonė nėra patvirtintas pataisymas
session.upload_progress išjungimas buvo mūsų atsargumo veiksmas, o ne oficialiai patvirtinta apsauga nuo abiejų spragų. Jis nepakeičia tiekėjo patvirtintų saugumo pataisų ir nepašalina galimo ankstesnio įsilaužimo pasekmių. Jei atnaujinti iš karto negalite, vadovaukitės oficialiomis rekomendacijomis dėl paveiktų sistemų izoliavimo.
NKSC perspėjimas mus pasiekė po pietų. Geriau vėliau negu niekada, bet spragų laikrodis pradėjo tiksėti dar naktį. Tai mūsų gauto perspėjimo laikas – ne išvada apie tai, kada institucija pradėjo dirbti ar kada perspėjimą gavo visi kiti.
2. Ką tai reiškia PHP svetainę turinčiai įmonei
PHP naudojamas svetainėse, el. parduotuvėse, turinio valdymo sistemose, klientų savitarnose ir CRM. Rizika aktuali tiek nuosaviems serveriams, tiek bendro naudojimo hostingui. Veikianti svetainė savaime nereiškia, kad jos serveris saugus.
Sėkmingo išnaudojimo pasekmės priklauso nuo serverio teisių ir izoliacijos. Jos gali apimti duomenų vagystę, svetainės pakeitimą, kenkėjiško kodo įdiegimą ar prieigos prie kitų sistemų gavimą. Tikslus pažeidžiamų ar jau kompromituotų sistemų skaičius nėra patikimai nustatytas, todėl jo nepateikiame.
3. Kodėl vien atnaujinti serverį nepakanka
Įsivaizduokite, kad serveris turėjo neužrakintas duris. Jūs jas užrakinote, bet nežinote, ar kas nors per jas jau įėjo. Saugumo atnaujinimas uždaro spragą, tačiau neatsako į klausimą, ar užpuolikas ja pasinaudojo anksčiau.
Jei sistema buvo kompromituota, joje galėjo likti papildomas prieigos mechanizmas, nežinoma paskyra, pakeisti failai ar suplanuota užduotis. Galėjo būti pavogti ir prisijungimo duomenys. Vien atnaujintas PHP šių pasekmių nebūtinai pašalina.
Svarbu neperšokti prie išvadų
Normali svetainės veikla ir akivaizdžių aliarmų nebuvimas neįrodo, kad įsilaužimo nebuvo. Tačiau vien spragos buvimas taip pat neįrodo, kad sistema jau užkrėsta. Tai nustatoma techniniu tyrimu.
4. Ką būtina patikrinti dabar
- Inventorizuoti visas PHP sistemas ir versijas: pagrindines bei pagalbines svetaines, konteinerius, administravimo sistemas ir trečiųjų šalių produktus.
- Patikrinti naujausią oficialų PHP ir savo hostingo ar operacinės sistemos tiekėjo perspėjimą. Įdiegti tiekėjo patvirtintą pataisytą versiją; nebepalaikomoms versijoms planuoti migraciją.
- Patikrinti, ar laikina konfigūracijos priemonė pritaikyta visose naudojamose PHP aplinkose, o ne tik viename serveryje. Tolesnius pakeitimus derinti su tiekėjo rekomendacijomis.
- Peržiūrėti žiniatinklio serverio, PHP, autentifikacijos, sistemos ir tinklo žurnalus: neįprastas užklausas, klaidas, procesų paleidimą ir išorinius ryšius.
- Ieškoti neleistinų failų pakeitimų, nežinomų paskyrų, įtartinų procesų, suplanuotų užduočių ir papildomų prieigos mechanizmų.
- Tyrimo neapriboti oficialaus perspėjimo laiku. Vertinti visą galimo pažeidžiamumo laikotarpį ir turimų žurnalų aprėptį.
- Nustačius ar pagrįstai įtarus kompromitavimą, įvertinti slaptažodžių, API raktų, sesijų ir kitų paslapčių pakeitimo poreikį.
- Aptikus įsilaužimo požymių, izoliuoti sistemą ir išsaugoti tyrimui reikalingus duomenis. Vien pašalinti įtartiną failą nepakanka, kol nenustatytas incidento mastas.
5. Ko paklausti savo hostingo tiekėjo
Jei turite PHP svetainę, pasitikrinkite, ar jūsų hostingas jau sureagavo. Nelaukite, kol sureaguos už jus. Paprašykite konkretaus atsakymo, o ne vien pažado, kad „viskas prižiūrima“.
- Kokia PHP versija realiai aptarnauja mūsų svetainę ir ar jai taikomi paskelbti pažeidžiamumai?
- Kokios laikinos apsaugos priemonės pritaikytos ir kada įdiegtos oficialios pataisos?
- Ar patikrinti žurnalai ir ankstesnio išnaudojimo požymiai? Kokį laikotarpį apėmė patikra?
- Kas imsis incidento tyrimo, jei bus aptikta kompromitavimo požymių?
Kibernetinis saugumas nėra vien pažeidžiamumo pašalinimas. Svarbu nustatyti ir tai, ar užpuolikas nespėjo juo pasinaudoti.
— ProKSI / KSG komanda
Šaltiniai ir įvykio kontekstas
Spalio 21 d. reagavimo eiga pateikta pagal KSG komandos pasakojimą. Techniniam kontekstui pateiktame straipsnio šaltinių sąraše nurodyti: Phoenix Security, Techmeme / Ars, Vulners PoC ir daily.dev. Techninę informaciją ir pataisų būseną visada tikrinkite oficialiuose tiekėjo pranešimuose.
- CERT-EU saugumo perspėjimas ir CVSS įvertinimas: https://www.cert.europa.eu/publications/security-advisories/2026-018/
- ENISA perspėjimo nuoroda: https://www.enisa.europa.eu/news/joint-statement-on-critical-php-vulnerabilities
- Oficialus PHP leidimų archyvas: https://www.php.net/archive/2026.php
- Pasidalinta naujienos nuoroda: https://lnkd.in/eGpAamqN
PHP sistemų saugumo patikra
Įvertinsime PHP aplinką, žurnalus ir galimo ankstesnio išnaudojimo požymius, pateiksime aiškų veiksmų planą. Jei įtariate vykstantį įsilaužimą, reikalingas incidento tyrimas, ne vien atnaujinimas.
Susisiekti su PROKSI