Dvi kritinės PHP spragos: ką turi padaryti svetainių savininkai

2026 m. spalio 21 d. PHP kūrėjai paskelbė apie dvi kritines saugumo spragas, kurios tam tikromis sąlygomis leidžia neprisijungusiam užpuolikui nuotoliniu būdu vykdyti kodą serveryje. Abiejų spragų pavojingumas įvertintas 9,2 balo iš 10 pagal CVSS v4.0. Svetainių savininkams tai skubus signalas patikrinti prieglobos aplinką ir įdiegti PHP saugumo pataisas. Oficialus PHP pranešimas.

Kas nustatyta PHP aplinkoje?

PHP yra serveryje veikianti programavimo aplinka, kuria naudojasi „WordPress“, „WooCommerce“ ir daugelis individualių svetainių bei verslo sistemų. Šiuo atveju pataisų reikia pačiai PHP aplinkai. Vien turinio valdymo sistemos ar jos įskiepių atnaujinimas šių dviejų PHP klaidų nepašalina.

CVE-2026-109618 – atminties būsenos sugadinimas pritrūkus atminties. Nutrūkus užklausos apdorojimui, PHP gali bandyti tvarkyti nevisiškai paruoštus vidinius duomenis. Specialiai suformuotos užklausos gali šią klaidą paversti nuotoliniu kodo vykdymu. PHP saugumo komanda patvirtino išnaudojimą „Apache mod_php“ aplinkoje dar prieš pradedant veikti svetainės programiniam kodui. Techninis CVE-2026-109618 aprašymas.

CVE-2026-109619 – pasenusi būsena tarp užklausų. PHP procesas gali išsaugoti nuorodas į jau atlaisvintą ankstesnės užklausos atmintį. Vėlesnė užklausa, aptarnaujama to paties proceso, tam tikromis sąlygomis panaudoja šią nebegaliojančią būseną. Tai taip pat gali sudaryti galimybę vykdyti užpuoliko kodą. Techninis CVE-2026-109619 aprašymas.

Praktinis skirtumas svetainės savininkui: užpuolikui gali neprireikti administratoriaus slaptažodžio ar lankytojo paspaudimo. Dėl to šią naujieną verta perduoti serverį prižiūrinčiam specialistui iš karto.

Kokios svetainės gali būti paveiktos?

PHP komanda ragina atnaujinti visas žiniatinklio užklausas aptarnaujančias PHP aplinkas: „PHP-FPM“, „Apache mod_php“, „php-cgi“, „FrankenPHP“ ir „LiteSpeed“. Didžiausia patvirtinta rizika nurodoma „mod_php“, tačiau „PHP-FPM“ naudojimas savaime nesuteikia apsaugos. PHP rizikos paaiškinimas.

Antrosios spragos aprašyme pateiktas patvirtintas „PHP-FPM“ scenarijus, priklausantis nuo tinkamos programos operacijos ir tolesnės užklausos tame pačiame procese. Vis dėlto išnaudojimo sąlygos skiriasi tarp aplinkų: vien PHP versijos numeris neįrodo, kad konkreti svetainė jau buvo nulaužta. PHP-FPM ir kitų scenarijų analizė.

Patikrą turėtų inicijuoti tiek reprezentacinės svetainės, tiek elektroninės parduotuvės ar klientų portalo savininkas. Net paprasta kontaktų forma veikia platesnėje serverio aplinkoje. HTTPS sertifikatas šių PHP klaidų neištaiso, o ugniasienė gali būti papildomas apsaugos sluoksnis, tačiau neatstoja pataisytos vykdymo aplinkos.

Kokios gali būti pasekmės svetainei ir verslui?

Patvirtinto išnaudojimo atveju kodas vykdomas žiniatinklio proceso paskyros teisėmis. Tai nėra automatinė viso serverio administratoriaus prieiga: konkretų poveikį lemia failų teisės, pasiekiami duomenys ir aplinkos izoliavimas. PHP komandos patvirtintas poveikis.

Vertinant verslo riziką, priklausomai nuo suteiktų teisių galimi tokie padariniai:

• Svetainės turinio pakeitimas. Įrašyti failai ar pakeisti duomenys gali lemti svetimus puslapius, apgaulingus pranešimus ir lankytojų nukreipimą.
• Duomenų konfidencialumo pažeidimas. Jei procesui prieinami konfigūracijos failai ar duomenų bazė, gali kilti grėsmė jose saugomai informacijai ir prisijungimo duomenims.
• Veiklos sutrikimas. Neveikiant svetainei gali nutrūkti užklausų siuntimas, registracija ar pirkimas. Elektroninei parduotuvei tai gali reikšti prarastus užsakymus ir papildomą klientų aptarnavimo darbą.
• Atkūrimo ir reputacijos išlaidos. Gali prireikti incidento tyrimo, sistemos atkūrimo, prieigų pakeitimo ir bendravimo su paveiktais klientais.

Tai galimų pasekmių vertinimas, o ne teiginys apie konkretų įsilaužimą. Spragos buvimas ir patvirtintas saugumo incidentas yra atskiri dalykai.

Kokias PHP versijas reikia įdiegti?

PHP nurodo šias pataisytas versijas. Rinkitės bent atitinkamą leidimą arba naujesnį savo šakos leidimą su šiomis pataisomis. Oficialios atnaujinimo rekomendacijos.

„Linux“ distributoriai ir ilgalaikio palaikymo tiekėjai gali pataisas perkelti į ankstesniu numeriu žymimus paketus. Tokiu atveju svarbus tiekėjo patvirtinimas, kad įdiegtame pakete ištaisytos abi CVE spragos. PHP 8.1 ir senesnių šakų PHP projektas įprastai nebepalaiko. Informacija apie tiekėjų pataisas ir senesnes šakas.

PHP 8.2 saugumo palaikymas baigiasi 2026 m. gruodžio 31 d. Jei svetainė ją dar naudoja, kartu verta suplanuoti perėjimą į ilgiau palaikomą šaką. PHP versijų palaikymo terminai.

Ką daryti dabar: atnaujinimo veiksmų planas

Rekomenduojame atnaujinimą organizuoti kaip trumpą, patikrinamą priežiūros darbą. Vien pakeisti skaičių prieglobos valdymo skydelyje nepakanka, jei dalis procesų toliau naudoja seną aplinką.

1. Inventorizuoti tikrą aplinką. Nustatyti, kokia PHP versija aptarnauja konkretų domeną, jo atskirus procesų telkinius ir konteinerius. Komandinės eilutės PHP gali skirtis nuo naudojamos naršyklės užklausoms. Atskirai patikrinti fonines užduotis.
2. Patikrinti atsarginę kopiją. Turėti suderintą failų ir duomenų bazės kopiją bei aiškų atkūrimo būdą. Planuojant trumpą priežiūros langą, numatyti tuo metu gaunamų užsakymų ir formų duomenų išsaugojimą.
3. Įdiegti patvirtintą pataisą. Su prieglobos tiekėju arba serverio administratoriumi atnaujinti naudojamą PHP šaką. Jei pereinama į kitą šaką, iš anksto įvertinti svetainės kodo ir plėtinių suderinamumą.
4. Perkrauti procesus ir patikrinti rezultatą. Įsitikinti, kad visi svetainę aptarnaujantys PHP procesai jau naudoja pataisytą paketą. Patikrinti veikiančią aplinką, o ne vien atsisiųsto paketo būseną.
5. Išbandyti svarbiausius veiksmus. Atverti vidinius puslapius, išsiųsti kontroliuojamą formos testą, patikrinti prisijungimą, failų įkėlimą, suplanuotas užduotis ir aktualias integracijas. Parduotuvėje išbandyti pirkimo eigą bei mokėjimų grįžtamuosius pranešimus.

Darbo pabaigoje turi likti aiškus atsakymas: kas atnaujinta, kaip patvirtinta pataisa ir kokios svetainės funkcijos patikrintos. Veikiantis pradinis puslapis dar nepatvirtina, kad veikia užsakymų ar laiškų siuntimo procesai.

Ar galima apsisaugoti laikinais nustatymais?

PHP kūrėjų nurodytos laikinos priemonės blokuoja tik dalį išnaudojimo kelių. Antrosios spragos atveju tai apima administracinį session.upload_progress.enabled=0, o PHP 8.5 aplinkoje – ir fatal_error_backtraces=0 nustatymą bei visų procesų perkrovimą. Tai nesuteikia visapusės apsaugos; nustatymus turi įvertinti administratorius. Laikinų priemonių ribos.

Atminties spragos rekomendacijose minimas ir PHP atminties limito panaikinimas. Aklai taikyti memory_limit=-1 bendroje priegloboje pavojinga dėl išteklių išnaudojimo. Reikia tinkamai suplanuotų išteklių ribų ir užklausų kontrolės; net tuomet išlieka kiti atminties paskirstymo nesėkmės keliai. Pilnas sprendimas yra pataisytas PHP paketas. Atminties spragos mažinimo rekomendacijos.

Ką daryti įtarus įsilaužimą?

Jei pastebėtas svetimas turinys, nepaaiškinami failų pakeitimai ar neįprastas sistemos elgesys, vien PHP atnaujinimu apsiriboti nereikėtų. Rekomenduojame išsaugoti žurnalus ir kitus tyrimui reikalingus duomenis, su administratoriumi įvertinti izoliavimo poreikį ir nustatyti pakeitimų mastą. Prieigų keitimą bei atkūrimą iš patikrintos kopijos reikia derinti su aplinkos sutvarkymu, kad naujos prieigos nepatektų į vis dar pažeistą sistemą.

Vien klaidų nebuvimas žurnaluose nėra saugumo patvirtinimas. PHP komanda pabrėžia, kad žurnalai turi papildyti konfigūracijos ir programos veikimo analizę. Žurnalų analizės apribojimai.

Kaip gali padėti Dev4you.lt?

Dev4you.lt komanda gali padėti paversti šį pranešimą konkrečiu darbų planu jūsų svetainei: nustatyti naudojamą aplinką, suderinti atnaujinimą, patikrinti svetainės veikimą ir užfiksuoti rezultatą. Darbų apimtis priklauso nuo turimų prieigų, prieglobos modelio ir sistemos sudėtingumo.

• Serverių administravimas – PHP paketų, plėtinių ir procesų konfigūracijos peržiūra, atnaujinimo organizavimas bei veikiančios versijos patikrinimas.
• Svetainių priežiūra – suderinamumo įvertinimas, kritinių funkcijų testavimas ir po atnaujinimo išryškėjusių klaidų šalinimas.
• Svetainių saugumo patikra – sutartos apimties konfigūracijos, prieigų ir galimų pažeidimo požymių įvertinimas.
• Atsarginės kopijos ir atkūrimas – kopijų būklės patikrinimas ir atkūrimo plano parengimas.

Nežinote, kas prižiūri jūsų svetainės PHP? Susisiekite su Dev4you.lt ir nurodykite svetainės adresą, prieglobos tiekėją bei naudojamą turinio valdymo sistemą. Slaptažodžių į pradinę užklausą nedėkite – prieigų perdavimą suderinsime atskirai.

Šaltiniai ir informacijos data

Informacija patikrinta 2026 m. spalio 22 d. pagal PHP projekto pirminius šaltinius. Galimų verslo pasekmių vertinimas ir siūlomas darbų planas – Dev4you.lt komandos paaiškinimas.

• PHP: 2026 m. spalio 21 d. kritinių spragų pranešimas.
• PHP saugumo komanda: CVE-2026-109618.
• PHP saugumo komanda: CVE-2026-109619.
• PHP šakų palaikymo terminai.

Pasitikrinkite svetainės PHP versiją

Dev4you.lt PHP2Shell įrankis padės įvertinti PHP versijos duomenis ir el. paštu gauti PDF su rekomenduojamais veiksmais. Jei versija paslėpta, rezultatas aiškiai parodys, kad reikia papildomų duomenų.

PHP saugumo patikra →