Trumpai: Esant PHP pažeidžiamumui, kaip PHP2Shell, hostinge už PHP atnaujinimą atsako hostingo teikėjas, o ne jūs. Jūsų užduotis yra gauti raštišką patvirtinimą, kliento meniu pasirinkti palaikomą PHP versiją ir patikrinti svetainę dėl atakos pėdsakų. Hostingo teikėjo pataisa nepašalina kenkėjiškos programinės įrangos, kuri į jūsų svetainę pateko anksčiau.
Padėtis paprastais žodžiais
PHP yra programavimo kalba, kuria veikia dauguma svetainių, parduotuvių ir CMS, pavyzdžiui, WordPress. PHP2Shell yra dvi kritinės klaidos pačiame PHP (CVE-2026-109618 ir CVE-2026-109619). Per jas užpuolikai gali be slaptažodžio vykdyti savo kodą serveryje. BSI (Vokietijos Federalinė informacijos saugumo tarnyba) paskelbė 3 įspėjimo lygį (oranžinį) ir rekomenduoja nedelsiant atnaujinti.
Bendrinamame hostinge daug klientų dalijasi vienu serveriu. Po tuo esančią techniką, t. y. operacinę sistemą, žiniatinklio serverį ir PHP, eksploatuoja hostingo teikėjas. Jūs patys valdote tik savo svetainę, duomenų bazę ir prieigas. Todėl PHP atnaujinimo patys įdiegti negalite ir neturite.
Hostingas ir PHP pažeidžiamumas: kas atsakingas?
Pasiskirstymas išplaukia iš jūsų sutarties. Daugumoje tarifų galioja maždaug toks pasiskirstymas:
| Užduotis | Hostingo teikėjas | Jūs kaip klientas |
|---|---|---|
| Atnaujinti PHP paketus | taip | ne |
| Paleisti iš naujo PHP procesus | taip | ne |
| Nustatyti visam serveriui galiojančias pereinamąsias reikšmes | taip | ne |
| Pasirinkti savo svetainės PHP versiją | suteikia galimybę | pasirenka |
| Atnaujinti CMS, įskiepius, temas | ne | taip |
| Prisijungimo duomenys ir administratorių paskyros | ne | taip |
| Patikrinti svetainę dėl kenkėjiško kodo | iš dalies | taip |
| Duomenų apsaugos vertinimas | ne | taip |
Svarbi paskutinė eilutė: jei jūsų svetainėje įvyksta incidentas su asmens duomenimis, paprastai atsakingas esate jūs kaip operatorius, o ne hostingo teikėjas. Daugiau apie tai skyriuje BDAR pranešimo pareiga.
Ką dabar turėtumėte daryti patys
1. Gaukite patvirtinimą. Raštu paklauskite hostingo teikėjo, ar jūsų paketo PHP versijos apsaugotos nuo abiejų CVE, nuo kada ir ar visi PHP procesai buvo paleisti iš naujo. Paruoštą šabloną rasite puslapyje Paklauskite hostingo teikėjo apie pataisų būseną. Nenustebkite, jei kliento meniu ir toliau nurodytas senesnis versijos numeris, pavyzdžiui, 8.2.34: kai kurie teikėjai pataisymus pateikia kaip backport, nepakeisdami numerio.
2. Patikrinkite PHP versiją. Kliento meniu pažiūrėkite, kokią PHP versiją naudoja jūsų svetainė. PHP 8.1 ir senesnės versijos iš PHP projekto oficialių atnaujinimų nebegauna. PHP 8.2 palaikymas baigiasi 2026-12-31. Ar jūsų CMS tinka naujesnei versijai, patikrinkite pagal gamintojo sistemos reikalavimus, pavyzdžiui, wordpress.org.
3. Patikrinkite svetainę. Atkreipkite dėmesį į nepažįstamas administratorių paskyras, netikėtus peradresavimus, svetimus failus FTP prieigoje ir įspėjimus Google Search Console. Tipinių požymių sąrašas pateiktas puslapyje Ar jau esu kompromituotas?.
4. Sukurkite atsarginę kopiją. Atsisiųskite naujausią failų ir duomenų bazės atsarginę kopiją ir saugokite ją atskirai. Be to, paprašykite hostingo teikėjo išsaugoti jūsų paketo prieigos žurnalus nuo 2026-10-20.
Po hostingo teikėjo patvirtinimo iš anksto pakeiskite kliento meniu, FTP/SFTP, duomenų bazės ir CMS administratorių slaptažodžius ir, kur įmanoma, įjunkite dviejų veiksnių prisijungimą.
Ko bendrinamame hostinge patys išspręsti negalite
php.net rekomenduojamos pereinamosios priemonės, pavyzdžiui, session.upload_progress.enabled=0, veikia tik tada, kai nustatytos serverio konfigūracijoje. Įrašas .user.ini faile ar per ini_set() kode, pasak php.net, nepakanka. Atminties ribos cgroup lygmeniu ir PHP procesų paleidimas iš naujo taip pat yra hostingo teikėjo reikalas.
Jei hostingo teikėjas neatsako arba atsako vengdamas, turite tris galimybes: priminti ir nustatyti terminą, laikinai perjungti svetainę į priežiūros režimą arba pereiti pas teikėją, kuris pateikia aiškų atsakymą. BSI rekomenduoja laikinai atjungti žiniatinklio serverius nuo tinklo, jei atnaujinimas nedelsiant neįmanomas.
Be to, patikrinkite, ar jūsų tarifas dar atitinka laikmetį. Paketai, kurie daug metų veikia nepakitę, kartais yra senesnėse serverių kartose su senesnėmis PHP versijomis, kurias teikėjas prižiūri tik ribotai. Perėjimas prie naujo to paties teikėjo tarifo dažnai pareikalauja nedaug pastangų ir atneša naujesnes PHP versijas. Paklauskite apie tai, jei atsakymas dėl pataisų būsenos netenkina.
Jei svetainė jau kelia įtarimų
Hostingo teikėjo pataisa uždaro pažeidžiamumą ateičiai. Bet ji nepašalina užpakalinių durų, kurias užpuolikai įrengė anksčiau, ir neįrodo, kad anksčiau nieko neįvyko. Jei pastebite anomalijų, netrinkite failų atsitiktinai. Pirmiausia išsaugokite būseną, kad vėliau būtų galima atsekti priežastį.
Kaip PHP SOS padeda konkrečiai?
- Kartu su jumis suformuluojame užklausą hostingo teikėjui ir techniškai įvertiname jo atsakymą.
- Tikriname jūsų svetainę dėl webshell, svetimų paskyrų ir pakeistų failų ir radus išvalome per mūsų kenkėjiškos programinės įrangos šalinimą.
- Esant ūmiam įtarimui perimame avarinę pagalbą nulaužtoms svetainėms su įrodymų išsaugojimu.
- Padedame pasirinkti tinkamą PHP versiją ir po to išbandome svetainę.
Dažni klausimai
Ar kaip hostingo klientas turiu pats atnaujinti PHP?
Paprastai ne, nes bendrinamame hostinge PHP priklauso hostingo teikėjo platformai. Tačiau kliento meniu dažnai galite pasirinkti PHP versiją. Jei ten nurodyta versija be oficialių atnaujinimų, turėtumėte pakeisti ją arba paklausti teikėjo, kaip jis ją apsaugo.
Mano svetainė neveikia. Ar buvau nulaužtas?
Nebūtinai. Kai kurie teikėjai prevenciškai atjungė svetaines nuo tinklo, kad uždarytų pažeidžiamumą. Paklauskite hostingo teikėjo apie priežastį ir paprašykite patvirtinti, ar yra požymių, kad buvo užpulta jūsų paketas.
Ar pereinamąsias priemones galiu pats nustatyti .user.ini faile?
Dėl session.upload_progress.enabled php.net aiškiai nurodo, kad .user.ini ir ini_set() nepakanka. Šį nustatymą hostingo teikėjas turi nustatyti serverio konfigūracijoje.
Ką turėčiau turėti raštu iš hostingo teikėjo?
Patvirtinimą, kad jūsų paketo PHP versijos apsaugotos nuo CVE-2026-109618 ir CVE-2026-109619, nuo kada tai galioja ir kad PHP procesai buvo paleisti iš naujo. Šį atsakymą saugokite kartu su savo dokumentais.