Trumpai: Kas nori, kad PHP spraga PHP2Shell būtų uždaryta jau šiandien, reikia keturių dalykų: tinkamo atnaujinimo, visų PHP procesų paleidimo iš naujo, patikros dėl jau įterpto kenkėjiško kodo ir įrodymo. Ar tai jus palietė? Skambinkite. Padėsime. Tai atliekame nuotoliu, nuo pirmos žinutės.
Dabar nieko netrinkite ir neįrenkite iš naujo. Ir pataisant galioja taisyklė: pirmiausia išsaugoti, tada keisti. Jei kas nors jau įsiskverbė, mums reikia failų ir žurnalų būsenos. Pranešti apie avariją, kartu išsiaiškinsime eiliškumą.
Kodėl spraga negali laukti
Abi spragos, CVE-2026-109618 ir CVE-2026-109619, slypi pačiame PHP ir leidžia vykdyti kenkėjišką kodą nuotoliu be prisijungimo. BSI paskelbė 3 (oranžinį) įspėjimo lygį ir rekomenduoja nedelsiant atnaujinti. Jei to padaryti iš karto neįmanoma, žiniatinklio serverius reikia laikinai atjungti nuo tinklo. Pasak žiniasklaidos pranešimų, pirmieji atakos bandymai buvo pastebėti dar prieš pataisų paskelbimą 2026 m. spalio 21 d. Cloudflare stebėjo bandymus ir įdiegė apsaugos taisykles, bet perspėja, kad taisyklių vien pagal užklausos duomenis nepakanka.
Svarbu operatoriams: CMS atnaujinimas PHP spragos neuždaro. Pasak pranešimų, ir WordPress.org nenumato atnaujinimo prieš ją, nes spraga yra interpretatoriuje. Ji uždaroma tik PHP lygmenyje, t. y. tame, ką jūsų serveris iš tikrųjų vykdo.
Ką daryti nedelsiant
- Žinokite tikslinę versiją. Ištaisytos PHP 8.5.12, 8.4.27, 8.3.36 ir 8.2.35. PHP 8.2 palaikymas baigiasi 2026 m. gruodžio 31 d., įtraukite tai į planą.
- Suregistruokite visas sistemas. Taip pat testavimo serverius, konteinerių atvaizdus ir senas sistemas, pasiekiamas iš interneto.
- Išsiaiškinkite atsakomybę. Hostingo paketuose ir valdomuose serveriuose atnaujina teikėjas. Raštu paklauskite apie versiją ir paleidimą iš naujo.
- Saugokite žurnalus. Nuo 2026 m. spalio 20 d., pasak specializuotos spaudos.
- Suderinkite laiką. Paleidimas iš naujo trumpam nutraukia vykdomas užklausas. Nustatykite laiką, kai yra kas priima sprendimus.
- Nelaukite, jei atvira. Jei iš karto pataisyti neįmanoma, kartu su mumis apsvarstykite atskyrimą arba pereinamąsias priemones.
Kaip PHP SOS padeda konkrečiai?
- Įvertiname padėtį: užfiksuojame sistemas, PHP versijas, veikimo režimus, hostingo teikėjus ir pasiekiamumą bei nustatome eiliškumą: pirmiausia labiausiai atviros sistemos.
- Išsaugome ir uždarome: išsaugome esamą būseną, įdiegiame atnaujinimą arba pakeliame hostingą iki įrodytai pataisytos būsenos ir iš naujo paleidžiame visus procesus. Konteineriuose iš naujo sukuriame atvaizdą (image) ir jį išleidžiame.
- Tikriname ir valome: kadangi pataisa kenkėjiško kodo nepašalina, tikriname, ar nėra ankstesnio įsilaužimo požymių, ir prireikus išvalome.
- Sutvirtiname ir pateikiame ataskaitą: gaunate raštišką įrodymą kiekvienai sistemai ir rekomendacijas, kad kitas atnaujinimas vyktų greičiau. Paslaugos pobūdį aprašo PHP pataisų paslauga.
Atnaujinimas, paleidimas iš naujo, įrodymas: kas svarbu
Dažniausia klaida yra atnaujinimas be paleidimo iš naujo. Kol atmintyje veikia seni procesai, pažeidžiamas kodas lieka aktyvus, net jei failai nauji. Instrukcija pateikta puslapyje PHP-FPM ir visų darbinių procesų paleidimas iš naujo. Antra klaida yra tikėti rodiniu: distribucijos ir hostingo teikėjai dažnai teikia backport, ir tada versijos numeris lieka tas pats. Patikimas yra paketo pakeitimų žurnalas su CVE numeriais, Debian šeimoje su apt-get changelog <paket>.
Be to, pagal PHP vadovą nuo saugumo leidimų galioja nauja direktyva memory_hard_limit_percent. Jei PHP versija jos nepažįsta, ji paveikta. Testas trumpas:
php -r 'var_dump(ini_get("memory_hard_limit_percent"));'
Jį reikia vykdyti kiekvienai versijai ir veikimo režimui, nes komandinė eilutė gali naudoti kitą PHP versiją nei žiniatinklio serveris. Pabaigoje užfiksuojame rezultatą, kad galėtumėte jį parodyti savo hostingo teikėjui, draudikui ar užsakovui.
Kai atnaujinti iš karto neįmanoma
Yra priežasčių, kodėl šiandien atnaujinti nepavyksta: sena programa, kuri naujesnėse PHP versijose neveikia, hostingo teikėjas be leidimo, konteinerio atvaizdas (image) fiksuotame procese. Tokiems atvejams php.net nurodo pereinamąsias priemones, kurios aiškiai nėra visiška apsauga: nustatyti memory_limit=-1 taip, kad programos jo negalėtų perrašyti, apriboti post_max_size, session.upload_progress.enabled=0, o PHP 8.5 fatal_error_backtraces=0, visais atvejais paleidžiant iš naujo. Be to, taikomos apsaugos taisyklės pakraštyje, kurios atnaujinimo neatstoja. Platinamas patarimas blokuoti visas užklausas su PHPSESSID specializuotų autorių aiškiai atmetamas.
Kokios priemonės tinka jūsų sistemai ir ką jos gali sugadinti, aptariame iš anksto. Daugiau puslapyje Skubios priemonės, kai dar negalite pataisyti ir temoje WAF ir virtualus pataisymas. PHP 8.1 ir senesnėms galioja atskira padėtis, aprašyta puslapyje PHP 8.1 ir senesnės: kas dabar galioja.
Ką mums atsiųsti
- Serverių ir hostingo teikėjų sąrašas, jei yra
php -višvestis kiekvienoje sistemoje ir nuoroda į veikimo režimą- Ar naudojami konteineriai, Plesk, cPanel ar valdomas (managed) pasiūlymas
- Pageidaujamas laiko langas ir kontaktinis asmuo paleidimui iš naujo
- Pastebėjimai apie neįprastus dalykus nuo 2026 m. spalio 17 d.
Kodėl PHP SOS
Dirbame Made in Germany ir kartu su savo kibernetinių specialistų partnerių tinklu daugiau nei 25 metus specializuojamės IT saugumo srityje. Turite vieną kontaktinį asmenį, kuris lydi atnaujinimą, tikrina paleidimą iš naujo ir pateikia įrodymą. Dirbame nuotoliu, be atvykimo, ir dokumentuojame kiekvieną žingsnį. Nežadame stebuklų: pataisa uždaro spragą, bet neįrodo, kad anksčiau nieko neįvyko, ir tai sakome jums atvirai.
Ar tai jus palietė? Skambinkite. Padėsime.
Nepalikite spragos ilgiau atviros. Paskambinkite arba parašykite per WhatsApp. Perimame darbą nuo pirmos žinutės ir pasiliekame, kol incidentas bus užbaigtas ir dokumentuotas. Pranešti apie avariją dabar.
Dažni klausimai
Ar PHP saugumo spragą galiu uždaryti pats, ar man reikia pagalbos?
Administratoriams atnaujinimas įmanomas, bet linkęs klysti: reikia, kad galiotų versija, kuri iš tikrųjų aptarnauja užklausas, ir kad būtų paleisti iš naujo visi procesai. Kas turi kelis serverius, konteinerių atvaizdus (image) ar hostingo teikėją su ypatumais, su pagalba sutaupo laiko ir išvengia klaidų.
Ar PHP po atnaujinimo reikia paleisti iš naujo?
Taip. Naujų failų nepakanka, kol atmintyje veikia seni PHP procesai. Visi darbiniai procesai (worker) turi būti paleisti iš naujo, o esant mod_php žiniatinklio serveris.
Ką daryti, jei mano PHP versijai dar nėra atnaujinimo?
8.1 ir senesnėms PHP projektas oficialių atnaujinimų nebeteikia. Tuomet reikia įrodytai pataisyto teikėjo backport, perėjimo prie prižiūrimos versijos arba pereinamųjų priemonių, kurios, tiesa, visiškos apsaugos nesuteikia.
Ar pakanka nustatyti session.upload_progress.enabled į 0?
Ne. Pasak specialistų pranešimų, vien šis nustatymas neuždaro abiejų spragų, PHP atnaujinimas išlieka privalomas. Nustatykite jį tik php.ini, FPM baseine ar serverio konfigūracijoje, o ne per ini_set() ar .user.ini.
Iš ko žinosiu, kad spraga po to tikrai uždaryta?
Iš įrodymo veikiančioje sistemoje: versijos ar paketo pakeitimų žurnalo, naujos direktyvos memory_hard_limit_percent testo ir patvirtinimo, kad po atnaujinimo visi procesai paleisti iš naujo.