Dabartinė padėtis: PHP2Shell. Du kritiniai PHP pažeidžiamumai (CVSS 9,2) leidžia vykdyti kenkėjišką kodą be prisijungimo. Pataisos nuo 2026-10-21.Ką dabar daryti →

Pataisyti, išjungti ar laukti? Sprendimo pagalba esant PHP spragai

Esant kritinei PHP spragai atsakingieji turi greitai spręsti. Ši pagalba sutvarko tris variantus, nurodo kriterijus ir parodo, kada laukti yra pateisinama.

Būsena 4 min. skaitymoSprendimų pagalba

Trumpai: ar dėl PHP spragos reikėtų išjungti svetainę, priklauso nuo vieno klausimo: ar PHP šiame serveryje įrodomai veikia ištaisytos būsenos ir ar visi procesai paleisti iš naujo? Jei taip, išjungti nereikia. Jei atnaujinimo iškart įdiegti neįmanoma, BSI rekomenduoja laikinai atjungti žiniatinklio serverį nuo tinklo. Laukti pateisinama tik tuomet, kai sistema nenaudoja PHP, nėra viešai pasiekiama arba teikėjas raštu patvirtino pataisą.

Padėtis, kurioje turite spręsti

PHP2Shell apima dvi spragas pačiame PHP, CVE-2026-109618 ir CVE-2026-109619, abi įvertintos CVSS v4.0 9,2. Jos leidžia nuotoliu vykdyti kenkėjišką kodą be prisijungimo. Ištaisytos versijos prieinamos nuo 2026-10-21: 8.5.12, 8.4.27, 8.3.36 ir 8.2.35. PHP 8.1 ir senesnėms oficialių atnaujinimų nebėra.

BSI paskelbė oranžinį įspėjimo lygį ir pataria nedelsiant atnaujinti, o jei nepavyksta, laikinai išjungti. Pasak žiniasklaidos pranešimų, Maincas (Mainz) miestas, Heseno žemės vyriausybės tarnybos ir kitos viešosios įstaigos atsargumo sumetimais atjungė svetaines nuo tinklo; Heseno valstybės kanceliarija apie ataką nepranešė. Ką iš to gali pasiimti įmonės, aprašyta skyriuje Institucijos atjungia svetaines nuo tinklo.

Įmonių atsakingiesiems klausimas praktiškesnis: ką šiandien darome su savo parduotuve, portalu, įmonės svetaine?

Svetainės išjungimas, pataisymas ar laukimas: trys variantai palyginime

Toliau pateiktoje lentelėje variantai sudėti greta. Ji nepakeičia jūsų konkretaus atvejo vertinimo, bet paverčia svarstymą matomu.

Kriterijus Pataisyti nedelsiant Laikinai išjungti Laukti
Apsauga nuo PHP2Shell Didelė, jei pataisa ir paleidimas iš naujo įrodyti Didelė išjungimo laikotarpiu Jokios, kol nepataisyta
Veiklos pertrauka Trumpa, atnaujinimui ir paleidimui iš naujo Valandos ar dienos Nėra
Prielaida Palaikoma PHP versija, prieiga, aptarnavimo langas Vadovybės sprendimas, statinis pakaitinis puslapis Įrodyta priežastis, kodėl rizikos nėra
Darbo sąnaudos Mažos ar vidutinės Technine prasme mažos, organizacine didelės Mažos, bet reikia įrodymo patikros
Tipinis atvejis Serveris su PHP 8.2–8.5 Sena sistema su PHP 8.1 ar senesne, neaiški būsena Sistema be PHP arba pasiekiama tik viduje
Likutinė rizika Ankstesnis įsilaužimas lieka galimas Ankstesnis įsilaužimas lieka galimas Visa išlieka

Viena eilutė nusipelno dėmesio: nei pataisa, nei išjungimas neišaiškina, ar anksčiau jau kas nors įvyko. Pasak žiniasklaidos pranešimų, pirmasis stebėtas atakos bandymas buvo 2026-10-17, taigi prieš pataisą. Todėl galimų pėdsakų patikra priklauso kiekvienam variantui.

Penkiais klausimais iki sprendimo

Atlikite klausimus iš eilės. Pirmas aiškus atsakymas dažniausiai veda prie sprendimo.

  1. Ar sistemoje apskritai veikia PHP ir ar ji pasiekiama iš interneto? Jei ne, sistema PHP2Shell nėra tiesiogiai paveikta. Dokumentuokite, kaip tai nustatėte.
  2. Ar pataisų būsena įrodyta? Įrodyta reiškia: ištaisyta versija arba atgalinis perkėlimas (backport) su CVE numeriais paketo pakeitimų žurnale ir visų PHP procesų paleidimas iš naujo. Versijos rodymo skydelyje nepakanka. Kaip tai patikrinti, rasite skyriuje Kaip teisingai patikrinti PHP versiją ir pataisų būseną.
  3. Ar atnaujinimą galima įdiegti per artimiausias valandas? Jei taip: pataisyti, paleisti iš naujo, patikrinti. Iki to laiko gali padėti pereinamosios priemonės.
  4. Ar tai neįmanoma, pavyzdžiui, dėl PHP 8.1 ar prieigos trūkumo? Tuomet pagal BSI kelias yra laikinas išjungimas. php.net pereinamosios priemonės sumažina riziką, bet neapsaugo visiškai; smulkmenos pateiktos skyriuje Skubios priemonės, kai dar negalite pataisyti.
  5. Ar yra kompromitavimo požymių? Tuomet klausimas nebėra „pataisyti ar išjungti“, o „tvarkyti incidentą“. Išjungti, išsaugoti įrodymus, nesiimti skubotai trinti.

Jei išjungiate: išjunkite teisingai

Išjungimas turi pašalinti atakos paviršių, o ne tik paslėpti pradinį puslapį. Priežiūros puslapis, kurį toliau generuoja PHP, šio tikslo neatitinka. Geriau statinis HTML puslapis, kurį žiniatinklio serveris pateikia be PHP, arba nukreipimas į kitą serverį.

Pagalvokite apie viską, kas priklauso nuo to paties PHP: poaplankius, programėlių ar prekių apskaitos sąsajas, administravimo sritis, mokėjimų atgalinius iškvietimus. Jei paveikta parduotuvė, iš anksto pasikalbėkite su mokėjimo paslaugų teikėju ir logistika. Ir aiškiais žodžiais informuokite darbuotojus bei klientus: svetainė atsargumo sumetimais neprieinama, ryšys per telefoną ir el. paštą. Tai geriau nei tyla, kuri maitina spėliones.

Svarbi ir išjungimo pabaiga. Nustatykite, kokiomis sąlygomis svetainė vėl grįžta į tinklą, pavyzdžiui, „PHP ištaisytos būsenos, paleidimas iš naujo patikrintas, pirma pėdsakų patikra be radinių“. Taip avarinis stabdis tampa sutvarkyta eiga.

Svarbu

Išjungti nėra pralaimėjimas. Pasak žiniasklaidos pranešimų, kelios viešosios įstaigos būtent taip ir padarė, nors atakos nebuvo. Atsargumo sumetimais išjungimas automatiškai nereiškia, kad svetainė buvo įsilaužta.

Kada paslaugų teikėjo nereikia

Ne kiekvienam sprendimui reikia išorinės pagalbos. Jei jūsų svetainė yra pas hostingo teikėją, kuris raštu patvirtina pataisų būseną ir paleidimą iš naujo, ir nėra jokių įtartinų požymių, jums pakanka trumpos dokumentacijos. Tas pats galioja, jei jūsų pačių IT gali pati pataisyti serverį su palaikoma PHP versija ir moka atlikti kontrolę.

Pagalba verta, kai veikia sistemos su sena PHP versija, būsena neaiški, paveikta keli serveriai arba yra įsilaužimo požymių.

Kaip PHP SOS padeda konkrečiai?

  1. Per trumpą laiką su jumis išsiaiškiname, kurios sistemos paveiktos ir kokia pataisų būsena įrodyta.
  2. Vadovybei pateikiame sprendimo pagrindą vienu puslapiu: variantai, rizikos, rekomenduojamas kelias.
  3. Pasirinktą kelią įgyvendiname, tai yra pataisa su paleidimu iš naujo, pereinamosios priemonės arba tvarkingas išjungimas su statiniu pakaitiniu puslapiu, kaip savo PHP2Shell skubios pagalbos dalį.
  4. Tikriname pėdsakus nuo 2026-10-17 ir dokumentuojame rezultatą.

Išvada

Pataisyti yra normalus atvejis, išjungti – tinkamas avarinis stabdis, laukti pateisinama tik su įrodymu. Kas sąžiningai atsako į penkis klausimus ir sprendimą užfiksuoja raštu, veikia pagal BSI rekomendaciją ir vėliau gali parodyti, kodėl.

Dažni klausimai

Ar dėl PHP2Shell turiu išjungti savo svetainę?

Ne, jei PHP jau veikia ištaisytos būsenos ir visi procesai paleisti iš naujo. BSI rekomenduoja laikiną išjungimą tuo atveju, kai iškart atnaujinti neįmanoma.

Kas brangiau kainuoja: išjungimas ar rizika?

Atsakyti galima tik kiekvienu atveju atskirai. Kelių valandų prastova dažniausiai geriau planuojama nei įsilaužimas, kurio pasekmių ir trukmės niekas nežino. Svarstymą užfiksuokite raštu, nepriklausomai nuo rezultato.

Ar priežiūros puslapis gali veikti tame pačiame serveryje?

Taip, jei jis pateikiamas kaip statinis failas be PHP. Jei priežiūros puslapį toliau generuoja PHP, atakos paviršius išlieka.

Ar laukti kada nors yra teisingas pasirinkimas?

Taip, aiškiai apibrėžtais atvejais: kai sistemoje PHP neveikia, kai ji nepasiekiama iš interneto arba kai teikėjas raštu patvirtino pataisą ir paleidimą iš naujo. Laukti be tokių įrodymų nėra variantas, o rizika.

Kas turėtų priimti sprendimą?

Asmuo, atsakingas už verslo riziką, paprastai vadovybė ar savininkas. IT pateikia faktus. Kas sprendžia, turėtų būti iš anksto nurodyta avariniame plane.

Šaltiniai

Skubus kontaktas

Kiekviena valanda svarbi. Parašykite mums dabar.

Trumpai aprašykite sistemą, PHP versiją ir pastebėjimus. Mes atsakysime, išsiaiškinsime padėtį ir dirbsime nuotoliu, kol incidentas bus užbaigtas ir dokumentuotas.

Skubi pagalba