PHP2Shell: kritiskas PHP ievainojamības — kā ielāpot tagad

2026. gada 21. oktobris | PHP | IT drošība

2026. gada 21. oktobrī PHP drošības komanda publicēja atjauninājumus visām vēl atbalstītajām PHP versijām. Tie aizver divas kritiskas ievainojamības, kas kļuvušas pazīstamas kā PHP2Shell. BSI par to ir izdevis brīdinājumu un pieprasa nekavējoties ielāpot skartās sistēmas. Kas darbina tīmekļa serveri ar PHP, tam jārīkojas vēl šodien. Tas attiecas arī uz visiem, kas darbina “tikai” WordPress, Nextcloud vai Joomla, jo šīs lietojumprogrammas darbojas uz PHP.

Šis raksts apkopo, kas noticis, kuras PHP versijas ir skartas, kāda versija jums tagad vajadzīga un kā dažās minūtēs pārbaudīt, vai jūsu serveris ir nodrošināts.

Kas noticis? Laika gaita

PHP drošības komanda iepriekš paziņoja par labojumu publicēšanu, lai hostinga sniedzējiem un administratoriem būtu laiks sagatavoties. Pati publicēšana notika 2026. gada 21. oktobrī. BSI tajā pašā dienā izdeva savu brīdinājumu (versija 1.1).

• 2026. gada 20. oktobris: PHP drošības komandas iepriekšējs brīdinājums, ka nākamajā dienā parādīsies drošības atjauninājumi.
• 2026. gada 21. oktobris, 14:00 UTC (16:00 pēc Centrāleiropas vasaras laika): Tiek publicēti ielāpi PHP 8.5, 8.4, 8.3 un 8.2.
• 2026. gada 21. oktobris: BSI brīdina par “kritiskām ievainojamībām, kas apdraud tīmekļa lietojumprogrammas visā pasaulē”, un iesaka nekavējoties ielāpot. Saskaņā ar BSI datiem lieli hostinga sniedzēji daļēji ir piesardzības nolūkos izslēguši serverus no tīkla.

Abas PHP ievainojamības īsumā

Tās ir divas atsevišķas kļūdas PHP kodolā: CVE-2026-109618 un CVE-2026-109619. Saskaņā ar PHP drošības komandas datiem abas var ļaut uzbrucējam izpildīt programmas kodu serverī, nepieteicoties (unauthenticated Remote Code Execution). Ievainojamības tiek novērtētas ar CVSS v4.0: 9,2 (kritiska).

Pēc BSI vērtējuma publicēšanas brīdī apstiprinātu uzbrukumu nebija, taču bija neapstiprinātas norādes uz ekspluatācijas mēģinājumiem. Pieredze rāda, ka pie kritiskām ievainojamībām tik plaši izplatītā programmatūrā jārēķinās, ka uzbrucēji analizēs labojumus un sagatavos automatizētus uzbrukumus. Laika logs ielāpošanai tāpēc ir īss.

Kas ir skarts?

Principā ir skarts katrs serveris, kurā darbojas PHP, neatkarīgi no tā, kā PHP ir pieslēgts: PHP-FPM, mod_php Apache, php-cgi, FrankenPHP vai LiteSpeed. Pēc PHP drošības komandas teiktā, visaugstākais risks ir Apache ar mod_php.

BSI skaidri min lietojumprogrammas, kas balstās uz PHP un tāpēc var būt līdzskartas:

• Satura pārvaldības sistēmas: WordPress, Drupal, TYPO3, Joomla
• Veikalu sistēmas: Magento
• Mākoņa un failu glabātuve: Nextcloud
• Ugunsmūru saskarnes: pfSense, OPNsense

Pašai lietojumprogrammai tam nav jābūt kļūdainai. Ievainojamība ir PHP, tāpēc WordPress, Nextcloud & Co. atjauninājums vien nepalīdz. Jāatjaunina servera PHP versija. Ugunsmūriem, piemēram, pfSense un OPNsense, labotā PHP versija nāk ar attiecīgā ražotāja programmaparatūras atjauninājumu.

Šīs PHP versijas ir drošas

Ievainojamības ir novērstas šajās versijās. Viss, kas zemāk, tiek uzskatīts par neaizsargātu.

Kā pārbaudīt un atjaunināt savu serveri

1. Noskaidrot instalēto PHP versiju

Servera komandrindā php -v parāda komandrindas PHP versiju. Tīmekļa serveris var izmantot citu PHP versiju. Tāpēc pārbaudiet arī PHP-FPM jeb Apache moduļa versiju, piemēram, ar php-fpm8.3 -v vai ar lapu, kas izvada phpinfo() (to pēc tam nekavējoties noņemt).

2. Atjauninājumu ieviest ar pakešu pārvaldību

Debian, Ubuntu, RHEL un radniecīgās sistēmās labotā versija nāk ar parasto pakešu pārvaldību, piemēram, apt update && apt upgrade vai dnf upgrade. Ārējiem avotiem, piemēram, Sury PPA vai Remi repozitorijam, jaunās paketes parasti parādās drīz.

3. Pārstartēt PHP pakalpojumu

Ar pakešu atjauninājumu vien nepietiek: darbojošies PHP procesi atmiņā patur veco kodu. Pārstartējiet PHP-FPM (systemctl restart php8.3-fpm) jeb Apache (systemctl restart apache2) un pēc tam pārbaudiet, vai procesi ir sākti pēc atjauninājuma.

4. Hostētas tīmekļa vietnes

Koplietošanas hostinga gadījumā atjaunina parasti sniedzējs. Klienta izvēlnē PHP versiju parasti var iestatīt katrai tīmekļa vietnei. Izvēlieties tur kādu no iepriekš minētajām drošajām versijām vai pajautājiet sniedzējam par ielāpu stāvokli. Pēc BSI datiem atsevišķi sniedzēji ir piesardzības nolūkos atvienojuši serverus no tīkla. Ja jūsu lapa uz brīdi nav pieejama, tas var būt iemesls.

PHP 8.1 un vecākas: nav oficiāla atjauninājuma

PHP 8.1 un vecākām versijām oficiālu drošības atjauninājumu vairs nav. Šādu sistēmu operatoriem ir divas iespējas:

• Pāriet uz atbalstītu versiju (ieteicams). Jo vecāka versija, jo lielāks ir pielāgošanas apjoms lietojumprogrammai un paplašinājumiem, tāpēc pāreja iepriekš jāpārbauda.
• Labojumus pārnest atpakaļ. PHP drošības komanda ir nodrošinājusi labojumus izstrādes atzaros GitHub. Kas PHP kompilē pats, var šīs izmaiņas pārņemt vecākās versijās. Tas ir pagaidu risinājums un prasa speciālas zināšanas.

Arī PHP 8.2 tiek atbalstīts tikai līdz 2026. gada 31. decembrim. Tāpēc plānojiet pāreju uz PHP 8.4 vai 8.5 jau tagad un neatlieciet to uz gadumiju.

Pagaidu pasākumi un jautājums “Izslēgt serveri no tīkla?”

PHP drošības komanda kopā ar paziņojumu aprakstīja arī pagaidu aizsardzības pasākumus. Tie samazina risku, bet ievainojamības pilnībā neaizver. Tie neaizstāj atjauninājumu un ir paredzēti tikai laika pārvarēšanai līdz atjauninājumam.

Vai serveris līdz atjauninājumam būtu jāatvieno no tīkla, ir atkarīgs no tā nozīmes un pieejamības. BSI norāda, ka lieli sniedzēji šo soli ir spēruši. Kā pamatnoteikums derēs:

• Publiski pieejams serveris, atjauninājums tagad iespējams: ielāpot nekavējoties, izslēgšana nav nepieciešama.
• Publiski pieejams serveris, atjauninājums īsā laikā nav iespējams: ierobežot piekļuvi (piemēram, ar ugunsmūri tikai zināmām adresēm) vai pakalpojumu īslaicīgi izslēgt, īpaši pie mod_php.
• Tikai iekšēji pieejams serveris: ielāpot drīz, steidzamība ir mazāka.

Biežāk uzdotie jautājumi

Vai man jāatjaunina WordPress, Joomla vai Nextcloud?

Ne šīs ievainojamības dēļ. Tā atrodas PHP, nevis lietojumprogrammā. Atjauniniet PHP versiju serverī. Lietojumprogrammas atjaunināšana tomēr ir lietderīga neatkarīgi no tā.

Kā noteikt, vai kāds ievainojamību jau ir izmantojis?

Droši to pateikt ir grūti. Aizdomas var radīt nepazīstami PHP faili tīmekļa direktorijā, neparasti procesi tīmekļa servera lietotāja vārdā, jauni lietotāju konti vai cron uzdevumi un neparasta izejošā datplūsma. Konkrētu aizdomu gadījumā sistēma jāpārbauda kriminālistiski un šaubu gadījumā jāuzstāda no jauna.

Vai ar tīmekļa lietojumprogrammu ugunsmūri (Web Application Firewall) pietiek?

Ugunsmūris var apturēt zināmus uzbrukumu modeļus, taču tas neaizstāj atjauninājumu. Vairāk par vairāku aizsardzības slāņu sadarbību lasiet mūsu rakstā Odoo 19 aizsardzība: ugunsmūris, 2FA & Web RBL. Šie principi attiecas uz jebkuru tīmekļa lietojumprogrammu.

Vai tas skar Odoo?

Nē. Odoo ir uzrakstīts Python valodā un nedarbojas uz PHP. Skartas varētu būt tikai PHP lietojumprogrammas, kas darbojas tajā pašā serverī.

Kur atrast oficiālo informāciju?

PHP drošības komandas paziņojumu atradīsiet php.net ziņu arhīvā (ieraksts no 2026. gada 20. oktobra), versijas — vietnē php.net/downloads. BSI brīdinājuma numurs ir 2026-297981-1032, un tas publicēts vietnē bsi.bund.de .

Biricon IT Services atbalsts

Ja neesat pārliecināti, kura PHP versija darbojas Jūsu serverī, vai Jums nepieciešama palīdzība ar ielāpu uzstādīšanu, mēs labprāt palīdzēsim: ar visu PHP sistēmu uzskaiti, atjauninājumu uzstādīšanu, pāreju uz atbalstītu PHP versiju un pārbaudi, vai sistēma nav kompromitēta. Kā IT pakalpojumu sniedzējs mēs apkalpojam serverus, ugunsmūrus un tīmekļa lietojumprogrammas mazajiem un vidējiem uzņēmumiem.

Sazināties tagad

Stāvoklis uz 2026. gada 21. oktobri. Situācija var strauji mainīties; noteicošie ir PHP drošības komandas un BSI publicētie materiāli.