Aktuālā situācija: PHP2Shell. Divas kritiskas PHP ievainojamības (CVSS 9.2) ļauj izpildīt ļaunprātīgu kodu bez pieteikšanās. Ielāpi kopš 21.10.2026.Kas jādara tagad →

PHP2Shell: 15 hostinga klientu jautājumu

Jūsu vietne atrodas pie hostinga sniedzēja, un vēlaties zināt, kas jums PHP2Shell gadījumā jādara pašam? Šeit 15 biežākie jautājumi ar īsām atbildēm.

Aktuāls uz 4 min lasīšanas laiksSituācija un vērtējums

Īsi sakot: Ko darīt hostinga klientam PHP ievainojamības PHP2Shell gadījumā? PHP atjauninājums jums parasti nav jāievieš pašam, koplietošanas hostingā to dara hostinga sniedzējs. Jūsu uzdevumi ir citi: iegūt rakstisku ielāpa stāvokļa apstiprinājumu, klienta izvēlnē izvēlēties atbalstītu PHP versiju un pārbaudīt savu vietni, vai nav novirzes. Šis raksts uz 15 biežākajiem jautājumiem atbild īsi un pēc kārtas.

PHP ievainojamība hostinga klientam: vai esmu skarts, ko darīt?

Kopš 2026. gada 21. oktobra mums nāk daudz jautājumu no uzņēmumiem, kuru vietne atrodas pie hostinga sniedzēja. Lielākā daļa attiecas uz vieniem un tiem pašiem punktiem. Kas atbildības vēlas izlasīt plašāk, atradīs tās sadaļā Koplietošanas hostings: ko dara hostinga sniedzējs un kas jādara jums.

1. Vai mana vietne vispār ir skarta?

Ja jūsu vietne darbojas ar WordPress, Shopware, TYPO3, Joomla, Contao vai citu PHP sistēmu, serveris zem tās, iespējams, ir skarts. Tīras HTML lapas bez PHP nav. Šaubu gadījumā palīdz skatiens klienta izvēlnē: ja tur ir PHP versijas iestatījums, jūs izmantojat PHP.

2. Kāda ir atšķirība starp koplietošanas hostingu un savu serveri?

Koplietošanas hostingā jūs dalāties ar citiem klientiem hostinga sniedzēja uzturētā serverī; hostinga sniedzējs apkopj PHP. Pie sava root servera vai vServer atbildat jūs paši. Pārvaldīta servera gadījumā līgums nosaka, kurš ievieš atjauninājumus.

3. Mans hostinga sniedzējs ir izsūtījis kopēju e-pastu. Vai man vēl kaut kas jādara?

Izlasiet precīzi, kas tajā rakstīts. Kopējs e-pasts bieži apstiprina tikai to, ka hostinga sniedzējs “strādā pie jautājuma”. Jums vajag apgalvojumu par jūsu pakotni: PHP atzars, ielāpa stāvoklis, laiks un pārstartēšana.

Atbildība un atjauninājums

4. Vai hostinga sniedzējs atjauninājumu ievieš automātiski?

Parasti jā, PHP versijām, ko viņš savos serveros piedāvā. Vai tas jau ir noticis un vai aptvertas arī vecākas versijas, atšķiras no hostinga sniedzēja uz hostinga sniedzēju. Pajautājiet.

5. Mana klienta izvēlne rāda veco versijas numuru. Vai esmu neaizsargāts?

Ne obligāti. Daudzi hostinga sniedzēji labojumus ievieš kā backport, numurs tad paliek tāds pats. Plesk, piemēram, var turpināt rādīt 8.2.34, kaut gan kļūda ir novērsta. Noteicošais ir hostinga sniedzēja apstiprinājums.

6. Es vēl izmantoju PHP 7.4 vai 8.1. Ko tagad?

Šie atzari no PHP projekta oficiālus atjauninājumus vairs nesaņem. Daži hostinga sniedzēji piegādā savus labojumus, citi ne. Noskaidrojiet to rakstiski un plānojiet pāreju uz atbalstītu atzaru. Iepriekš savā CMS sistēmas prasībās pārbaudiet, kuras PHP versijas tas atbalsta.

7. Vai PHP versiju varu pārslēgt pats?

Pie lielākās daļas hostinga sniedzēju jā, klienta izvēlnē. Kā tas notiek un uz ko iepriekš jāpievērš uzmanība, apraksta raksts PHP versijas maiņa hostinga klienta sadaļā. Iepriekš izveidojiet rezerves kopiju.

8. Vai palīdz WordPress vai spraudņu atjaunināšana?

Pret PHP2Shell nē, jo ievainojamība ir PHP. CMS atjauninājumi tomēr ir noderīgi, jo tie aizver citas ievainojamības.

Pārbaude un apliecinājums

9. Kā saņemt apliecinājumu no hostinga sniedzēja?

Ar rakstisku pieprasījumu, kas prasa konkrētus datus: pakotņu stāvoklis katram PHP atzaram, instalēšanas datums, visu PHP procesu pārstartēšana. Kopējamu paraugu piedāvā ceļvedis Pieprasīt hostinga sniedzēja PHP atjauninājuma apstiprinājumu.

10. Vai pagaidu pasākumus varu iestatīt ar .user.ini?

Nē. php.net tieši neiesaka pagaidu iestatījumus iestatīt ar ini_set() vai .user.ini. Tie pieder servera konfigurācijā, un koplietošanas hostingā to pārvalda hostinga sniedzējs.

11. Mana vietne bija uz brīdi bezsaistē. Vai mani uzlauza?

Ne obligāti. Daži hostinga sniedzēji vietnes ir piesardzības nolūkā atslēguši vai serverus pārstartējuši. Pajautājiet par iemeslu, pirms izdarāt secinājumus.

12. Pēc kā var atpazīt, ka manai vietnei ir uzbrukts?

Iespējamas norādes ir nezināmi administratoru konti, jauni PHP faili augšupielādes mapē, novirzīšana uz svešām lapām, svešas lapas Google indeksā vai brīdinājumi Search Console. Lūdziet hostinga sniedzējam saglabāt piekļuves žurnālus no 20. oktobra.

Ja kaut kas nav kārtībā

13. Hostinga sniedzējs neatbild vai izvairās. Ko darīt?

Jautājiet rakstiski un nosakiet saprātīgu termiņu. Ja atbildes nav, serveris jāuztver kā nepārbaudīts, un jāapsver vietnes uz laiku pārslēgšana uz statisku paziņojuma lapu.

14. Vai man jāmaina hostinga sniedzējs?

Maiņa situācijas vidū rada savus riskus. Tā ir saprātīga, ja hostinga sniedzējs pastāvīgi nesniedz informāciju vai turpina uzturēt vecas PHP versijas bez labojuma. Kas šajā gadījumā jāņem vērā, apraksta Hostinga sniedzēja maiņa pēc incidenta.

15. Vai man kaut kas jāpaziņo?

Ja ir norādes uz uzbrukumu un var būt skarti personas dati, var pastāvēt ziņošanas pienākums saskaņā ar VDAR, parasti 72 stundu laikā. Noskaidrojiet to ar savu datu aizsardzības speciālistu vai advokātu. Šī nav juridiska konsultācija.

Jūsu īsais kontrolsaraksts

  1. Rakstiski pajautāt hostinga sniedzējam par ielāpa stāvokli un pārstartēšanu.
  2. Pārbaudīt PHP versiju klienta izvēlnē, novecojušos atzarus nomainīt.
  3. Pārskatīt administratoru kontus un augšupielādes mapi.
  4. Pārbaudīt Search Console brīdinājumus.
  5. Novirzes gadījumā meklēt palīdzību, pirms dzēšat failus.

Kā PHP SOS palīdz konkrēti?

  • Noskaidrošana ar hostinga sniedzēju: Mēs formulējam pieprasījumu vai vadām sarunu un novērtējam atbildi.
  • Vietnes pārbaude: Mēs meklējam pēdas failos, datubāzē un kontos, ciktāl to ļauj hostinga pakotne.
  • Attīrīšana: Ja atrodam ļaunprātīgu kodu, to noņemam un nomainām visu piekļuvi.
  • Dokumentācija: Jūs saņemat stāvokli rakstiski.

Konkrētu aizdomu gadījumā palīdz ārkārtas palīdzība uzlauztām vietnēm.

Secinājums

Kā hostinga klients PHP2Shell gadījumā jūs nenesat atjauninājuma slogu, bet nesat atbildību par savu vietni. Lielāko daļu jautājumu var atrisināt ar skaidru hostinga sniedzēja rakstisku atbildi. Pēc tam paliek skats uz savu vietni: konti, faili, Google norādes. Kas ir izdarījis abus, savu daļu ir paveicis un šaubu gadījumā var pierādīt, ka rīkojies rūpīgi.

Biežāk uzdotie jautājumi

Kurš tīmekļa hostingā ir atbildīgs par PHP atjauninājumu?

Koplietošanas hostingā parasti hostinga sniedzējs, jo viņš uztur serveri un PHP instalāciju. Jūs atbildat par savu vietni, savu piekļuvi un PHP versijas izvēli klienta izvēlnē. Pārvaldītu serveru gadījumā sadalījumu nosaka līgums.

Kāpēc mans hostinga sniedzējs rāda veco PHP versiju?

Daudzi hostinga sniedzēji un distributīvi labojumu ievieš kā backport esošajā versijā. Numurs tad paliek tāds pats, kaut gan ievainojamība ir aizvērta. Tāpēc paļaujieties uz hostinga sniedzēja rakstisku apstiprinājumu, nevis uz rādījumu.

Ko es kā hostinga klients varu pārbaudīt pats?

Varat pārbaudīt iestatīto PHP versiju klienta izvēlnē, pārskatīt sava CMS administratoru kontus, pavērot nezināmus failus augšupielādes mapē un pārbaudīt Search Console brīdinājumus. Paša servera ielāpa stāvokli var apliecināt tikai hostinga sniedzējs.

Vai palīdz ugunsmūra iestatījums hostinga pakotnē?

Hostinga sniedzēja vai priekšā ieslēgta pakalpojuma ugunsmūra noteikumi var samazināt risku. Taču tie neaizstāj PHP atjauninājumu serverī. Tāpēc vienmēr vispirms jautājiet par atjauninājumu.

Avoti

Tūlītējs kontakts

Katra stunda ir svarīga. Rakstiet mums tūlīt.

Īsi aprakstiet sistēmu, PHP versiju un novēroto. Mēs sazināsimies, noskaidrosim situāciju un strādāsim attālināti, līdz incidents ir slēgts un dokumentēts.

Tūlītēja palīdzība