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 →

Kāpēc WordPress atjauninājums pret PHP2Shell nepalīdz

Daudzi operatori pēc virsrakstiem atjaunināja WordPress un jūtas droši. Kāpēc PHP2Shell gadījumā tas neko nedod un kas ir svarīgs tā vietā.

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

Īsi sakot: WordPress atjauninājums nepalīdz pret PHP ievainojamību PHP2Shell, jo kļūda nav WordPress, bet PHP, programmatūrā serverī, kas WordPress izpilda. Saskaņā ar Dr. Web WordPress.org tāpēc arī neplāno savu atjauninājumu. Aizsargāt var tikai PHP atjauninājums serverī ar visu PHP procesu pārstartēšanu. To parasti ievieš jūsu hostinga sniedzējs vai servera operators.

Sākumpunkts: “Mēs taču visu atjauninājām”

Pēc pirmajiem virsrakstiem par PHP2Shell daudzi operatori izdarīja to, kas pašsaprotami: atvēra WordPress paneli, nospieda “Atjaunināt tagad”, un kopā arī spraudņus un tēmas. Pēc tam viss ir zaļš, un sajūta saka: padarīts.

Šīs ievainojamības gadījumā sajūta maldina. Tas nav WordPress dēļ, bet tāpēc, kur kļūda atrodas. Arī Cloudflare savā paziņojumā norāda, ka lietojumprogrammas koda vai spraudņu atjauninājums ievainojamības nelabo.

WordPress atjauninājums un PHP ievainojamība: slāņu modelis

WordPress vietne sastāv no vairākiem slāņiem, kas balstās viens uz otra. Katram slānim ir savi atjauninājumi un bieži savi atbildīgie:

Slānis Piemērs Kurš tipiski atjaunina Vai PHP2Shell skar?
Operētājsistēma Debian, Ubuntu, AlmaLinux hostinga sniedzējs vai servera administrators nē, taču bieži piegādā PHP pakotni
Tīmekļa serveris Apache, Nginx, LiteSpeed hostinga sniedzējs vai servera administrators darbības režīms ietekmē risku
PHP izpildes vide PHP-FPM, mod_php hostinga sniedzējs vai servera administrators jā, šeit atrodas ievainojamība
WordPress kodols WordPress operators vai aģentūra nē
Spraudņi un tēmas WooCommerce, lapu veidotājs (page builder) operators vai aģentūra nē

Atjaunināšanas poga panelī sasniedz tikai apakšējās divas rindas. PHP izpildes vide atrodas zemāk un WordPress ir neredzama. Kā citas sistēmas balstās uz PHP, apraksta raksts CMS un veikali uz PHP.

Kāpēc WordPress ievainojamību aizvērt nevar

Var domāt, ka WordPress var “ieprogrammēt apkārt”. PHP2Shell gadījumā tas nedarbojas divu iemeslu dēļ.

Pirmkārt, abas kļūdas slēpjas tajā, kā PHP apstrādā pieprasījumus un pēc tam sakārto. Tas notiek neatkarīgi no tā, kāda programma PHP darbojas. Otrkārt, PHP komanda Apache ar mod_php gadījumam ir demonstrējusi exploit, kas iedarbojas, pirms vispār tiek izpildīts lietojumprogrammas kods. WordPress, tā spraudņi un jebkurš drošības spraudnis tad pie vārda vispār netiek.

Tā paša iemesla dēļ nepalīdz arī neviens “nostiprināšanas spraudnis”, kas maina iestatījumus ar ini_set(). php.net tieši neiesaka pagaidu pasākumus iestatīt šādā veidā.

Un pārvaldītā WordPress gadījumā?

Pārvaldītā WordPress (Managed WordPress) piedāvājumos pakalpojuma sniedzējs bieži rūpējas ne tikai par WordPress atjauninājumiem, bet arī par serveri zem tā. PHP2Shell gadījumā tas ir ieguvums, bet ne automātisms. Jautājiet konkrēti, vai PHP atjauninājums ir ieviests un visi PHP procesi pārstartēti. Apgalvojums “Mēs uzturam jūsu WordPress aktuālu” uz šo jautājumu neatbild.

Daudzas vietnes, viena PHP instalācija

Aģentūrām un uzņēmumiem ar vairākām vietnēm jāzina kāda īpatnība: serverī daudzas WordPress instalācijas bieži dala vienu PHP versiju. Ja tā ir neielāpota, skartas ir visas, neatkarīgi no tā, cik labi uzturēta ir katra atsevišķā vietne. Savukārt PHP atjauninājums aizsargā visas instalācijas uzreiz, ja pēc tam tiek pārstartēti visi tam piederošie PHP procesi. Kas paralēli darbina vairākas PHP versijas, tam katra jāatjaunina atsevišķi.

Svarīgi

Zaļš WordPress panelis par PHP2Shell neko neizsaka. Izšķirošs ir PHP ielāpa stāvoklis serverī un visu PHP procesu pārstartēšana.

Kā pareizi nolasīt PHP versiju WordPress

WordPress rāda PHP versiju: panelī sadaļā Rīki, Vietnes veselība, apgabalā Atskaite pie nodaļas Server. Tā ir laba pirmā norāde, bet ne pierādījums.

Ja tur ir atzars, piemēram, 8.1 vai vecāks, tas ir skaidrs brīdinājuma signāls, jo tam oficiālu atjauninājumu vairs nav. Ja tur ir 8.2.35, 8.3.36, 8.4.27 vai 8.5.12, labotais stāvoklis ir instalēts. Ja tur ir vecāks atbalstīta atzara numurs, tomēr var būt ieviests backport. Distributīvi un hostinga sniedzēji numuru pie tā bieži nemaina. Skaidrību dod tikai hostinga sniedzēja apstiprinājums vai ieskats pakotnes changelog. Kā tas notiek, lasāms sadaļā PHP versijas un ielāpa stāvokļa pārbaude.

Ko WordPress operatoriem darīt tā vietā

  1. Pajautāt hostinga sniedzējam vai servera operatoram: Vai PHP ir ielāpots, kad, un vai visi PHP procesi ir pārstartēti? Atbilde rakstiski.
  2. Pārbaudīt PHP atzaru: Ja vietne darbojas ar 8.1 vai vecāku, plānot pāreju uz atbalstītu atzaru. Kuru versiju atbalsta jūsu WordPress versija, norādīts sistēmas prasībās wordpress.org. Maiņu klienta izvēlnē apraksta PHP versijas maiņa hostinga klienta sadaļā.
  3. Pārbaudīt pēdas: jauni PHP faili wp-content/uploads, nezināmi administratoru konti, sveši ieraksti mu-plugins. Tipiskās slēptuves apraksta lapa WordPress un PHP2Shell.
  4. WordPress tomēr uzturēt aktuālu: Kodols, spraudņi un tēmas aizver citas ievainojamības. Tas paliek pienākums, tikai cits.
  5. Noskaidrot atbildību: Ja vietni uztur aģentūra, fiksēt, vai tā atbild arī par PHP vai tikai par WordPress.

Tieši pēdējais punkts bieži rada robus. Aģentūra uztur WordPress, hostinga sniedzējs serveri, un katrs domā, ka otrs PHP2Shell ir ņēmis vērā.

Kā PHP SOS palīdz konkrēti?

  • Noskaidrot slāņus: Mēs nosakām, kurš jūsu WordPress vietnei par kuru slāni atbild.
  • Atjaunināt PHP: Savos vai pārvaldītos serveros mēs ieviešam PHP atjauninājumu un pārstartējam visus procesus.
  • Pārbaudīt WordPress: Mēs meklējam uzbrukuma pēdas failos, datubāzē un kontos.
  • Apliecinājums: Jūs saņemat ielāpa stāvokli rakstiski, arī nodošanai aģentūrai vai klientiem.

Norisi apraksta PHP ielāpu pakalpojums.

Secinājums

WordPress atjauninājums ir laba uzturēšana, taču PHP2Shell gadījumā nepareizais slānis. Ievainojamība atrodas vienu stāvu zemāk, PHP serverī. Kas to saprot, uzdod pareizo jautājumu pareizajai vietai: vai PHP ir ielāpots, pārstartēts un apliecināts?

Biežāk uzdotie jautājumi

Vai WordPress izdos drošības atjauninājumu pret PHP2Shell?

Saskaņā ar Dr. Web WordPress.org neplāno atjauninājumu pret PHP2Shell, jo ievainojamība atrodas PHP interpretatorā serverī. Palīdz tikai PHP atjauninājums, ko veic hostinga sniedzējs vai servera operators.

Kur WordPress redzu PHP versiju?

Panelī sadaļā Rīki, Vietnes veselība, apgabalā Atskaite pie nodaļas Server. Rādītais numurs tomēr droši neizsaka, vai ielāps ir ieviests, jo hostinga sniedzēji labojumus bieži iebūvē kā backport bez jauna versijas numura.

Vai drošības spraudnis pasargā no PHP2Shell?

Tikai ļoti ierobežoti. Spraudnis pats darbojas PHP un kļūst aktīvs tikai tad, kad WordPress ir ielādēts. Apache ar mod_php gadījumā saskaņā ar PHP komandu exploit tika demonstrēts, vēl pirms tiek izpildīts jebkāds lietojumprogrammas kods. Tur spraudnis iejaukties nevar.

Vai man tomēr WordPress jāatjaunina?

Jā. Aktuālās WordPress, tēmu un spraudņu versijas aizver citas ievainojamības un ir laba uzturēšanas daļa. Tās vienkārši neatrisina PHP2Shell problēmu.

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