Īsi: PHP ievainojamības, piemēram, PHP2Shell, gadījumā tīmekļa hostingā par PHP atjauninājumu atbild hostinga sniedzējs, nevis jūs. Jūsu uzdevums ir saņemt rakstisku apstiprinājumu, klientu izvēlnē izvēlēties atbalstītu PHP versiju un pārbaudīt, vai vietnē nav uzbrukuma pēdu. Sniedzēja ielāps nenoņem ļaunprātīgu programmatūru, kas jūsu vietnē nokļuva iepriekš.
Situācija vienkāršiem vārdiem
PHP ir programmēšanas valoda, uz kuras darbojas lielākā daļa vietņu, veikalu un CMS, piemēram, WordPress. PHP2Shell ir divas kritiskas kļūdas pašā PHP (CVE-2026-109618 un CVE-2026-109619). Caur tām uzbrucēji bez paroles var izpildīt savu kodu serverī. BSI ir izsludinājis 3. brīdinājuma līmeni (oranžs) un iesaka nekavējoties atjaunināt.
Shared hostingā vienu serveri dala daudzi klienti. Tehniku zem tā, tātad operētājsistēmu, tīmekļa serveri un PHP, uztur sniedzējs. Jūs paši pārvaldāt tikai savu vietni, datubāzi un piekļuves. Tāpēc PHP atjauninājumu jūs nevarat ieinstalēt pats, un jums tas nav jādara.
Tīmekļa hostings un PHP ievainojamība: kurš par ko atbild?
Sadalījums izriet no jūsu līguma. Lielākajā daļā tarifu aptuveni spēkā ir šāds sadalījums:
| Uzdevums | Hostinga sniedzējs | Jūs kā klients |
|---|---|---|
| Atjaunināt PHP pakotnes | jā | nē |
| Pārstartēt PHP procesus | jā | nē |
| Iestatīt servera mēroga pagaidu vērtības | jā | nē |
| Izvēlēties savas vietnes PHP versiju | nodrošina | izvēlas |
| Atjaunināt CMS, spraudņus, tēmas | nē | jā |
| Piekļuves dati un administratoru konti | nē | jā |
| Pārbaudīt vietni, vai nav ļaunprātīga koda | daļēji | jā |
| Datu aizsardzības tiesiskais izvērtējums | nē | jā |
Svarīga ir pēdējā rinda: ja jūsu vietnē notiek incidents ar personas datiem, parasti atbildat jūs kā operators, nevis hostinga sniedzējs. Vairāk par to lapā VDAR ziņošanas pienākums.
Ko jums tagad vajadzētu darīt pašam
1. Saņemiet apstiprinājumu. Rakstiski vaicājiet hostinga sniedzējam, vai jūsu pakotnes PHP versijas ir aizsargātas pret abām CVE, kopš kura laika un vai visi PHP procesi ir pārstartēti. Gatavu paraugu atradīsiet lapā Kā vaicāt hostinga sniedzējam par ielāpa stāvokli. Nebrīnieties, ja klientu izvēlnē joprojām ir vecāks versijas numurs, piemēram, 8.2.34: daži sniedzēji labojumus piegādā kā backportu, un numurs nemainās.
2. Pārbaudiet PHP versiju. Klientu izvēlnē apskatiet, kuru PHP versiju izmanto jūsu vietne. PHP 8.1 un vecākām versijām PHP projekts oficiālus atjauninājumus vairs nesniedz. PHP 8.2 atbalsts beidzas 2026. gada 31. decembrī. Vai jūsu CMS atbalsta jaunāku versiju, pārbaudiet pēc ražotāja sistēmas prasībām, piemēram, vietnē wordpress.org.
3. Pārbaudiet vietni. Pievērsiet uzmanību nezināmiem administratoru kontiem, negaidītām novirzēm, svešiem failiem FTP piekļuvē un brīdinājumiem Google Search Console. Tipisku pazīmju saraksts atrodams lapā Vai mani jau ir kompromitējuši?.
4. Izveidojiet rezerves kopiju. Lejupielādējiet aktuālu failu un datubāzes kopiju un glabājiet to atsevišķi. Lūdziet sniedzējam arī saglabāt jūsu pakotnes piekļuves žurnālus no 2026. gada 20. oktobra.
Pēc sniedzēja apstiprinājuma saņemšanas preventīvi nomainiet paroles klientu izvēlnei, FTP/SFTP, datubāzei un CMS administratoriem un, kur iespējams, aktivizējiet divfaktoru autentifikāciju.
Ko shared hostingā jūs paši atrisināt nevarat
php.net ieteiktie pagaidu pasākumi, piemēram, session.upload_progress.enabled=0, darbojas tikai tad, ja tie ir iestatīti servera konfigurācijā. Ieraksts .user.ini vai ini_set() kodā saskaņā ar php.net nav pietiekams. Arī atmiņas ierobežojumi cgroup līmenī un PHP procesu pārstartēšana ir sniedzēja pusē.
Ja sniedzējs neatbild vai atbild izvairīgi, jums ir trīs iespējas: atgādināt un noteikt termiņu, vietni uz laiku pārslēgt uzturēšanas režīmā vai pāriet pie sniedzēja ar skaidru atbildi. BSI iesaka tīmekļa serverus uz laiku atvienot no tīkla, ja atjauninājumu nevar ieviest nekavējoties.
Pārbaudiet arī, vai jūsu tarifs vēl ir mūsdienīgs. Pakotnes, kas daudzus gadus darbojas nemainīgi, dažkārt atrodas uz vecākas paaudzes serveriem ar vecākām PHP versijām, ko sniedzējs uztur tikai ierobežoti. Pāreja uz aktuālu tā paša sniedzēja tarifu bieži prasa maz pūļu un nodrošina jaunākas PHP versijas. Pajautājiet par to, ja atbilde par ielāpa stāvokli neapmierina.
Ja vietne jau izskatās aizdomīgi
Sniedzēja ielāps aizver ievainojamību nākotnei. Tas tomēr nenoņem aizmugures durvis, ko uzbrucēji ir izveidojuši iepriekš, un nepierāda, ka iepriekš nekas nav noticis. Ja atrodat aizdomīgas pazīmes, nedzēsiet failus bez izšķirības. Vispirms saglabājiet stāvokli, lai cēloni vēlāk varētu izsekot.
Kā PHP SOS palīdz konkrēti?
- Mēs kopā ar jums formulējam vaicājumu hostinga sniedzējam un tehniski novērtējam tā atbildi.
- Mēs pārbaudām jūsu vietni, vai tajā nav webshell, svešu kontu un manipulētu failu, un atradumu gadījumā tīrām to ar savu ļaunprātīgās programmatūras noņemšanu.
- Akūtu aizdomu gadījumā mēs uzņemamies ārkārtas palīdzību uzlauztām vietnēm ar pierādījumu nodrošināšanu.
- Mēs palīdzam izvēlēties piemērotu PHP versiju un pēc tam testējam vietni.
Biežāk uzdotie jautājumi
Vai man kā hostinga klientam PHP jāatjaunina pašam?
Parasti nē, jo shared hostingā PHP ir sniedzēja platformas daļa. Taču klientu izvēlnē bieži var izvēlēties PHP versiju. Ja tur ir versija bez oficiāliem atjauninājumiem, mainiet to vai vaicājiet sniedzējam, kā tā tiek aizsargāta.
Mana vietne nav pieejama. Vai mani uzlauza?
Ne obligāti. Daži sniedzēji ir preventīvi atvienojuši vietnes no tīkla, lai aizvērtu ievainojamību. Vaicājiet sniedzējam par iemeslu un lūdziet apstiprināt, vai ir norādes uz uzbrukumu jūsu pakotnei.
Vai pagaidu pasākumus drīkstu iestatīt pats failā .user.ini?
Attiecībā uz session.upload_progress.enabled php.net skaidri norāda, ka ar .user.ini un ini_set() nepietiek. Šo iestatījumu sniedzējam jāiestata servera konfigurācijā.
Kas man jābūt rakstiski no hostinga sniedzēja?
Apstiprinājums, ka jūsu pakotnes PHP versijas ir aizsargātas pret CVE-2026-109618 un CVE-2026-109619, kopš kura laika tas ir spēkā un ka PHP procesi ir pārstartēti. Glabājiet šo atbildi kopā ar saviem dokumentiem.