Īsi: kas vēlas PHP ievainojamību PHP2Shell aizvērt jau šodien, tam vajadzīgas četras lietas: pareizais atjauninājums, visu PHP procesu pārstartēšana, pārbaude uz jau ievadītu ļaunprātīgu kodu un pierādījums. Vai esat skarti? Zvaniet. Mēs palīdzam. Mēs to uzņemamies attālināti, no pirmās ziņas.
Tagad neko neizdzēsiet un neuzstādiet no jauna. Arī ielāpojot, vispirms saglabājiet, tad mainiet. Ja kaut kas jau ir iekļuvis, mums vajadzīgs failu un žurnālu stāvoklis. Pieteikt ārkārtas gadījumu, un mēs ar jums saskaņosim secību.
Kāpēc ievainojamība nevar gaidīt
Abas ievainojamības CVE-2026-109618 un CVE-2026-109619 atrodas pašā PHP un ļauj izpildīt ļaunprātīgu kodu no attāluma bez pieteikšanās. BSI ir izsludinājis 3. brīdinājuma līmeni (oranžs) un iesaka nekavējoties atjaunināt. Ja tas nav iespējams uzreiz, tīmekļa serveri jāatvieno no tīkla uz laiku. Saskaņā ar mediju ziņojumiem pirmie novērotie uzbrukuma mēģinājumi bija jau pirms ielāpu publicēšanas 2026. gada 21. oktobrī. Cloudflare ir novērojis mēģinājumus un ieviesis aizsardzības noteikumus, taču brīdina, ka noteikumi, kas balstīti tikai uz pieprasījuma datiem, nepietiek.
Svarīgi operatoriem: CMS atjauninājums PHP ievainojamību neaizver. Arī WordPress.org saskaņā ar ziņojumiem neplāno atjauninājumu pret to, jo ievainojamība ir interpretatorā. Tā tiek aizvērta tikai PHP līmenī, tas ir, tajā, ko jūsu serveris patiešām izpilda.
Ko darīt tūlīt
- Zināt mērķa versiju. Labotas ir PHP 8.5.12, 8.4.27, 8.3.36 un 8.2.35. PHP 8.2 atbalsta beigas ir 2026. gada 31. decembrī, ņemiet to vērā plānojot.
- Apzināt visas sistēmas. Arī testa serverus, konteineru attēlus un vecās sistēmas, kas sasniedzamas no interneta.
- Noskaidrot atbildību. Hostinga pakotnēs un pārvaldītos serveros ielāpu ievieš sniedzējs. Jautājiet rakstiski par versiju un pārstartēšanu.
- Saglabāt žurnālus. No 2026. gada 20. oktobra, kā iesaka speciālistu prese.
- Saskaņot laika logu. Pārstartēšana īslaicīgi pārtrauc notiekošos pieprasījumus. Nosakiet laiku, kad kāds var pieņemt lēmumus.
- Negaidīt, ja ir atvērts. Ja uzreiz ielāpot nevar, kopā ar mums izvērtējiet norobežošanu vai pagaidu pasākumus.
Kā PHP SOS palīdz konkrēti?
- Situācijas attēls: Mēs apzinām sistēmas, PHP versijas, darbības režīmus, hostinga sniedzējus un sasniedzamību un nosakām secību: vispirms visvairāk pakļautās sistēmas.
- Saglabāt un aizvērt: Mēs saglabājam esošo stāvokli, uzstādām atjauninājumu vai panākam, ka hostings ir pierādāmi ielāpotā stāvoklī, un pārstartējam visus procesus. Konteineru gadījumā attēlu pārbūvējam un izvēršam.
- Pārbaudīt un attīrīt: Tā kā ielāps ļaunprātīgu kodu nenoņem, mēs pārbaudām, vai nav agrākas ielaušanās pazīmju, un vajadzības gadījumā attīrām.
- Nostiprināt un ziņot: Jūs saņemat rakstisku pierādījumu katrai sistēmai un ieteikumus, lai nākamais atjauninājums noritētu ātrāk. Pakalpojuma saturu apraksta PHP ielāpu pakalpojums.
Atjauninājums, pārstartēšana, pierādījums: kas ir svarīgi
Biežākā kļūda ir atjauninājums bez pārstartēšanas. Kamēr atmiņā darbojas veci procesi, ievainojamais kods paliek aktīvs, pat ja faili ir jauni. Pamācība ir lapā PHP-FPM un visu darbprocesu pārstartēšana. Otrā kļūda ir ticēt rādījumam: distributīvi un hostinga sniedzēji bieži piegādā backport, un tad versijas numurs paliek tāds pats. Uzticams ir pakotnes changelog ar CVE numuriem, Debian saimē ar apt-get changelog <paket>.
Papildus saskaņā ar PHP rokasgrāmatu kopš drošības izlaidumiem ir jauna direktīva memory_hard_limit_percent. Ja PHP versija to nepazīst, tā ir skarta. Tests ir īss:
php -r 'var_dump(ini_get("memory_hard_limit_percent"));'
Tas jāveic katrai versijai un darbības režīmam, jo komandrindā var būt cita PHP versija nekā tīmekļa serverī. Noslēgumā mēs rezultātu fiksējam, lai jūs to varētu uzrādīt hostinga sniedzējam, apdrošinātājam vai pasūtītājam.
Ja atjauninājumu nevar uzreiz
Ir iemesli, kāpēc atjauninājums šodien nav iespējams: veca lietojumprogramma, kas jaunākajās PHP versijās nedarbojas, hostinga sniedzējs bez atļaujas, konteinera attēls stingrā konveijerā. Šiem gadījumiem php.net min pagaidu pasākumus, kas tieši nav pilnīga aizsardzība: memory_limit=-1 iestatīt tā, lai lietojumprogrammas to nevarētu pārrakstīt, ierobežot post_max_size, session.upload_progress.enabled=0 un PHP 8.5 fatal_error_backtraces=0, katru reizi ar pārstartēšanu. Tam pievienojas aizsardzības noteikumi tīkla malā, kas atjauninājumu neaizstāj. Apgalvojumu, ka jābloķē visi pieprasījumi ar PHPSESSID, speciālisti skaidri noraida.
Kuri pasākumi der jūsu sistēmai un ko tie var sabojāt, apspriežam iepriekš. Vairāk lapā Tūlītēji pasākumi, ja vēl nevarat ielāpot un tēmā WAF un virtuālā ielāpošana. PHP 8.1 un vecākām versijām ir sava situācija, kas aprakstīta lapā PHP 8.1 un vecākas versijas: kas tagad ir spēkā.
Ko jums vajadzētu mums nosūtīt
- Serveru un hostinga sniedzēju saraksts, ciktāl pieejams
php -vizvade katrā sistēmā un norāde par darbības režīmu- Norāde, vai tiek izmantoti konteineri, Plesk, cPanel vai pārvaldīts piedāvājums
- Vēlamais laika logs un kontaktpersona pārstartēšanai
- Norādes par neparastām parādībām kopš 2026. gada 17. oktobra
Kāpēc PHP SOS
Mēs strādājam pēc principa Made in Germany, un kopā ar savu kiberspeciālistu partneru tīklu IT drošībā esam specializējušies vairāk nekā 25 gadus. Jums ir viena kontaktpersona, kas pavada atjauninājumu, pārbauda pārstartēšanu un sniedz pierādījumu. Mēs strādājam attālināti, bez ierašanās, un dokumentējam katru soli. Mēs nesolām brīnumus: ielāps ievainojamību aizver, bet nepierāda, ka iepriekš nekas nav noticis, un to mēs jums arī sakām.
Vai esat skarti? Zvaniet. Mēs palīdzam.
Neļaujiet ievainojamībai stāvēt atvērtai ilgāk. Zvaniet vai rakstiet WhatsApp. Mēs uzņemamies darbu no pirmās ziņas un paliekam līdz brīdim, kad incidents ir noslēgts un dokumentēts. Pieteikt ārkārtas gadījumu tagad.
Biežāk uzdotie jautājumi
Vai PHP ievainojamību varu aizvērt pats, vai man vajadzīga palīdzība?
Administratoriem atjauninājums ir izpildāms, bet pakļauts kļūdām: jāatjaunina tā versija, kas patiešām apkalpo lapas, un jāpārstartē visi procesi. Kam ir vairāki serveri, konteineru attēli vai hostinga sniedzējs ar savām īpatnībām, ar atbalstu ietaupa laiku un kļūdas.
Vai PHP pēc atjaunināšanas jāpārstartē?
Jā. Ar jauniem failiem vien nepietiek, kamēr atmiņā darbojas veci PHP procesi. Jāpārstartē visi darbprocesi jeb procesi, mod_php gadījumā tīmekļa serveris.
Ko darīt, ja manai PHP versijai atjauninājuma vēl nav?
Versijām 8.1 un vecākām PHP projekts oficiālus atjauninājumus vairs nesniedz. Tad vajadzīgs sniedzēja pierādāmi ielāpots backport, migrācija uz uzturētu versiju vai pagaidu pasākumi, kas tomēr nesniedz pilnīgu aizsardzību.
Vai pietiek ar session.upload_progress.enabled iestatīšanu uz 0?
Nē. Saskaņā ar speciālistu ziņojumiem šis iestatījums vien neaizver abas ievainojamības, PHP atjauninājums paliek obligāts. Iestatiet to tikai php.ini, FPM pūlā vai servera konfigurācijā, nevis ar ini_set() vai .user.ini.
Kā es zinu, ka ievainojamība pēc tam patiešām ir aizvērta?
Ar pierādījumu darbojošā sistēmā: versija vai pakotnes changelog, tests jaunajai direktīvai memory_hard_limit_percent un apstiprinājums, ka visi procesi pēc atjaunināšanas ir pārstartēti.