PHP2Shell: kritiska PHP ievainojamība un kas jādara WordPress lapām

PHP2Shell ir nosaukums divām kritiskām PHP ievainojamībām: CVE-2026-109618 un CVE-2026-109619, abām CVSS vērtējums 9,2 no 10. Tās ļauj uzbrucējam bez paroles izpildīt savu kodu serverī, uz kura darbojas PHP. Tas nozīmē gandrīz katru WordPress, WooCommerce, Joomla un Drupal lapu. Labojums iznāca 21. oktobrī plkst. 17.00 pēc Rīgas laika: drošas ir PHP versijas 8.5.12, 8.4.27, 8.3.36 un 8.2.35 un jaunākas. WordPress, spraudņu vai tēmas atjaunināšana šoreiz nepalīdz, jāatjaunina pats PHP, un vairumam lapu to dara hostings. Rakstu papildinām, tiklīdz parādās jauna pārbaudīta informācija.

Jaunākais par PHP2Shell

Svarīgākās izmaiņas kopš labojuma iznākšanas. Jaunākais ieraksts ir augšā.

23.10.2026, 18.00

PHP drošības komanda 23. oktobrī publicēja papildu paziņojumu par vēl vienu koda izpildes ceļu (CVE-2026-115560), ko labos tikai nākamajā kārtējā PHP laidienā. Tas iespējams tikai retā konfigurācijas un lapas koda kombinācijā, tomēr līdz tam PHP komanda iesaka serverī paturēt iestatījumu session.upload_progress.enabled = 0 arī pēc atjaunināšanas. CloudLinux apstiprina, ka labotās PHP pakas cPanel (ea-php) un CloudLinux (alt-php) serveriem ir pieejamas stabilajos repozitorijos.

23.10.2026, 09.00

Amazon draudu izpētes komanda ziņo, ka pirmo uzbrukuma mēģinājumu savos slazdu serveros reģistrēja jau 17. oktobrī, četras dienas pirms kļūdu publiskošanas, un tagad redz plašus uzbrukuma mēģinājumus. Tāpēc, pārbaudot, vai lapa nav uzlauzta, servera žurnālus skatieties sākot no 17. oktobra. Hostinger apstiprina, ka labojums uzstādīts visos tā serveros, izņemot VPS.

22.10.2026, 18.00

CERT.LV aicina Latvijas uzņēmumus nekavējoties atjaunināt PHP un noskaidrot, kāda versija darbojas publiskajās lapās, interneta veikalos un klientu portālos. Sistēmām, kuras nevar atjaunināt, CERT.LV iesaka ierobežot piekļuvi no interneta vai vismaz no ārvalstīm, un daļai valsts digitālo resursu piekļuve no ārvalstīm īslaicīgi ierobežota, iespējams, līdz 26. oktobrim. Ziņu par Latvijā uzlauztām sistēmām pagaidām nav.

22.10.2026, 09.00

Hostinger oficiāli paziņoja, ka koplietošanas un pārvaldītajā hostingā PHP labojumu ievieš automātiski un klientiem nekas nav jādara. Visos serveros ieslēgti ugunsmūra noteikumi, kas zināmos uzbrukuma pieprasījumus uzreiz noraida. VPS klientiem PHP jāatjaunina pašiem.

21.10.2026, 23.15

Raksta pirmā versija. Labojums pieejams visām atbalstītajām PHP versijām (8.2-8.5). Cloudflare ugunsmūra noteikumi aizsargā arī bezmaksas plāna lapas. WordPress.org apstiprina, ka WordPress atjauninājums nav vajadzīgs un netiek gatavots.

Kas notika un kāpēc tas ir nopietni

20. oktobrī PHP drošības komanda brīdināja, ka nākamajā dienā izlaidīs labojumu divām kritiskām kļūdām. Uzbrucēji par kļūdu uzzināja agrāk: Amazon pirmo uzbrukuma mēģinājumu reģistrēja jau 17. oktobrī, un 21. oktobra rītā, vēl pirms labojums bija pieejams, uzbrukumus redzēja arī Cloudflare. Tagad kļūdu apraksti un uzbrukuma rīks ir publiski, tāpēc nesalabotas lapas automātiski meklē un uzbrūk tām.

Abas kļūdas ir saistītas ar to, kā PHP rīkojas, ja pieprasījuma laikā pietrūkst atmiņas vai notiek fatāla kļūda. PHP pārtrauc darbu, bet ne vienmēr kārtīgi notīra iekšējos datus. Nākamais pieprasījums var izmantot šos “pārpalikumus”, un ar īpaši sagatavotu pieprasījumu uzbrucējs var palaist savu kodu vai nolasīt servera atmiņu, kur var būt paroles un piekļuves atslēgas.

Svarīgākais mājaslapas īpašniekam: uzbrukums notiek pirms WordPress vispār ielādējas. Nav nozīmes, cik drošas ir jūsu paroles, spraudņi vai tēma. Ja serveris darbojas ar nesalabotu PHP, lapa ir apdraudēta.

Vai tas skar jūsu lapu

Jā, ja lapa vai interneta veikals darbojas ar WordPress, WooCommerce, Joomla, Drupal, Magento vai citu PHP sistēmu un serverī vēl nav 21. oktobra labojuma. Kļūdas ir visās PHP versijās kopš 5.4, tātad arī ļoti vecās lapās.

Nē, ja lapa ir uz Wix, Wix Studio, Shopify vai Squarespace. Tur jūs neuzturat savu PHP serveri, un serverus uztur pati platforma. Jums nekas nav jādara.

Ja nezināt, uz kā lapa veidota, ieskatieties lapas administrēšanas adresē: ja ielogojaties caur /wp-admin vai līdzīgu adresi un redzat WordPress paneli, lapa ir uz PHP.

Kā pārbaudīt PHP versiju 2 minūtēs

WordPress panelī atveriet Rīki → Vietnes veselība → Informācija → Serveris. Rindā “PHP versija” redzēsiet numuru. Tas pats parasti redzams arī hostinga vadības panelī.

Salīdziniet to ar drošajām versijām:

PHP 8.5

droša no 8.5.12

PHP 8.4

droša no 8.4.27

PHP 8.3

droša no 8.3.36

PHP 8.2

droša no 8.2.35. Šai versijai atbalsts beidzas 2026. gada 31. decembrī, tāpēc pāreju uz jaunāku vērts plānot jau tagad.

8.1 un vecāka

PHP projekts tās vairs neatjaunina. Labojums iespējams tikai no hostinga vai Linux izplatītāja, citādi jāpāriet uz 8.2 vai jaunāku.

Viena nianse: daudzi serveri PHP instalē no Linux izplatītāja pakām, un tad labojums tiek ielikts, nemainot redzamo versijas numuru. Ja redzat, piemēram, 8.3.35, tas vēl nenozīmē, ka lapa nav salabota. Šādā gadījumā jautājiet hostingam tieši: vai serverī ir uzstādīts 21. oktobra PHP drošības labojums?

Kas jādara atkarībā no hostinga

Koplietošanas vai pārvaldīts hostings

Tas ir vairums mazo uzņēmumu lapu: jums ir hostinga vadības panelis, bet servera neesat konfigurējuši paši. PHP atjaunina hostings visiem klientiem uzreiz. Daudzi lielie hostingi jau 21. oktobrī ziņoja par pagaidu aizsardzību un labojuma ieviešanu. Ja līdz 22. oktobrim neesat saņēmuši paziņojumu, uzrakstiet atbalstam un prasiet apstiprinājumu. Ja panelī var izvēlēties PHP versiju un jums ir 8.1 vai vecāka, šis ir brīdis pāriet uz atbalstītu versiju.

VPS vai savs serveris

Šeit neviens neatjauninās jūsu vietā. Kurš serveri uztur, tam šodien jāuzstāda atjauninātās PHP pakas un jāpārstartē PHP, lai jaunā versija darbotos visos procesos. Vērts pārbaudīt, no kura avota serveris ņem PHP pakas, jo ne visi repozitoriji labojumu publicēja vienlaikus.

Lapa aiz Cloudflare

Cloudflare ugunsmūra noteikumi pret šiem uzbrukumiem darbojas visos plānos, arī bezmaksas plānā, un tur tie ieslēgti automātiski. Pro, Business un Enterprise plānos pārbaudiet, ka pārvaldītie noteikumi ir režīmā “Block”, nevis tikai “Log”. Tā ir papildu aizsardzība, nevis labojums: PHP tik un tā jāatjaunina.

Ja PHP nevar atjaunināt uzreiz

PHP drošības komanda ir publicējusi pagaidu iestatījumus, kas aizver dažus uzbrukuma ceļus, bet lapu drošu nepadara. Tie ir darbs servera administratoram, ne lapas īpašniekam:

• session.upload_progress.enabled = 0 servera php.ini vai FPM pūla konfigurācijā, pēc tam pārstartēt visus PHP procesus. Iestatījums .user.ini failā vai ar ini_set() šeit nedarbojas. WordPress šo funkciju neizmanto, tāpēc lapas darbību tas neietekmē.
• Zems post_max_size: 8M lapām bez failu augšupielādes, 32M lapām ar augšupielādi.
• PHP 8.5 serveros papildus fatal_error_backtraces = 0.

Iestatījumu session.upload_progress.enabled = 0 PHP komanda iesaka paturēt arī pēc atjaunināšanas, līdz nākamajam kārtējam PHP laidienam. 23. oktobrī tā paziņoja par vēl vienu, mazticamu uzbrukuma ceļu (CVE-2026-115560), kuru labos šajā laidienā.

Ja arī to nevar izdarīt ātri, Lielbritānijas Nacionālais kiberdrošības centrs iesaka apsvērt sistēmas atslēgšanu, līdz to var salabot. Latvijā CERT.LV iesaka līdzīgi: ja sistēmu nevar atjaunināt, ierobežojiet tās piekļuvi no interneta vai vismaz no ārvalstīm. Uzņēmuma vizītkartes lapai pāris stundas bezsaistē izmaksā mazāk nekā uzlauzts serveris.

Pēc labojuma vērts pārliecināties, ka lapa nav uzlauzta jau pirms tā: vai administratoru sarakstā nav svešu lietotāju, vai mapē wp-content/uploads nav PHP failu un vai servera žurnālos nav daudz atmiņas limita kļūdu un 500 atbilžu pēc kārtas. Žurnālus skatieties sākot no 17. oktobra, jo pirmie uzbrukuma mēģinājumi reģistrēti jau tad.

Ko šis stāsts māca par AI un drošību

Kļūda PHP kodā bija vairāk nekā desmit gadus. To neviens neizmantoja, jo darbojošos uzbrukumu uzbūvēt bija pārāk sarežģīti. Wiz pētnieki to atrada augustā, izmantojot jaunākos AI modeļus, un raksta, ka viens pētnieks ar AI nedēļā paveica to, kam iepriekš vajadzētu veselu komandu un mēnešus.

Šoreiz kļūdu atrada aizstāvji un ziņoja PHP komandai. Bet tie paši rīki ir pieejami arī uzbrucējiem, un laiks starp kļūdas publiskošanu un masveida uzbrukumiem kļūst arvien īsāks. Arguments “mūsu lapa ir pārāk maza, lai kādu interesētu” vairs nestrādā: robotiem ir vienalga, kam pieder serveris.

Mēs AI izmantojam izstrādē katru dienu un tāpēc labi redzam abas puses. AI paātrina darbu, bet par to, vai PHP ir atjaunināts un vai kāds vispār seko līdzi drošības paziņojumiem, joprojām atbild cilvēks. Ja jūsu lapai tāda cilvēka nav, šis ir labs brīdis to mainīt.

Ko izdarīt šodien

• Noskaidrojiet, vai lapa darbojas ar PHP (WordPress, WooCommerce, Joomla, Drupal).
• Pārbaudiet PHP versiju: Rīki → Vietnes veselība → Informācija → Serveris.
• Salīdziniet ar drošajām versijām: 8.5.12, 8.4.27, 8.3.36 vai 8.2.35.
• Ja versija ir vecāka vai neesat drošs, prasiet hostingam apstiprinājumu par 21. oktobra labojumu.
• Ja PHP versija ir 8.1 vai vecāka, plānojiet pāreju uz 8.2 vai jaunāku, vispirms pārbaudot lapu testa kopijā.
• Pēc labojuma pārbaudiet, vai administratoru sarakstā nav svešu lietotāju.

Biežāk uzdotie jautājumi

Nezināt, kas uztur jūsu lapu?

Uzrakstiet mums lapas adresi, un bez maksas pateiksim, kāda PHP versija tajā darbojas un kas jādara. Ja gribat, lai pēc tam kāds pastāvīgi seko atjauninājumiem un drošībai, skatiet lapas uzturēšanu un drošību no 49 € mēnesī. Lai sazinātos, aizpildiet formu vai zvaniet +371 25 640 062.

Avoti

• PHP drošības paziņojums, 21.10.2026
• WordPress.org: Critical PHP Security Release
• Wiz Research: PHP2Shell
• Cloudflare: aizsardzība pret php2shell
• NCSC (Lielbritānija): Critical security issue affecting PHP
• Hostinger: aizsardzība pret php2shell
• CERT.LV: Kritiskas ievainojamības PHP programmatūrā
• CERT.LV: Latvijā ievieš preventīvus pasākumus
• Amazon Threat Intelligence: PHP2Shell uzbrukumi pirms publiskošanas
• PHP papildu paziņojums par session upload progress, 23.10.2026
• CloudLinux: PHP pakotņu statuss un Imunify360 aizsardzība