Trumpai: Po PHP2Shell vien rodoma PHP versija įrodo nedaug, nes hostingo teikėjai pataisymus dažnai įdiegia kaip atgalinį perkėlimą (backport). Todėl paprašykite raštiško hostingo teikėjo PHP atnaujinimo patvirtinimo: paketo būsenos pagal kiekvieną PHP šaką, įdiegimo momento ir visų PHP procesų paleidimo iš naujo. Šabloną kopijavimui rasite žemiau.
Kodėl būtent dabar svarbus raštiškas patvirtinimas
2026-10-21 PHP projektas išleido pataisas dviem kritiniams pažeidžiamumams, žinomiems PHP2Shell pavadinimu. Abu leidžia nuotoliu vykdyti kenkėjišką kodą be prisijungimo. BSI paskelbė 3 (oranžinį) įspėjimo lygį ir rekomenduoja nedelsiant atnaujinti.
Kas svetainę laiko pas hostingo teikėją, atnaujinimo dažnai pats įdiegti negali. Kartu kaip operatorius atsakote už savo klientų duomenis. Todėl raštiškas, konkretus hostingo teikėjo patvirtinimas yra daugiau nei formalumas. Tai jūsų dokumentacijos dalis, pavyzdžiui, duomenų apsaugos pareigūnų, draudikų ar vadovybės atžvilgiu.
Be to: pataisa nepašalina kenkėjiškos programinės įrangos, įterptos anksčiau. Pasak žiniasklaidos pranešimų, pirmasis atakos bandymas buvo pastebėtas jau spalio 17 d. Tikslus momentas, nuo kada jūsų serveris buvo apsaugotas, todėl svarbus sprendžiant, ar reikia tikrinti toliau.
Kodėl rodomos PHP versijos nepakanka
Ištaisytos PHP 8.5.12, 8.4.27, 8.3.36 ir 8.2.35 versijos. Tačiau daugelis distribucijų ir hostingo teikėjų pataisymą perima kaip atgalinį perkėlimą į savo paketą. Tuomet sąsaja, pavyzdžiui, Plesk, toliau rodo 8.2.34, nors serveris pataisytas.
Ir atvirkščiai: teisingas versijos numeris gali klaidinti. Vien naujų failų nepakanka, kol atmintyje dar veikia seni PHP procesai. Naujas variantas aktyvus tik paleidus iš naujo visus darbinius procesus (worker). Daugiau straipsnyje Kaip teisingai patikrinti PHP versiją ir pataisų būseną.
| Hostingo teikėjo teiginys | Ką jis įrodo | Ko dar trūksta |
|---|---|---|
| „Visos sistemos atnaujintos.“ | nedaug | Versija ar paketo būsena, data, paleidimas iš naujo |
| „Įdiegta PHP 8.3.36.“ | Versiją | Datos, paleidimo iš naujo, paveiktų serverių |
| „Backport pakete xy, paleista iš naujo …“ | Pataisą ir aktyvavimą | Prireikus duomenų apie PHP 8.1 ir senesnes versijas |
Kokių duomenų reikia iš hostingo teikėjo
Paprašykite atsakymų į šiuos klausimus, jei įmanoma, pagal kiekvieną svetainę ar sutartį:
- Kokios PHP šakos ir versijos aktyvios jūsų svetainėms, taip pat senesnės, veikiančios tik atskiruose kataloguose?
- Ar yra CVE-2026-109618 ir CVE-2026-109619 pataisymai, kaip oficiali versija ar kaip backport?
- Kada atnaujinimas buvo įdiegtas ir kada visi PHP procesai (FPM baseinai, Apache, LiteSpeed) buvo paleisti iš naujo?
- Ar dėl CVE-2026-115560 išjungtas
session.upload_progress.enabled? - Kokį veikimo režimą naudoja jūsų planas, pavyzdžiui, PHP-FPM ar Apache su mod_php? Esant mod_php PHP komanda mato didžiausią riziką.
- Kokie prieigos ir klaidų žurnalai nuo 2026-10-20 saugomi ir kaip juos galite gauti?
Jei svetainė vis dar veikia su PHP 8.1 ar senesne versija, klauskite atskirai. Toms šakoms oficialių atnaujinimų nebėra, yra tik minimalūs šaltinio kodo atgaliniai perkėlimai 7.4, 8.0 ir 8.1 versijoms.
Šablonas: paprašyti hostingo teikėjo PHP atnaujinimo patvirtinimo
Nukopijuokite tekstą į pagalbos užklausą ar el. laišką savo hostingo teikėjui. Laužtiniuose skliaustuose esančius duomenis papildykite.
Tema: Prašymas patvirtinti PHP pataisų būseną (PHP2Shell, CVE-2026-109618 / CVE-2026-109619)
Laba diena,
pas jus valdome šias svetaines / sutartis:
[Kliento numeris, sutartis, domenai]
Dėl PHP pažeidžiamumų CVE-2026-109618 ir CVE-2026-109619
(PHP2Shell, pataisos 2026-10-21) bei 2026-10-23 pranešimo
dėl CVE-2026-115560 prašome raštiško patvirtinimo šiais klausimais:
1. Kokios PHP versijos ar paketų būsenos aktyvios mūsų svetainėms?
2. Ar jose yra pataisymai (oficiali versija ar backport)?
3. Įdiegimo data ir laikas.
4. Visų PHP procesų (FPM, Apache, LiteSpeed ar kt.) paleidimo iš
naujo data ir laikas.
5. Ar session.upload_progress.enabled išjungtas serverio pusėje?
6. Koks PHP veikimo režimas naudojamas (pvz., PHP-FPM, mod_php)?
7. Ar prieigos ir klaidų žurnalai saugomi nuo 2026-10-20 ir kaip
galime juos gauti?
8. Jei kuri nors svetainė dar naudoja PHP 8.1 ar senesnę versiją:
kokia ten apsauga ir kokį perėjimą rekomenduojate?
Šie duomenys reikalingi mūsų vidinei dokumentacijai.
Dėkojame ir geriausi linkėjimai
[Vardas, įmonė, pareigos]
Kaip teisingai įvertinti atsakymą ir pačiam jį pasitikrinti
Geras atsakymas nurodo konkrečias būsenas, datas ir laikus. Bendri sakiniai, pavyzdžiui, „sureagavome“, jūsų bylai nepakanka. Tuomet maloniai paprašykite trūkstamų duomenų.
Jei jūsų planas leidžia, patikrinkite ir patys. Turint SSH prieigą dažniausiai pakanka šių komandų:
# Komandinės eilutės versija (gali skirtis nuo žiniatinklio versijos)
php -v
# Paketo būsena Debian/Ubuntu
dpkg -l | grep -E "php[0-9.]*-(fpm|cli|common)"
# Paketo būsena RHEL, Alma, Rocky
rpm -qa | grep -i php
# Nuo kada veikia PHP-FPM procesai?
ps -eo pid,lstart,cmd | grep "[p]hp-fpm"
Jei PHP procesų paleidimo laikas ankstesnis už patvirtintą įdiegimo datą, paleidimas iš naujo nebuvo pilnas.
Kai hostingo teikėjas neatsako arba išsisukinėja
Jei atsakymo nėra arba trūksta lemiamų duomenų, padėties nelaikykite išaiškinta. BSI rekomenduoja laikinai atjungti žiniatinklio serverius nuo tinklo, jei atnaujinti iš karto neįmanoma. Ar tai proporcinga jūsų svetainei, sprendžia vadovybė, geriausia raštu ir su data.
Lygiagrečiai verta ieškoti galimų atakos pėdsakų, nes pataisymo momentas lieka neaiškus. Užuominų pateikia straipsnis Ar jau esu kompromituotas?. Be SSH prieigos raštiškas patvirtinimas lieka svarbiausias jūsų įrodymas. Kokios pareigos tenka hostingo teikėjui, o kokios jums, paaiškina puslapis Bendrinamas hostingas: ką daro teikėjas; prižiūrimiems serveriams padeda Valdomas serveris: aiškinamės atsakomybę.
Užklausą, atsakymą ir savo patikros rezultatus su datomis saugokite viename aplanke. Šis rinkinys vėliau padės atsakant į draudikų ar duomenų apsaugos pareigūnų klausimus.
Kaip PHP SOS padeda konkrečiai?
- Kartu su jumis suformuluojame užklausą hostingo teikėjui ir profesionaliai įvertiname atsakymą.
- Kur turime prieigą, patys tikriname paketo būseną, aktyvų veikimo režimą ir PHP procesų paleidimą iš naujo.
- Jei lieka spragų, įgyvendiname pereinamąsias priemones arba planuojame perėjimą prie palaikomos versijos.
- Rezultatą ir momentus užfiksuojame įrodymu, kurį galite perduoti viduje.
Kaip vyksta atnaujinimas su paleidimu iš naujo ir įrodymu, aprašo mūsų PHP pataisų paslauga.
Dažni klausimai
Ar pakanka, kad hostingo teikėjas parašo, jog viskas atnaujinta?
Jūsų dokumentacijai greičiausiai ne. Paprašykite konkrečių duomenų: paketo būsenos arba versijos pagal kiekvieną PHP šaką, įdiegimo datos ir visų PHP procesų paleidimo iš naujo datos. Tik su jais galėsite apriboti pažeidžiamumo laikotarpį.
Kodėl mano hostingo sąsajoje vis dar rodoma PHP 8.2.34?
Distribucijos ir hostingo teikėjai saugumo pataisymus kartais įdiegia kaip atgalinį perkėlimą (backport), nekeisdami versijos numerio. Tuomet Plesk gali toliau rodyti 8.2.34, nors serveris pataisytas. Aiškumą suteikia tik teikėjo patvirtinimas dėl paketo būsenos.
Ką daryti, jei hostingo teikėjas neatsako?
Užfiksuokite savo užklausą su data ir po pagrįsto laiko paklauskite dar kartą. Kartu patikrinkite, ar pereinamąsias priemones galite nustatyti patys, ir su vadovybe suderinkite, ar iki išsiaiškinimo svetainė bus atjungta nuo tinklo, kaip BSI rekomenduoja nepataisytiems serveriams.
Ar WordPress arba parduotuvės atnaujinimas taip pat uždaro pažeidžiamumą?
Ne. PHP2Shell glūdi pačiame PHP. CMS ar parduotuvės programinės įrangos atnaujinimas nieko nekeičia serveryje veikiančiame PHP interpretatoriuje.