PHP2Shell atgādina nepatīkamu patiesību: interneta veikals var pieņemt pasūtījumus, kamēr tā tehniskajā pamatā ir nopietna drošības problēma. Kā saprast, vai risks attiecas arī uz jūsu vietni, un ko darīt tālāk?

2026. gada 22. oktobris

Iedomājieties, ka no rīta atverat savu mājaslapu. Produkti redzami, pogas darbojas, kontaktforma nosūta ziņas, un vakar vakarā pievienotais attēls beidzot izskatās tā, kā vajag. Viss kārtībā — līdz brīdim, kad kāds pajautā: „Vai jūsu serverim ir uzstādīti jaunākie PHP drošības labojumi?”

Uz šo jautājumu ir vilinoši atbildēt: „Kāpēc gan lai nebūtu? Lapa taču strādā!” Diemžēl mājaslapas darbība un mājaslapas drošība nav viens un tas pats. To 2026. gada 21. oktobrī atgādināja divas kritiskas PHP ievainojamības, kuras kopīgi dēvē par PHP2Shell. Šis nav stāsts tikai programmētājiem — tas ir arī stāsts ikvienam, kam internetā ir uzņēmuma vizītkarte, blogs, rezervāciju sistēma vai veikals.

Redzamā mājaslapa un neredzamā tehniskā telpa

Mājaslapu var salīdzināt ar veikalu. Apmeklētājs redz izkārtni, sakārtotus plauktus un laipnu pārdevēju. Taču aiz skatloga ir elektroinstalācija, signalizācija, noliktava un durvis, kuras pircējiem vispār nevajadzētu redzēt. Ja kādā no šīm sistēmām rodas kļūme, skaists skatlogs to neatklās.

Daudzās mājaslapās daļa šī neredzamā darba notiek ar PHP palīdzību. Tā ir programmēšanas valoda un izpildes vide, kas apstrādā servera pieprasījumus, sagatavo lapas saturu un palīdz lietotnei sazināties ar datubāzi. PHP izmanto, piemēram, WordPress un daudzas interneta veikalu sistēmas. Jums nav jāprot PHP, lai vadītu savu biznesu, bet ir lietderīgi zināt, kurš uztur šo tehnisko pamatu.

Kas ir PHP2Shell, un kāpēc par to sacelta trauksme?

  1. gada 21. oktobrī PHP projekts izlaida drošības atjauninājumus divām kritiskām ievainojamībām — CVE-2026-109618 un CVE-2026-109619. Abām piešķirts 9,2 punktu vērtējums no 10 pēc CVSS v4.0 skalas. Tas nenozīmē, ka uzlauzti 92% vietņu; tas norāda uz potenciāli ļoti smagām sekām. PHP oficiālais paziņojums un CERT-EU brīdinājums mudina rīkoties nekavējoties.

Abas kļūdas ir saistītas ar to, kā PHP noteiktos apstākļos apstrādā atmiņu. Tehniski runājot, viena saistīta ar atmiņas izsīkuma situācijas nepareizu apstrādi, otra — ar atsaucēm uz atmiņu, kas jau ir atbrīvota. Noteiktos apstākļos uzbrucējs var panākt attālinātu koda izpildi (RCE) serverī, turklāt bez iepriekšējas pieslēgšanās mājaslapas administrācijai.

Vienkāršāk sakot, problēma nav tikai tajā, ka kāds varētu uzminēt paroli. Risku rada kļūda pašā tehnoloģijā, kas apkalpo mājaslapu. Uzbrukuma iespējamās sekas ir atkarīgas no servera piekļuves tiesībām un izolācijas, taču tās var skart gan vietnes darbību, gan tai pieejamos datus. Vienlaikus ievainojama mājaslapa vēl nenozīmē uzlauztu mājaslapu — šīs lietas nevajag jaukt.

„Mana lapa ir pārāk maza, lai kādu interesētu”

Var šķist, ka kibernoziedzniekiem vajadzīgas tikai bankas, lielas korporācijas un valdības portāli. Taču automatizētam skenerim nav svarīgi, vai vietne pārdod tūkstošiem preču vai piedāvā vienu amatnieka pakalpojumu. Tas var vienkārši pārbaudīt, vai serverī ir zināma ievainojamība. Ja tāda ir, mazs uzņēmums nekļūst neredzams tikai tāpēc, ka tam nav milzīga apgrozījuma.

Arī WordPress administratora stipra parole, divu faktoru autentifikācija un drošības papildinājums šajā gadījumā nav pilnvērtīgs aizstājējs PHP labojumam. Tie ir vērtīgi aizsardzības slāņi pret citiem uzbrukumiem, taču PHP2Shell novēršanai vajadzīgs drošības labojums pašā PHP izpildes vidē. Arī ugunsmūris var samazināt risku, bet nav pamata pieņemt, ka tas bloķē ikvienu šīs ievainojamības izmantošanas veidu.

Kuras PHP versijas ir izlabotas?

Pirmās oficiālās PHP versijas, kurās novērstas abas 2026. gada 21. oktobrī izziņotās ievainojamības, ir šādas:

PHP versiju saime Pirmā versija ar labojumiem
PHP 8.2 8.2.35
PHP 8.3 8.3.36
PHP 8.4 8.4.27
PHP 8.5 8.5.12

Te ir neliela, bet svarīga nianse. Ja hostinga panelī redzams „PHP 8.5”, tas vēl nenozīmē, ka darbojas tieši 8.5.12. Piemēram, vietnei joprojām var būt ieslēgta 8.5.11, kurā šie konkrētie labojumi vēl nav iekļauti. Savukārt daži Linux izplatītāji un hostinga nodrošinātāji drošības labojumus var iestrādāt savās pakotnēs, saglabājot vecāku redzamo versijas numuru. Šādā gadījumā jāprasa konkrēts piegādātāja apstiprinājums par abiem CVE, nevis jāmin pēc cipariem.

PHP 8.1 un vecākām saimēm vairs nav PHP projekta parastā drošības atbalsta. Ja vietne vēl izmanto šādu versiju, jānoskaidro, vai piegādātājs nodrošina īpaši uzturētu, salabotu pakotni, vai arī jāplāno pāreja uz atbalstītu vidi. Skatiet PHP drošības paziņojumu.

Vai vienkārši pārslēgties uz vislielāko numuru?

Šāda doma ir saprotama: atveram hostingu, izvēlamies jaunāko PHP versiju, nospiežam „Saglabāt”, un drošības jautājums atrisināts. Tikai pēc tam izrādās, ka interneta veikala maksājumu modulis, vecs papildinājums vai individuāli veidota funkcija jaunajā vidē nestrādā. Mājaslapa var izskatīties pareizi, bet pasūtījuma nosūtīšana vairs neizdodas — savdabīga uzvara pār kibernoziedzniekiem, ja vienlaikus nevar nopirkt arī klienti.

Tāpēc vajadzīgs nevis akls versijas lēciens, bet pārbaudīts atjauninājums. Vispirms noskaidro, kuru PHP versiju reāli izmanto konkrētais domēns, sagatavo rezerves kopiju un pārbaudi programmatūras saderību. Pēc labojuma ieviešanas jāizmēģina ne tikai sākumlapa, bet arī pieslēgšanās, formas, pirkumu grozs, pasūtījumi un citas uzņēmumam svarīgas darbības. WordPress, PrestaShop un citu sistēmu tehniskās prasības var atšķirties, tāpēc vienas vietnes veiksmīgs atjauninājums negarantē otras saderību.

Piecas darbības, kuras mājaslapas īpašnieks var sākt jau šodien

1. Noskaidro precīzu PHP versiju. Nepietiek ar „8.5” vai „8.4”. WordPress vietnē to var pārbaudīt sadaļā Rīki → Vietnes veselība → Informācija → Serveris; citās sistēmās — servera informācijas sadaļā vai ar hostinga palīdzību. Vienā hostinga kontā dažādi domēni var izmantot atšķirīgas PHP konfigurācijas.

2. Pārbaudi, kurš ievieš drošības labojumus. Ja PHP uztur hostinga pakalpojumu sniedzējs, pajautā, vai abi PHP2Shell labojumi jau ieviesti. Ja serveri administrē pats vai to dara izstrādātājs, jānoskaidro faktiski darbojošās PHP instances, nevis tikai komandrindas php -v rezultāts.

3. Sagatavo rezerves kopijas ārpus servera. Nepaļaujies tikai uz vienu kopiju tajā pašā hostingā. Saglabā gan vietnes failus, gan datubāzi un pārliecinies, ka vajadzības gadījumā no tiem iespējams atjaunot darbību. Rezerves kopija neaizlāpa ievainojamību, bet var būt izšķiroša kļūmes vai incidenta gadījumā.

4. Pārskati papildinājumus un piekļuves tiesības. Novecojuši spraudņi, aizmirstas testa vietnes, nevajadzīgi administratoru konti un vāji aizsargāti servisi rada papildu riskus. Atjaunini izmantotos moduļus pēc saderības pārbaudes, nevajadzīgos izņem un ieslēdz divu faktoru autentifikāciju, kur tā pieejama. Šie pasākumi neaizstāj PHP labojumu, toties palīdz samazināt kopējo uzbrukuma virsmu.

5. Pārbaudi, vai nav neizskaidrojamu izmaiņu. Nezināms administratora konts, negaidīta pāradresācija, pēkšņas izmaiņas failos vai aizdomīgi žurnālu ieraksti ir iemesls pārbaudei. Pat tad, ja drošības skeneris neko nav atradis, tas nav absolūts pierādījums, ka ielaušanās nav notikusi. Ja rodas aizdomas par kompromitēšanu, saglabā žurnālus un iesaisti speciālistu.

Ja labojumu uzreiz nav iespējams ieviest, CERT-EU iesaka apsvērt ievainojamo publisko pakalpojumu izolēšanu līdz atjaunināšanai. Pagaidu aizsardzības noteikumi neaizstāj pašu drošības labojumu.

Kad vajadzīga profesionāla palīdzība, nevis vēl viens klikšķis?

Ne katram uzņēmējam jākļūst par programmētāju vai serveru administratoru. Taču ir vērts zināt, kam piezvanīt, kad parādās nopietns drošības paziņojums. Labs mājaslapas izstrādes un uzturēšanas partneris neapstājas pie skaista dizaina: viņš palīdz saprast tehniskās prasības, izvērtēt saderību, plānot atjauninājumus un pārbaudīt, vai svarīgākās vietnes funkcijas pēc izmaiņām joprojām darbojas.

Ja šobrīd nav skaidrs, kurš pieskata jūsu vietnes tehnisko pusi, viena no vietām, kur meklēt palīdzību, ir CraftIN IT Solutions. Tas ir mājaslapu izstrādes un digitālo risinājumu virziens, kur var vērsties ar jautājumiem par vietnes izveidi, tehniskām problēmām un tās turpmāko uzturēšanu. Svarīgākais nav saņemt solījumu, ka drošības problēmu nekad nebūs, bet gan skaidru plānu, kā tās laikus pamanīt un atbildīgi risināt.

Pirms uztici kādam mājaslapu, pajautā ne tikai par cenu un dizaina paraugiem. Noskaidro arī, kas atbildēs par atjauninājumiem, rezerves kopijām, saderības pārbaudēm un rīcību incidenta gadījumā. Mājaslapa nav vienreiz izgatavota izkārtne, ko pēc publicēšanas var aizmirst; tā ir sistēma, kurai nepieciešama uzturēšana.

Noslēgumā: skaista fasāde vēl nenozīmē aizslēgtas durvis

PHP2Shell ir labs atgādinājums tam, cik daudz svarīga mājaslapā paliek neredzams. Apmeklētājs redz saturu un pogas, bet uzņēmuma drošību ietekmē servera programmatūra, tās versijas, papildinājumi un cilvēki, kuri par tiem rūpējas. Panika neko nesalabos, savukārt precīza pārbaude un savlaicīgi atjauninājumi var palīdzēt izvairīties no daudz lielākām problēmām.

Tāpēc šodien pietiek sākt ar trim jautājumiem: kāda PHP versija patiešām darbina manu vietni, vai tai ir abi nepieciešamie labojumi un kurš to var apstiprināt? Ja vajadzīga palīdzība ar atbildēm vai mājaslapas tehnisko sakārtošanu, apskati CraftIN IT Solutions. Un tad var atgriezties pie sava darba — vēlams, kamēr kafija nav atdzisusi pavisam.

Avoti un papildu lasāmviela

Loading

Noderīgs raksts? Dalies ar citiem:
Dalīties: