Mājaslapa strādā. Kāpēc šodien ar to nepietiek?

PHP2Shell, divas kritiskas ievainojamības un ļoti labs iemesls noskaidrot, kurš pieskata jūsu digitālās saimniecības durvis.

2026. gada 21. oktobris.

Iztēlojieties gluži parastu uzņēmēja rītu. Kafija ir karsta, pasūtījumi pienāk, un mājaslapā beidzot nomainīts attēls, kuru bija plānots nomainīt jau pavasarī. Tad telefonā parādās ziņa: “Steidzami jāatjaunina PHP.” Jūs paskatāties uz savu nevainojami strādājošo mājaslapu un nodomājat: lieliski, tagad arī internetam vajadzīga tehniskā apskate.

Vietne tiešām atveras. Pogas spiežas, produkti grozā iekrīt, un nekas neliecina, ka digitālajā saimniecībā būtu ieradies nelūgts viesis. Taču tieši te sākas šī stāsta nepatīkamākā daļa: mājaslapas ārējais miers ļoti maz pasaka par tās tehnisko drošību. Skaista fasāde vēl nav atbilde uz jautājumu, kas notiek aiz durvīm.

gada 21. oktobrī PHP izstrādātāji izlaida labojumus divām kritiskām ievainojamībām. Noteiktos apstākļos tās ļauj uzbrucējam panākt sava koda izpildi serverī, pat nepieslēdzoties vietnei. Šoreiz atjauninājumu paziņojums ir pelnījis vairāk uzmanības nekā kārtējais atgādinājums piekrist sīkdatnēm. [1]

Vispirms iepazīsim to, kurš strādā aiz letes

Ja saīsinājums PHP jums neko neizsaka, jūs esat labā kompānijā. Cilvēkam nav jāzina motora uzbūve, lai brauktu ar automašīnu, un nav jāmāk programmēt, lai vadītu interneta veikalu. Tomēr reizēm ir noderīgi saprast, kāpēc meistars zvana par dzinēju, lai gan virsbūve joprojām spīd.

PHP ir programmēšanas valoda un tās izpildes vide, ar kuru darbojas daudzu mājaslapu aizkulises. Kamēr apmeklētājs redz glītu produktu katalogu, serverī tiek apstrādāti pieprasījumi, sagatavots saturs un iegūta informācija no datubāzes. WordPress un daudzi interneta veikali izmanto PHP, lai vietne spētu paveikt vairāk par nekustīga plakāta demonstrēšanu.

Iztēlosimies mājaslapu kā veikalu. Dizains ir skatlogs, lapu saturs — plaukti, bet PHP ir daļa no aizkulišu darba, kas ļauj šo veikalu apkalpot. Var nopirkt visskaistāko izkārtni pilsētā, taču tā nepalīdzēs, ja tehniskajās telpās atklājusies bīstama kļūme. Un tieši par šādu kļūmi pašlaik ir stāsts.

“Manai lapai taču nav nekā interesanta”

Šis ir saprotams mierinājums. Nelielam uzņēmumam var šķist, ka kibernoziedznieki nodarbojas tikai ar bankām, ministrijām un kino cienīgiem seifiem. Kuram gan būtu vajadzīga neliela galdnieka mājaslapa vai blogs par tomātu audzēšanu?

Taču automatizētam uzbrucējam nav jāsajūsminās par jūsu produkciju. Viņu var interesēt servera resursi, iespēja ievietot svešu saturu vai piekļūt informācijai, kas pieejama mājaslapas procesam. Mazs veikals arī ir veikals, un durvju rokturi var paraustīt, iepriekš neizlasot uzņēmuma misiju.

Vienlaikus ievainojama vietne vēl nenozīmē uzlauztu vietni. Šī atšķirība ir svarīga: satraukumam jāpalīdz rīkoties, nevis izdomāt jau notikušu katastrofu. Ir atklāta nopietna iespēja uzbrukumam, un tā jānovērš, pirms hipotētiskais scenārijs iegūst jūsu uzņēmuma rekvizītus.

Parole ar izsaukuma zīmi šoreiz neizglābs

Abas kļūdas publiski pazīstamas ar nosaukumu PHP2Shell. To tehniskie identifikatori ir CVE-2026-109618 un CVE-2026-109619, bet CERT-EU katrai norāda bīstamības vērtējumu 9,2 no 10. Tas nav procentuāls uzlauztu mājaslapu skaits; tas raksturo problēmas smagumu. [2]

Bīstamā iespēja saucas attālināta koda izpilde jeb RCE. Cilvēciskā valodā: uzbrucējs var panākt, ka serveris izpilda viņa norādījumus. Ko viņš pēc tam spētu paveikt, atkarīgs no piekļuves tiesībām un servera izolācijas, taču mājaslapai un tai pieejamajiem datiem sekas var būt nopietnas.

Viena kļūda rodas atmiņas trūkuma apstrādē: pieprasījums var tikt pārtraukts, pirms iekšējās datu struktūras pienācīgi sagatavotas, un to vēlākā sakopšana var radīt atmiņas bojājumu. Otra ļauj saglabāties atsaucēm uz jau atbrīvotu atmiņu, kurām noteiktos apstākļos piekļūst nākamais pieprasījums tajā pašā darba procesā. Programmētāji otrajā aprakstā atpazīs use-after-free; pārējiem pietiek saprast, ka sistēma var sākt izmantot informāciju, kurai vairs nedrīkst uzticēties. [3][4]

Īpaši nepatīkama detaļa: Apache konfigurācijā ar mod_php demonstrēts uzbrukums pirms pašas lietotnes koda izpildes. Tāpēc pat rūpīgi izveidota pieslēgšanās forma var nepaspēt iesaistīties notikumos. Brīdinājums attiecas arī uz PHP-FPM, php-cgi, FrankenPHP un LiteSpeed; administratora parole “TikaiEsZinu2026!” šo PHP kļūdu nelabo. [1]

Labās ziņas: durvis var salabot

Šim stāstam ir ļoti praktiska labā ziņa: labojumi ir pieejami. Nav jāgaida brīnumlīdzeklis vai jāpārbūvē visa mājaslapa tikai tāpēc, ka internetā atkal notiek kaut kas nepatīkams. Jāievieš konkrētajai vietnei piemērots PHP drošības atjauninājums.

gada 21. oktobrī pirmās versijas ar abu kļūdu labojumiem ir šādas. Ja rakstu lasāt vēlāk, pārbaudiet arī jaunākos drošības laidienus un sava piegādātāja paziņojumus. Ar laiku “jaunākā versija” mainās; šeit minētie numuri fiksē konkrētās dienas labojumus. [1]

Ja vietne izmanto šo PHP zaru	Pirmā labotā versija
8.2	8.2.35
8.3	8.3.36
8.4	8.4.27
8.5	8.5.12

Te paslēpies neliels ciparu detektīvs: uzraksts “PHP 8.5” vēl neapstiprina, ka izmantota 8.5.12. Savukārt profesionālu Linux pakotņu piegādātāji var iestrādāt labojumus arī būvē ar vecāku pamatversijas numuru. Tad vajadzīgs konkrētās pakotnes un abu ievainojamību labojumu apstiprinājums, nevis minējums pēc pirmā cipara. PHP 8.1 un vecāku zaru lietotājiem jānoskaidro piegādātāja atbalsts vai jāplāno pāreja uz atbalstītu vidi. [2]

Lielākā poga panelī ne vienmēr ir pareizā

Pēc šādām ziņām rodas vēlme atvērt hostinga paneli un izvēlēties pašu lielāko pieejamo versijas numuru. Sajūta ir patīkama: pāris klikšķu, un jūs esat cilvēks, kurš tikko izglābis savu biznesu. Pēc tam atverat veikalu un atklājat, ka maksājumu modulis par šo varoņdarbu nav informēts.

Pāreja uz citu PHP zaru var atklāt nesaderību vecā kodā, moduļos vai papildinājumos. Arī PHP migrācijas dokumentācija aicina pārbaudīt saderību pirms pārslēgšanas reālajā darbības vidē. Tāpēc vietnei, kas strādā ar atbalstītu PHP 8.3, konkrētās problēmas novēršanai var pietikt ar 8.3.36; tai nav obligāti tajā pašā dienā jāpārceļas uz 8.5. [6]

Labs uzturētājs vispirms noskaidro, kas vietni darbina, sagatavo atjaunošanas iespēju un ievieš piemērotu labojumu. Pēc tam viņš pārbauda arī lietas, kas sākumlapas ekrānattēlā nav redzamas: pieteikuma nosūtīšanu, pieslēgšanos, pasūtījumu un citas biznesam svarīgas darbības. Jo uzņēmējam vajag strādājošu veikalu, un drošības atjauninājuma sekmes nevar izmērīt tikai ar skaistu pirmo lapu.

Kam īsti tagad jāzvana?

Mājaslapas īpašniekam nav vienā vakarā jākļūst par serveru administratoru. Viņa svarīgākais uzdevums ir panākt, lai būtu skaidrs atbildīgais un pārbaudīts rezultāts. Sarežģījumi sākas brīdī, kad īpašnieks domā, ka visu izdara hostings, hostings gaida klienta izvēli panelī, bet izstrādātājs pēc vietnes nodošanas vairs nav iesaistīts.

Sāciet ar hostinga atbalstu vai savu uzturētāju un pajautājiet: “Vai manas vietnes PHP ir saņēmis abu šodien izziņoto ievainojamību labojumus, un vai pēc atjaunināšanas ir pārbaudīta vietnes darbība?” Ja vajag precizēt, pievienojiet abus CVE numurus. Šim jautājumam nav vajadzīgs programmētāja diploms, bet atbildei gan vajadzētu būt konkrētākai par “mēs drošību uztveram nopietni”.

Jāpārbauda arī pārējie domēni un aizmirstās testa vietnes. Piemēram, cPanel ļauj dažādiem domēniem izmantot atšķirīgas PHP konfigurācijas, tāpēc viena pārslēgšana ne vienmēr sakārto visu saimniecību. [5] Testa lapa, kuru “rīt izdzēsīsim” jau trešo gadu, šādā brīdī kļūst par pārsteidzoši svarīgu ģimenes locekli.

Uzturētājiem ir vēl viena būtiska nianse: php -v parāda palaistā komandrindas PHP versiju, bet ar to vien nepietiek, lai apstiprinātu vietnes tīmekļa izpildes vides stāvokli. [7] Jāpārbauda faktiskie apstrādātāji, visas instances un tas, ka pieprasījumus vairs neapkalpo vecie darba procesi. Atjauninājuma fails diskā vēl nav tas pats, kas atjauninājums darbībā.

Ja labojumu uzreiz ieviest nevar, CERT-EU iesaka apsvērt ievainojamās lietotnes izolēšanu no publiskā tīkla līdz labojuma ieviešanai un pārbaudei. Pagaidu aizsardzības pasākumi neaizstāj pašu labojumu. [2] Arī uzraksts “Notiek apkope” palīdz tikai tad, ja risinājums patiešām aptur publisku piekļuvi ievainojamajai videi; plāksnīte uz durvīm pati par sevi durvis neaizslēdz.

Par ko patiesībā maksājam profesionālim?

Ja savu pirmo mājaslapu vēl tikai plānojat, šis viss var izklausīties pārsteidzoši. Reklāmā taču bija vienkārši: izvēlies dizainu, ievieto tekstu, nospied “Publicēt”. Un tā arī var sākt — pašam izveidot lapu ir iespējams, un mācīties to darīt ir vērtīgi.

Taču uzņēmuma vietne pēc publicēšanas sāk savu darba dzīvi. Tai vajadzīgi atjauninājumi, rezerves kopijas, saderības pārbaudes un kāds, kurš reaģē uz šādām ziņām. Arī profesionāli veidotu vietni var skart vēlāk atklāta kļūda izmantotajā tehnoloģijā; profesionāļa vērtība parādās tajā, kā šāds risks tiek pārvaldīts.

Tāpēc, pasūtot mājaslapu, ir vērts pajautāt vairāk par krāsu paleti un cenu. Kurš sekos drošības paziņojumiem? Kurš atjauninās sistēmu, pārbaudīs pasūtījumus un palīdzēs, ja kaut kas salūzīs? Tie ir jautājumi, kas skaistam dizainam pievieno ļoti nepieciešamo spēju turpināt strādāt.

Atjaunināšana arī neatceļ vajadzību izmeklēt aizdomīgas izmaiņas, ja tādas jau novērotas. Svešs administratora konts vai neizskaidrojama pāradresācija ir iemesls pārbaudei; labojuma uzstādīšana pati par sevi nepierāda, ka iepriekš nekas nav noticis. Rezerves kopijas, žurnāli un uzraudzība tāpēc pieder pie ikdienas uzturēšanas, nevis tikai avārijas ceremonijas. [8]

Šodien mājaslapas īpašniekam nav jāiegaumē visi tehniskie saīsinājumi. Pietiek noskaidrot, kurš atbild par viņa vietni, vai abi labojumi ir ieviesti un vai pēc tiem viss būtiskais darbojas. Kad šīs atbildes ir saņemtas, var mierīgi atgriezties pie pasūtījumiem, klientiem un tā attēla, kuru beidzot nomainījāt.

Bet kafiju gan droši vien vajadzēs jaunu. Šī pa to laiku būs atdzisusi.

Avoti

Atgriezties pie jaunumiem