Īsi: pēc PHP2Shell redzamā PHP versija vien pierāda maz, jo hostinga sniedzēji labojumus bieži ievieš kā backportu. Tāpēc pieprasiet rakstisku hostinga sniedzēja PHP atjauninājuma apstiprinājumu: pakotnes stāvokli katram PHP atzaram, uzstādīšanas laiku un visu PHP procesu pārstartēšanu. Paraugu kopēšanai atradīsiet tālāk.
Kāpēc rakstisks apstiprinājums ir svarīgs tieši tagad
- gada 21. oktobrī PHP projekts publicēja ielāpus divām kritiskām ievainojamībām, kas pazīstamas ar nosaukumu PHP2Shell. Abas ļauj attālināti izpildīt ļaunprātīgu kodu bez pieteikšanās. BSI (Vācijas Federālais informācijas drošības birojs) ir izsludinājis brīdinājuma līmeni 3 / oranžs un iesaka nekavējoties atjaunināt.
Ja vietne darbojas pie hostinga sniedzēja, atjauninājumu bieži nevar uzstādīt pats. Vienlaikus jūs kā operators esat atbildīgs par savu klientu datiem. Rakstisks, konkrēts hostinga sniedzēja apstiprinājums tāpēc nav tikai formalitāte. Tas ir jūsu dokumentācijas elements, piemēram, attiecībā pret datu aizsardzības speciālistiem, apdrošinātājiem vai vadību.
Turklāt: ielāps neizņem ļaunprogrammatūru, kas ievadīta iepriekš. Saskaņā ar plašsaziņas līdzekļu ziņojumiem jau 17.10. bija pirmais novērotais uzbrukuma mēģinājums. Precīzs brīdis, kad jūsu serveris bija aizsargāts, tāpēc ir svarīgs jautājumā, vai jāturpina pārbaude.
Kāpēc redzamā PHP versija nav pietiekama
Izlabotas ir PHP 8.5.12, 8.4.27, 8.3.36 un 8.2.35. Daudzas distribūcijas un hostinga sniedzēji labojumu tomēr pārņem kā backportu savā pakotnē. Tad saskarne, piemēram, Plesk, turpina rādīt 8.2.34, kaut gan serveris ir ielāpots.
Un otrādi: pareizs versijas numurs var maldināt. Jauni faili vien neaizsargā, kamēr atmiņā darbojas veci PHP procesi. Jaunais stāvoklis ir aktīvs tikai pēc visu darbprocesu pārstartēšanas. Vairāk rakstā PHP versijas un ielāpa stāvokļa pareiza pārbaude.
| Hostinga sniedzēja apgalvojums | Ko tas pierāda | Kas vēl trūkst |
|---|---|---|
| „Visas sistēmas ir aktuālas.“ | maz | versija vai pakotnes stāvoklis, datums, pārstartēšana |
| „PHP 8.3.36 ir uzstādīts.“ | versija | datums, pārstartēšana, skartie serveri |
| „Backports pakotnē xy, pārstartēšana ...“ | ielāps un aktivizēšana | vajadzības gadījumā dati par PHP 8.1 un vecāku |
Kādi dati jums vajadzīgi no hostinga sniedzēja
Lūdziet atbildes uz šiem punktiem, ja iespējams, katrai vietnei vai līgumam:
- Kuri PHP atzari un versijas ir aktīvi jūsu vietnēm, arī vecākie, kas darbojas tikai atsevišķiem direktorijiem?
- Vai ir iekļauti labojumi priekš CVE-2026-109618 un CVE-2026-109619, kā oficiāla versija vai kā backports?
- Kad atjauninājums tika uzstādīts un kad tika pārstartēti visi PHP procesi (FPM pūli, Apache, LiteSpeed)?
- Vai
session.upload_progress.enabledir deaktivizēts CVE-2026-115560 dēļ? - Kādu darbības režīmu izmanto jūsu tarifs, piemēram, PHP-FPM vai Apache ar mod_php? Pie mod_php PHP komanda saskata augstāko risku.
- Kuri piekļuves un kļūdu žurnāli no 20.10.2026 tiek glabāti un kā jūs tos varat saņemt?
Ja kāda vietne joprojām darbojas ar PHP 8.1 vai vecāku, jautājiet atsevišķi. Šiem atzariem oficiālu atjauninājumu vairs nav, ir tikai minimāli pirmkoda backporti versijām 7.4, 8.0 un 8.1.
Paraugs: hostinga sniedzēja PHP atjauninājuma apstiprinājuma pieprasījums
Nokopējiet tekstu atbalsta pieteikumā vai e-pastā savam hostinga sniedzējam. Kvadrātiekavās norādītos datus papildiniet.
Temats: Lūgums apstiprināt PHP ielāpa stāvokli (PHP2Shell, CVE-2026-109618 / CVE-2026-109619)
Labdien!
Mēs pie jums darbinām šādas vietnes / līgumus:
[Klienta numurs, līgums, domēni]
Saistībā ar PHP drošības ievainojamībām CVE-2026-109618 un
CVE-2026-109619 (PHP2Shell, ielāpi no 21.10.2026), kā arī paziņojumu
par CVE-2026-115560 no 23.10.2026 lūdzam rakstiski apstiprināt
šādus punktus:
1. Kuras PHP versijas vai pakotņu stāvokļi ir aktīvi mūsu vietnēm?
2. Vai tajos ir iekļauti labojumi (oficiāla versija vai backports)?
3. Uzstādīšanas datums un laiks.
4. Visu PHP procesu (FPM, Apache, LiteSpeed vai tml.) pārstartēšanas
datums un laiks.
5. Vai session.upload_progress.enabled servera pusē ir deaktivizēts?
6. Kāds PHP darbības režīms tiek izmantots (piem., PHP-FPM, mod_php)?
7. Vai piekļuves un kļūdu žurnāli no 20.10.2026 tiek glabāti un kā
mēs tos varam saņemt?
8. Ja kāda vietne joprojām izmanto PHP 8.1 vai vecāku: kāda aizsardzība
tur ir un kādu pāreju jūs iesakāt?
Šos datus mums vajag iekšējai dokumentācijai.
Paldies un ar cieņu
[Vārds, uzņēmums, amats]
Atbildes pareiza izvērtēšana un pašpārbaude
Laba atbilde nosauc konkrētus stāvokļus, datumus un laikus. Vispārīgi formulējumi, piemēram, „mēs esam reaģējuši“, jūsu lietai nepietiek. Šādā gadījumā laipni pajautājiet par trūkstošajiem punktiem.
Ja jūsu tarifs to atļauj, papildus pārbaudiet paši. Ar SSH piekļuvi parasti pietiek ar šīm komandām:
# Komandrindas versija (var atšķirties no tīmekļa versijas)
php -v
# Pakotnes stāvoklis Debian/Ubuntu sistēmās
dpkg -l | grep -E "php[0-9.]*-(fpm|cli|common)"
# Pakotnes stāvoklis RHEL, Alma, Rocky sistēmās
rpm -qa | grep -i php
# Kopš kura laika darbojas PHP-FPM procesi?
ps -eo pid,lstart,cmd | grep "[p]hp-fpm"
Ja PHP procesu startēšanas laiks ir pirms apstiprinātā uzstādīšanas datuma, pārstartēšana nebija pilnīga.
Ja hostinga sniedzējs neatbild vai atbild izvairīgi
Ja atbildes nav vai trūkst izšķirošo datu, situāciju nevajadzētu uzskatīt par noskaidrotu. BSI iesaka tīmekļa serverus uz laiku atvienot no tīkla, ja atjauninājums nav iespējams nekavējoties. Vai tas jūsu vietnei ir samērīgi, lemj vadība, ideālā gadījumā rakstiski un ar datumu.
Paralēli ir vērts pārbaudīt iespējamās uzbrukuma pēdas, jo ielāpa brīdis paliek neskaidrs. Atbalsta punktus sniedz raksts Vai jau esmu kompromitēts?. Bez SSH piekļuves rakstisks apstiprinājums paliek jūsu svarīgākais pierādījums. Kuri pienākumi ir hostinga sniedzējam un kuri jums, skaidro lapa Shared Hosting: ko dara hostinga sniedzējs; pārvaldītiem serveriem palīdz Managed Server: atbildības noskaidrošana.
Glabājiet pieprasījumu, atbildi un savus pārbaudes rezultātus ar datumu vienā mapē. Šī lieta vēlāk palīdz, ja jautā apdrošinātāji vai datu aizsardzības speciālisti.
Kā PHP SOS palīdz konkrēti?
- Kopā ar jums formulējam pieprasījumu hostinga sniedzējam un profesionāli izvērtējam atbildi.
- Kur ir piekļuve, paši pārbaudām pakotnes stāvokli, aktīvo darbības režīmu un PHP procesu pārstartēšanu.
- Ja paliek robi, ieviešam pagaidu pasākumus vai plānojam pāreju uz atbalstītu versiju.
- Rezultātu un laikus fiksējam apliecinājumā, ko varat nodot iekšēji.
Kā norit atjauninājums ar pārstartēšanu un apliecinājumu, apraksta mūsu PHP ielāpu pakalpojums.
Biežāk uzdotie jautājumi
Vai pietiek, ja hostinga sniedzējs raksta, ka viss ir aktuāls?
Jūsu dokumentācijai drīzāk nē. Lūdziet konkrētus datus: pakotnes stāvokli vai versiju katram PHP atzaram, uzstādīšanas datumu un visu PHP procesu pārstartēšanas datumu. Tikai ar tiem varat norobežot ievainojamības laika logu.
Kāpēc mana hostinga saskarne joprojām rāda PHP 8.2.34?
Distribūcijas un hostinga sniedzēji drošības labojumus dažkārt ievieš kā backportu, nemainot versijas numuru. Tad Plesk var turpināt rādīt 8.2.34, kaut gan serveris ir ielāpots. Skaidrību nodrošina tikai sniedzēja apstiprinājums par pakotnes stāvokli.
Ko darīt, ja hostinga sniedzējs neatbild?
Dokumentējiet savu pieprasījumu ar datumu un pēc saprātīga laika pajautājiet vēlreiz. Paralēli pārbaudiet, vai pagaidu pasākumus varat ieviest paši, un saskaņojiet ar vadību, vai vietne līdz skaidrībai tiek atvienota no tīkla, kā BSI iesaka neielāpotiem serveriem.
Vai WordPress vai veikala atjauninājums arī aizver ievainojamību?
Nē. PHP2Shell ir pašā PHP. CMS vai veikala programmatūras atjauninājums neko nemaina PHP interpretatorā, kas darbojas serverī.