Ko darīt, ja mājaslapa ir uzlauzta vai serverī parādās aizdomīga datplūsma?

2026. gada oktobrī izlaistie kritiskie PHP drošības labojumi atgādina, kāpēc jāpārbauda arī mājaslapas tehniskais pamats. PHP izpildvidē darbojas daudzas mājaslapas, e-veikali un biznesa sistēmas. Tās kļūda var apdraudēt arī vietni ar jaunu dizainu un regulāri atjauninātu satura vadības sistēmu.

Ceļvedī skaidrojam, kas ir mainījies, kā atšķirt brīdinājumu no apstiprināta incidenta un ko prasīt tehniskajai komandai. Aplūkojam arī personas datu aizsardzības pienākumus un mākslīgā intelekta (AI) izmantošanu drošības izpētē un kibernoziedzībā. Daudz atrastu kļūdu vēl nenozīmē tikpat daudz reālu uzbrukumu.

Fakti un norādītās versijas pārbaudītas 2026. gada 31. oktobrī. PHP drošības paziņojumi, AI piemēri un GDPR norādes atkārtoti pārbaudītas 2026. gada 4. novembrī. Pirms atjaunināšanas pārbaudiet arī jaunākos PHP un sava hostinga vai operētājsistēmas piegādātāja paziņojumus.

Piecas pirmās darbības, ja aizdomas radušās jau tagad

Tālāk aprakstītās darbības palīdz sagatavoties sarunai ar speciālistiem un sekot viņu darbam. Vienam uzņēmumam pietiks izolēt vietni, citam būs jāpārbauda arī hostinga konts, e-pasts, datubāze un savienojumi ar iekšējām sistēmām. Visām mājaslapām vienāds risinājums nederēs.

Kas ar PHP notika 2026. gada oktobrī?

21. oktobrī PHP projekts izlaida labojumus kritiskajām ievainojamībām CVE-2026-109618 un CVE-2026-109619. Noteiktos apstākļos tās ļauj attālināti izpildīt kodu, nepieslēdzoties lietotāja kontam. Šādu iespēju apzīmē ar RCE (remote code execution). Uzbrucējs var panākt, ka serveris izpilda viņa kodu ar pārņemtā procesa tiesībām.

Pirmā kļūda saistīta ar nepabeigta iekšējā stāvokļa apstrādi, kad pietrūkst atmiņas. Otrajā gadījumā iepriekšējā pieprasījuma stāvoklī var saglabāties norāde uz jau atbrīvotu atmiņu. Abas problēmas ir PHP izpildvidē, bet to izmantošanas iespējas ir atkarīgas no konkrētās darbības vides.

PHP projekta CVE-2026-109618 paziņojums un CVE-2026-109619 paziņojums, 21.10.2026.

Tabulā ir pirmās versijas ar šiem labojumiem, nevis ieteikums turpmāk izmantot tikai tās. Linux distribūcijas uzturētājs drošības labojumu var iekļaut arī vecākas versijas pakotnē. Šādu praksi sauc par backport. Tāpēc jāpārbauda piegādātāja drošības paziņojums un pilns pakotnes numurs.

PHP brīdinājums attiecas uz tīmekļa pieprasījumu apkalpošanu ar FPM, Apache mod_php un citiem integrācijas veidiem. Augstākais risks norādīts mod_php, kur demonstrēta ievainojamības izmantošana vēl pirms lietotnes koda izpildes. Ar to vien, ka mājaslapa izmanto FPM, nepietiek, lai secinātu, ka tā ir droša.

PHP projekta 21. oktobra drošības paziņojums.

Tas vairs nav tikai teorētisks brīdinājums

CISA katalogā, kurā apkopo zināmas uzbrukumos izmantotas ievainojamības, abi CVE pievienoti 26. oktobrī. AWS savā 21. oktobra ziņojumā apraksta MadPot novērotu izmantošanas mēģinājumu jau 17. oktobrī, pirms publiskā paziņojuma. Tas pamato steidzamas pārbaudes vajadzību, taču nepierāda, ka konkrētā uzņēmuma serveris ir uzlauzts.

CISA KEV oficiālie dati, 03.11.2026. kataloga versija, pārbaudīta 04.11.2026.; AWS Threat Intelligence novērojums, 21.10.2026.

Arī CERT.LV 21. oktobrī ziņoja par automatizētiem mēģinājumiem Latvijā. Tajā pašā dienā plkst. 23.00 iestāde norādīja, ka tobrīd nav ziņu par sekmīgiem uzbrukumiem. Tas ir konkrētā brīža situācijas vērtējums. Preventīvi piekļuves ierobežojumi dažiem resursiem nav pierādījums, ka tie būtu uzlauzti.

CERT.LV paziņojums par situāciju Latvijā, 21.10.2026., atjauninājums plkst. 23.00.

Pēc ārkārtas labojuma sekoja vēl divi precizējumi

23. oktobrī PHP publicēja informāciju par atsevišķu gadījumu CVE-2026-115560. Tas saistīts ar neparastu sesiju serializētāja maiņu lietotnes darbības laikā un ieslēgtu augšupielādes progresa funkciju. 21. oktobra laidieni šo atsevišķo gadījumu nenovērš. Piegādātājs apraksta pagaidu konfigurācijas pasākumu līdz nākamajam regulārajam labojumam. Šī nav vienāda riska situācija pilnīgi visām vietnēm.

26. oktobrī izlaistas Windows pakotņu pārbūves 8.2.35-1, 8.3.36-1, 8.4.27-1 un 8.5.12-1. Tajās atjaunināta Brotli bibliotēka, novēršot CVE-2026-111497. Problēma var rasties, ja lietotne ieslēdz cURL automātisko HTTP atbilžu atspiešanu. PHP pamata versijas numurs šajā pārbūvē nemainās.

Atjaunināšanu var uzskatīt par pabeigtu pēc pakotņu un konfigurācijas pārbaudes. Ekrānattēls ar tekstu “PHP atjaunināts” vēl neparāda, vai labojums darbojas konkrētajā vidē.

PHP 23. un 26. oktobra paziņojumi; Brotli 1.2.1 izlaidums.

“PHP problēma” var nozīmēt vairākas atšķirīgas lietas

Mājaslapu veido vairāki tehnoloģiju slāņi. Pirms drošības darbiem jāapzina, kas tajos darbojas, kur tas izvietots un kurš to uztur.

• Serveris un infrastruktūra. Operētājsistēma, tīmekļa serveris, hostinga pārvaldība, tīkla noteikumi un bibliotēkas.
• PHP izpildvide un konfigurācija. Konkrētā versija, FPM vai cita integrācija, paplašinājumi un konfigurācijas parametri.
• Lietotne. WordPress, Drupal, PrestaShop, Laravel projekts vai individuāls risinājums; arī spraudņi, moduļi un Composer pakotnes.
• Piekļuves un savienojumi. Administratori, SSH atslēgas, datubāzes konti, e-pasts, CRM, maksājumi, izvietošanas rīki un AI pakalpojumi.

To parāda PrestaShop moduļa ps_facetedsearch ievainojamība CVE-2026-54159. Piegādātājs paziņojumu publicēja 3. jūnijā, bet CERT.LV brīdināja 8. oktobrī. Norādītas skartās moduļa versijas no 3.0.0 līdz 4.0.3, savukārt labojums iekļauts 4.0.4. Nozīme ir arī attiecīgo cenu vai svara slīdņa filtru izmantošanai. PHP atjaunināšana pati par sevi šo moduļa kļūdu nenovērš.

PrestaShop moduļa drošības paziņojums; CERT.LV brīdinājums.

Savukārt CVE-2024-4577 attiecas uz vēsturisku Windows/PHP-CGI konfigurācijas problēmu. Tā nav jauna 2026. gada kļūda, un to nevar automātiski attiecināt uz katru Linux serveri. Lai izvēlētos labojumu, jānoskaidro konkrētā problēma un konfigurācija, nevis jāvadās tikai pēc vārda “PHP” paziņojuma virsrakstā.

DEVCORE sākotnējais pētījums par CVE-2024-4577, 06.06.2024.

Par ko liecina neparasta datplūsma, un ko tā vēl nepierāda?

Vai kāds sūta daudz pieprasījumu jūsu serverim, vai serveris pats veido negaidītus savienojumus? Vispirms jānošķir šīs situācijas. Hostinga paneļa “izejošie baiti” var būt arī parastas atbildes apmeklētājiem. Tas nav tas pats, kas servera uzsākts savienojums ar svešu sistēmu.

Tabulā ir praktiski piemēri, kas palīdz izvēlēties pārbaudes virzienu. Ar vienu datplūsmas diagrammu nepietiek, lai noteiktu incidenta cēloni.

Viena ārvalstu IP adrese nepierāda uzbrucēja atrašanās vietu. User-Agent tekstu var norādīt pats pieprasījuma sūtītājs. Arī HTTP 200 atbilde nepierāda veiksmīgu koda izpildi, savukārt 404 neatceļ iespēju, ka citā pieprasījumā uzbrukums izdevās.

Secinājums kļūst pamatotāks, ja konkrētu pieprasījumu var saistīt ar jaunu procesu, faila izmaiņām, neparedzētu savienojumu un neatļautu darbību kontā. Tie ir neatkarīgi pierādījumi, kas jāvērtē kopā. Ja žurnāli nav saglabāti, daļu notikušā var nebūt iespējams droši noskaidrot. Tad nav pamata apgalvot, ka nekas nav noticis.

Pirmajā stundā svarīgākais ir apturēt kaitējumu

Ne katru incidentu var atrisināt 60 minūtēs. Šajā sadaļā aprakstīti pirmie darbi, kas jāsāk vienlaikus. Tehniskā komanda ierobežo kaitējumu, uzņēmums noskaidro ietekmi uz klientiem, bet atbildīgais cilvēks pieraksta lēmumus.

Uzticiet darbu koordinēšanu vienam cilvēkam

Ja īpašnieks, hostinga pakalpojuma sniedzējs, izstrādātājs un mārketinga speciālists rīkojas katrs atsevišķi, kļūst grūti izsekot izmaiņām. Vienojieties, kurš tās apstiprina un kur pieraksta paveikto. Katram ierakstam vajadzīgs laiks, novērojums, veiktā izmaiņa, tās veicējs un rezultāts.

Jau pirmajā sarunā noskaidrojiet, kuri pakalpojumi izmanto to pašu infrastruktūru. Vienā hostinga kontā var būt uzņēmuma mājaslapa, vecs testa projekts un vairāki klientu domēni. Ja problēma sākusies vienā vietnē, nevar automātiski pieņemt, ka pārējās ir neskartas.

Saglabājiet pierādījumus, nezaudējot laiku aktīva kaitējuma apturēšanai

Kopā ar hostinga pakalpojuma sniedzēju vai administratoru saglabājiet pieejamos žurnālus, failu un datubāzes stāvokli un, ja vajadzīgs, sistēmas momentuzņēmumu. Pierādījumu kopiju glabājiet atsevišķi, ar ierobežotu piekļuvi. No tās nedrīkst bez pārbaudes atjaunot publisko vietni.

Pārstartēšana var izdzēst atmiņā esošu informāciju par procesiem un savienojumiem. Tomēr reizēm sistēma jāizslēdz, piemēram, ja notiek datu iznīcināšana un citādi kaitējumu apturēt nevar. Speciālists izvēlas pierādījumu savākšanas un izolēšanas secību atbilstoši situācijai.

NIST SP 800-86 3.1. un 5.2. sadaļā aplūkoti gaistošie pierādījumi un sistēmas izslēgšanas izvērtējums. Izmantots 2006. gadā publicētais digitālo pierādījumu izmeklēšanas pamatprincips.

Ierobežojiet skarto vidi

Atkarībā no situācijas var nākties izolēt serveri no tīkla, apturēt skarto vietni vai atsaukt konkrētas piekļuves tiesības. Saskaņojiet arī nepieciešamo pārvaldības piekļuvi, lai nejauši neliegtu piekļuvi speciālistiem, kuri atjauno sistēmu.

Ja jāinformē klienti, atsevišķā vidē, kuru uzbrucējs nav skāris, var izvietot statisku paziņojuma lapu. Apkopes režīms tajā pašā uzbrucēja skartajā satura vadības sistēmā (CMS) neapliecina, ka viņa darbība ir apturēta. Tīmekļa lietotnes ugunsmūra (WAF) noteikumi var aizturēt daļu uzbrukuma mēģinājumu, taču neaizstāj labojumu un incidenta izmeklēšanu.

NCSC tehniskās reaģēšanas vadlīnijas aplūko incidenta ierobežošanu un cēloņa novēršanu. Darbības jāpielāgo konkrētajai sistēmai.

Saziņā ar iesaistītajiem balstieties uz pārbaudāmiem faktiem

Sākotnējā ziņojumā norādiet domēnu, pazīmes, to pamanīšanas laiku, hostinga pakalpojuma sniedzēju un jau veiktās darbības. Iespējama neatļauta piekļuve, ko vēl pārbaudāt, nav tas pats, kas apstiprināta klientu datu noplūde. Taču arī apgalvot, ka dati nav skarti, drīkst tikai tad, ja tam ir tehnisks pamatojums.

Ja ir pamats ziņot par incidentu vai vajadzīga koordinācija, izmantojiet CERT.LV norādīto kārtību. Atsevišķiem uzņēmumiem var būt īpaši nozares, līgumu vai kiberdrošības ziņošanas pienākumi; tie jāpārbauda paralēli GDPR izvērtējumam.

Ko nedarīt, pat ja gribas salabot visu uzreiz

Vietne pelna naudu, klienti zvana, bet hostinga pakalpojuma sniedzējs prasa rīkoties. Steiga ir saprotama, tomēr dažas šķietami ātras darbības var pasliktināt situāciju.

• Nedzēsiet visu aizdomīgo bez saglabāšanas. Faila saturs, atrašanās vieta un laika atzīmes var palīdzēt noskaidrot, kā uzbrucējs iekļuvis sistēmā. Analizējiet to izolēti; nepalaidiet atrasto PHP failu pārlūkā “pārbaudei”.
• Nepalaidiet vakardienas kopiju uzreiz publiskajā vidē. Uzbrukums varēja sākties agrāk. Kopijā var būt gan ļaunatūra, gan tā pati neatrisinātā ievainojamība.
• Neuzskatiet atjauninājumu vai skenera zaļo rezultātu par incidenta noslēgumu. Ar tiem vien nevar pārbaudīt visus kontus, savienojumus un uzbrucēja atstātās piekļuves.
• Nemainiet paroles no aizdomīgas ierīces. Ja uzbrucējs joprojām kontrolē datoru, pastkasti vai pārvaldības vidi, jaunā parole var nonākt pie viņa tikpat ātri. Piekļuves sakārtojiet no uzticamas vides.
• Neatslēdziet aizsardzības mehānismus uz labu laimi. Plašas failu rakstīšanas tiesības, noņemti resursu ierobežojumi vai akli pārkopēta konfigurācija var radīt nākamo problēmu. Pagaidu pasākumiem vajag konkrētu pamatojumu.
• Nepublicējiet phpinfo(), konfigurācijas failus vai pilnus žurnālus. Paroles, atslēgas, sesiju dati un klientu informācija nedrīkst nonākt publiskā forumā, nejaušā “tīrīšanas” servisā vai neapstiprinātā AI čatā.
• Neslēpiet neskaidrību aiz pārāk droša solījuma. Ja izmeklēšana turpinās, pasakiet, kas jau zināms, ko vēl pārbaudāt un kad būs nākamā informācija. “Viss kārtībā” nav incidenta atskaite.

OWASP iesaka žurnālos tieši neiekļaut paroles, piekļuves marķierus jeb tokenus, šifrēšanas atslēgas un citus noslēpumus. Arī piekļuve žurnāliem un to nosūtīšana ir jāaizsargā, lai izmeklēšana neradītu jaunu datu noplūdi.

OWASP Logging Cheat Sheet.

Ko tehniskajai komandai pārbaudīt

Tehniskajai komandai jānoskaidro, kas darbojas serverī, kādi pierādījumi saglabājušies un kā uzbrucējs varēja piekļūt sistēmai. Darbu apjomu nosaka pamanītās pazīmes un sistēmas uzbūve. Tāpēc arī turpmāk aprakstītās pārbaudes jāpielāgo konkrētajai mājaslapai. Ja kaitējums turpinās, tas jāaptur vienlaikus ar izmeklēšanu.

Jāpārbauda tā PHP vide, kas apkalpo mājaslapu

Komandrindā redzamais PHP versijas numurs vēl nepasaka, kuru versiju izmanto mājaslapa. Vienā serverī var būt vairāki PHP izpildfaili, FPM procesu grupas un konteineri. Jānoskaidro, kuru PHP saskarni jeb SAPI izmanto tīmekļa pieprasījumu apstrādei un kāda konfigurācija ir ielādēta. Kā skaidrots PHP dokumentācijā, dažādām izpildvidēm var būt atšķirīgi konfigurācijas faili. Šo informāciju iegūst servera pārvaldības vidē, neveidojot publiski pieejamu diagnostikas lapu.

Instalētās pakotnes pilnais versijas numurs jāsalīdzina ar operētājsistēmas vai hostinga piegādātāja drošības paziņojumu. Daži piegādātāji iestrādā drošības labojumu vecākā laidienā, nemainot PHP pamata versijas numuru. Šo praksi apraksta arī Red Hat. Tādēļ vecāks numurs vien nepierāda, ka sistēma ir ievainojama. Tomēr arī solījums par atbalstu neaizstāj pārbaudi, vai konkrētais labojums ir uzstādīts. Jāzina, kurš uztur pakotni un līdz kuram datumam.

Pēc atjaunināšanas pārbauda arī strādājošos procesus. Jauni faili diskā vēl nenozīmē, ka visi pieprasījumus apkalpojošie PHP procesi izmanto laboto versiju. Atkarībā no servera uzbūves var būt jānomaina procesi, jāpārstartē serviss vai jāpalaiž jauns konteiners. Jāpārliecinās, ka vecie procesi ir beiguši darbu. Šīs darbības jāsaskaņo ar pierādījumu iegūšanu un prasībām par pakalpojuma nepārtrauktību.

Žurnālu ieraksti palīdz noskaidrot notikumu secību

Tīmekļa servera piekļuves žurnāls parāda tikai daļu notikumu. Tā ierakstus salīdzina ar lietotnes kļūdu paziņojumiem, administratoru darbībām, pieslēgumiem hostingam un pieejamajiem datiem par tīkla darbību. Vispirms noskaidro laika joslas un iespējamās serveru pulksteņu nobīdes. Ierakstus par vienu darbību palīdz sasaistīt pieprasījuma identifikators, konts un laiks. OWASP vadlīnijas iesaka reģistrēt lietotnes drošības notikumus un aizsargāt žurnālus. Paroles, piekļuves marķierus un sesiju identifikatorus nevajag bez izvērtēšanas iekļaut diagnostikas izvadē.

Piemēram, savienojums ar ārēju sistēmu var būt vajadzīgs pasūtījuma nosūtīšanai. Jānoskaidro, kurš process to izveidojis, ar kāda lietotāja tiesībām, uz kurieni un vai tas noticis pasūtījuma apstrādes laikā. Aizdomas pastiprina vienlaikus pamanītas neizskaidrotas koda izmaiņas vai jauns administrators. Taču vienāda IP adrese divos žurnālos vēl nepierāda saistību starp notikumiem.

Administrators, kuram ir atļauja pārbaudīt attiecīgo Linux serveri, ar šīm komandām var nolasīt tā pašreizējo stāvokli.

date -u
ps -eo pid,ppid,user,lstart,comm
ss -ntp

Komandas rāda UTC laiku, procesus un pašreizējos TCP savienojumus. Procesu argumenti apzināti nav iekļauti, jo tajos var būt paroles vai citi piekļuves dati. Redzamo informāciju ierobežo piekļuves tiesības un konteineru robežas. Izvade neatklāj jau beigušos savienojumus un neapliecina, ka sistēma ir tīra. Ja uzbrucējs kontrolē pašu serveri, arī tā rīki var sniegt sagrozītu informāciju. Šo ierobežojumu skaidro NIST norādes par pierādījumu iegūšanu.

Jāpārbauda, vai uzbrucējs nav atstājis sev iespēju atgriezties

Ar aizdomīga PHP faila pārbaudi vien nepietiek. Mājaslapā un saistītajās sistēmās var būt arī citas izmaiņas, kas atjauno uzbrucēja piekļuvi vai turpina kaitēt apmeklētājiem. Tādēļ pārbauda vairākas vietas.

• Konfigurācijas failos meklē neizskaidrotas izmaiņas .user.ini, .htaccess, PHP automātiski ielādējamo failu iestatījumos un tīmekļa servera pieprasījumu maršrutēšanā.
• Plānotajos darbos pārbauda jaunus cron ierakstus, servisus un lietotnes uzdevumus, kuru izcelsme un vajadzība nav zināma.
• Kontos un datubāzē meklē nepazīstamus administratorus, mainītas tiesības, ievietotu JavaScript un pāradresācijas.
• Koda ieviešanas procesā pārbauda repozitoriju, izvietošanas skriptus un automatizēto pārbaužu un izvietošanas sistēmu jeb CI/CD. Izmaiņas tajos var atkal ieviest nedrošu kodu nākamajā laidienā.

Atrasto salīdzina ar uzticamu programmatūras laidienu un dokumentētajām izmaiņām. Neparasts fails var būt radīts izstrādes vajadzībām, savukārt pazīstams nosaukums nepadara failu drošu. Arī faila datums vien neapstiprina tā izcelsmi. Pārbaudes beigās jābūt skaidram, kuras sistēmas daļas ir skartas, kādi pierādījumi to apstiprina un kas vēl nav noskaidrots.

Pirms darba atsākšanas jāpārbauda atjaunotā sistēma

Atjaunošanas veids atkarīgs no incidenta apjoma. Ja nevar ticami noteikt visas uzbrucēja veiktās izmaiņas, var būt pamatotāk izveidot vidi no jauna, izmantojot uzticamus avotus, nekā labot atsevišķus failus. Jaunajā vidē ievieto pārbaudītu lietotnes kodu un nepieciešamos papildu komponentus ar izvērtētu konfigurāciju. Pārkopējot visu veco servera mapi, var pārnest arī problēmu. Šo pieeju apraksta NCSC norādes par sistēmu atjaunošanu.

Arī vecākā rezerves kopijā var būt ļaunatūra. Uzbrucējs sistēmā varēja atrasties jau pirms pirmajām pamanītajām pazīmēm. Kopiju izvēlas pēc izmeklēšanā noskaidrotās notikumu secības un pārbauda pirms izmantošanas. NIST atjaunošanas ieteikumi paredz pārbaudīt atjaunošanai izmantoto datu integritāti un novērst incidenta cēloņus, pirms sistēmu atsāk lietot ikdienā.

E-veikalam jāsaskaņo arī dati. Ja izvēlētā kopija ir no otrdienas, bet pasūtījumi saņemti līdz ceturtdienai, jānoskaidro, kā droši atgūt trūkstošos pasūtījumus un informāciju par maksājumiem. Atjaunošanas dēļ nedrīkst rasties dubulti rēķini vai pazust klientu pieteikumi. Šo pārbaudi veic kopā ar cilvēku, kurš pārzina uzņēmuma darba kārtību.

Atsevišķi jāpārskata piekļuves dati, kas nonākuši vai varēja nonākt nepiederošu personu rokās. Ar jaunas atslēgas izveidošanu nepietiek, ja vecā joprojām darbojas. OWASP vadlīnijas nošķir paroļu un citu piekļuves datu nomaiņu no to atsaukšanas. No uzticamas ierīces un pārvaldības vides saskaņoti nomaina skartos hostinga, mākoņpakalpojumu, datubāzes, CI/CD un API piekļuves datus un anulē vecos.

Jāpārbauda arī aktīvās administratoru sesijas un citiem piešķirtās piekļuves, jo paroles maiņa ne visās sistēmās tās automātiski pārtrauc. OWASP sesiju pārvaldības vadlīnijas skaidro, ka sesiju izbeigšana ir atsevišķa darbība. Jaunās paroles un atslēgas nedrīkst nonākt vidē, kur uzbrucējs tās vēl var nolasīt. Nepieciešamo piekļuves atsaukšanu neatliek līdz visas izmeklēšanas beigām. Izmaiņas saskaņo ar cilvēkiem, kuri atbild par savienotajām sistēmām, pārbauda jauno savienojumu un pārliecinās, ka vecā piekļuve vairs nedarbojas.

Pirms mājaslapu atkal padara publiski pieejamu, pārbauda ne tikai sākumlapu, bet arī pieteikuma formas, pieslēgšanos kontiem, pasūtījumus, e-pastus un savienojumus ar uzņēmuma sistēmām. Testus veic tā, lai nejauši neiekasētu īstus maksājumus un nenosūtītu klientiem nevēlamas ziņas. Pēc palaišanas pārbauda kļūdas, procesus un savienojumus, salīdzinot tos ar paredzēto darbību. Arī NIST iesaka pārbaudīt atjaunošanas rezultātu un turpināt novērot sistēmas darbību.

Darba beigās pieraksta atrasto, atjauninātos vai no jauna izveidotos komponentus, atsauktās piekļuves un veiktās pārbaudes. Norāda arī to, kas turpmāk jāuzrauga. Pēc šīm ziņām uzņēmums var lemt, vai sistēmu atsākt lietot. Pārbaude nenovērš visus iespējamos riskus, taču tai jāpamato, kāpēc sistēmu var atkal izmantot.

Kas uzņēmumam jāzina par datu noplūdi un GDPR

Kamēr tehniskā komanda aptur uzbrukumu, uzņēmumam jānoskaidro, vai ir skarti personas dati. Tie var būt klientu kontos, pasūtījumos, pieteikumu formās vai darbinieku dokumentos. Vispārīgā datu aizsardzības regula (GDPR) aptver arī situācijas, kad dati ir dzēsti, neatļauti mainīti vai kāds tiem neatļauti piekļuvis. Tāpēc nepietiek noskaidrot tikai to, vai kāds ir lejupielādējis datubāzi.

Iestādes un skarto cilvēku informēšanai ir atšķirīgi nosacījumi

Pārzinim par personas datu aizsardzības pārkāpumu jāziņo kompetentajai uzraudzības iestādei bez nepamatotas kavēšanās un, ja iespējams, 72 stundu laikā pēc tam, kad tas par pārkāpumu uzzinājis. Izņēmums ir gadījums, kad maz ticams, ka pārkāpums varētu radīt risku cilvēku tiesībām un brīvībām. Ja termiņš pārsniegts, kavējums jāpamato.

Cilvēki, kuru dati ir skarti, jāinformē bez nepamatotas kavēšanās, ja pārkāpums varētu radīt augstu risku. Šo risku vērtē atsevišķi. Regula paredz izņēmumus, ja izpildīti noteikti nosacījumi, piemēram, skartie dati ir efektīvi aizsargāti. Visus personas datu aizsardzības pārkāpumus dokumentē, arī tos, par kuriem nav jāziņo. Ja hostinga vai cits pakalpojuma sniedzējs darbojas kā datu apstrādātājs, tam, uzzinot par pārkāpumu, bez nepamatotas kavēšanās jāinformē pārzinis. Apstrādātājam nav automātiski piešķirtas papildu 72 stundas.

Uzlaušana pati par sevi nenozīmē automātisku naudas sodu. Uzraudzības iestāde vērtē konkrētos apstākļus, pārkāpumu un uzņēmuma rīcību.

Šo kārtību nosaka GDPR 4., 33., 34. un 83. pants.

Kad sāk skaitīt 72 stundas

Neparasta datplūsma ir iemesls tūlītējai pārbaudei. Termiņu sāk skaitīt, kad pārzinim ir pietiekami pamatota pārliecība, ka incidents ir skāris personas datus. Īsa sākotnējā izpēte ir pieļaujama, taču nedrīkst gaidīt pilnu ekspertīzes atzinumu. Ja pārkāpums jau zināms, bet skarto ierakstu skaitu vēl precizē, nepieciešamajā paziņojumā sniedz tobrīd pieejamo informāciju. To vēlāk papildina pa daļām bez turpmākas nepamatotas kavēšanās.

Pierakstiet, kad saņēmāt brīdinājumu, ko pārbaudījāt un kad kļuva skaidrs, ka ir skarti personas dati. Saglabājiet arī lēmuma pamatojumu, ja secināt, ka ziņošana nav vajadzīga.

Šifrēšana vai pseidonimizācija automātiski neatbrīvo no ziņošanas. Jāpārbauda, vai uzbrucējs tiešām nevarēja datus izlasīt, vai viņam nebija pieejamas atslēgas un vai saglabājās iespēja datus izmantot. Arī pseidonimizētus datus var būt iespējams saistīt ar konkrētu cilvēku, izmantojot papildu informāciju. Personas datu nepieejamība var būt pārkāpums arī tad, ja datu pārsūtīšana ārpus sistēmas nav pierādīta.

Šo kārtību skaidro EDPB pamatnostādnes 9/2022, 2. versija.

Trīs situācijas, kurās lēmums var atšķirties

Turpmāk aprakstītās situācijas ir izdomātas, nevis CreateIT klientu gadījumi. Tās parāda, kāpēc lēmumu par ziņošanu nevar pieņemt pēc vienas tehniskas pazīmes.

Neliela uzņēmuma uzskaites sistēmā uzbrucējs piekļuvis tikai droši šifrētiem datiem, un atslēgas nav skartas. Darbība ātri atjaunota no atsevišķas kopijas, cilvēkiem būtiskas sekas nav radušās. Pamatota izpēte var ļaut secināt, ka risks ir maz ticams un paziņojums nav vajadzīgs. Notikušo tomēr dokumentē.

Personāla atlases mājaslapā svešs PHP fails ļāvis piekļūt kandidātu pieteikumiem un dzēst darbību pēdas. Izmeklēšanu nevar pabeigt tikai tāpēc, ka žurnālos nav redzama datu pārsūtīšana ārpus sistēmas. Kandidātu datu apjoms un iespējamā ļaunprātīgā izmantošana var radīt augstu risku un prasīt informēt gan iestādi, gan cilvēkus.

Klīnikas sistēmā šifrējoša ļaunatūra padara pacientu informāciju nepieejamu un kavē aprūpi. Tas var radīt augstu risku arī bez datu zādzības. Ar rezerves kopiju vien nepietiek, ja vajadzīgo informāciju nevar laikus atjaunot.

Piemēru pamatā ir EDPB pamatnostādnēs 01/2021 aplūkotie izspiedējvīrusu un vietņu uzlaušanas gadījumi.

DVI un CERT.LV ir atšķirīgi uzdevumi

Ja kompetentā uzraudzības iestāde ir Datu valsts inspekcija, izmantojiet tās aktuāli norādīto paziņošanas kārtību. Sagatavojiet pārkāpuma aprakstu, skarto datu un personu kategorijas, aptuveno apjomu, kontaktpersonas informāciju, iespējamās sekas un veiktos vai plānotos pasākumus. Ja kāda informācija vēl nav zināma, norādiet, ka to precizējat. Uzņēmumam, kas darbojas vairākās valstīs, atsevišķi jānosaka kompetentā iestāde.

2026. gada 4. novembrī DVI vietnē joprojām bija publicēts paziņojums, ka tiešsaistes forma uz laiku nav pieejama. Iestāde aicina aizpildīt Excel veidlapu, parakstīt to ar drošu elektronisko parakstu un nosūtīt paziņojumā norādītajā veidā. Pirms iesniegšanas pārbaudiet jaunāko kārtību DVI vietnē. Tiešsaistes formas nepieejamība neatceļ ziņošanas pienākumu.

Iesniegšanas kārtība aprakstīta DVI instrukcijā un 26. oktobra paziņojumā par tiešsaistes formas pagaidu nepieejamību.

CERT.LV var sniegt tehnisku atbalstu kiberincidenta risināšanā. Ziņojums CERT.LV neaizstāj nepieciešamo paziņojumu DVI. Noteiktām organizācijām ir arī atsevišķi pienākumi ziņot par kiberdrošības incidentiem. Tos nevar automātiski attiecināt uz katru mājaslapas īpašnieku. CERT.LV paredz arī iespēju ziņot brīvprātīgi un aicina pirms darbības atjaunošanas saglabāt izmeklēšanai vajadzīgos pierādījumus.

Palīdzību un ziņošanas kārtību apraksta CERT.LV rīcības norādes.

CreateIT palīdz noskaidrot, kuras sistēmas un dati ir skarti, saglabāt tehniskos pierādījumus un apkopot paziņojumam vajadzīgos faktus. Juridisko izvērtējumu veic jūsu datu aizsardzības speciālists vai jurists. Šo darbu sāk vienlaikus ar vietnes atjaunošanu, lai lēmumus varētu pieņemt pēc pārbaudītas informācijas.

Kā AI izmanto drošības izpētē un kibernoziedzībā

AI var palīdzēt ātrāk lasīt kodu, meklēt iespējamās kļūdas, sakārtot daudz informācijas un pārbaudīt vairāk variantu. To var izmantot gan drošības speciālists, gan uzbrucējs. Taču aizdomīgs koda fragments vēl nenozīmē, ka ar to izdosies uzbrukt uzņēmuma sistēmai.

Četri jēdzieni, kurus nedrīkst sajaukt

Atradums

Norāde, ka kodā varētu būt problēma. Tā var būt kļūdaina, atkārtot jau zināmu atradumu vai attiekties uz situāciju, kas konkrētajā sistēmā nevar rasties.

Apstiprināta ievainojamība

Pārbaudīts drošības trūkums ar noteiktiem priekšnosacījumiem. Joprojām jāvērtē tā reālā ietekme konkrētajā darbības vidē.

Ievainojamības izmantošanas paņēmiens jeb exploit

Veids, kā ievainojamību izmantot drošības pārkāpuma radīšanai. Laboratorijas demonstrācija vienā versijā vēl nav universāls uzbrukums visām instalācijām.

Reāls incidents

Faktiski notikusi neatļauta piekļuve vai cita drošības problēma. To apstiprina incidenta pierādījumi, nevis tikai pētījuma rezultāts.

Ko rāda pārbaudīti 2026. gada piemēri?

Mozilla 7. maijā ziņoja par 271 ar AI palīdzību identificētu un Firefox 150 izlabotu drošības kļūdu. Starp tām bija 180 augstas, 80 vidējas un 11 zemas smaguma pakāpes kļūdas. Mozilla paskaidroja, ka augsta smaguma pakāpe vēl nenozīmē praktiski īstenojamu uzbrukumu. Pilns uzbrukuma paņēmiens netika izstrādāts katrai kļūdai. Lai pārvarētu aizsardzības slāņus, var būt jāizmanto vairāki trūkumi kopā.

Šis rezultāts apliecina AI vērtību drošības izpētē, bet neliecina par 271 noziedzīgu uzbrukumu vai 271 PHP ievainojamību.

Mozilla tehniskais skaidrojums par Firefox drošības uzlabošanu, 07.05.2026.

Mandiant 18. augustā aprakstīja vairāk nekā 100 kritiskas ievainojamības, kas apstiprinātas divu dienu analīzē. Tas notika izmeklēšanā, kas bija saistīta ar uzņēmuma koda repozitoriju zādzību. Komanda izmantoja specializētu sistēmu un ekspertu pārbaudi. Šo rezultātu nevar uzskatīt par vidējo rādītāju jebkurai mājaslapai. Komanda apraksta hipotēžu pārbaudi, atkārtotu atradumu atpazīšanu un kļūdainu rezultātu noraidīšanu.

Google/Mandiant par AI atbalstītu koda pārskatīšanu, 18.08.2026.

Anthropic 27. oktobrī publicēja pētījumu, kurā demonstrētas piecas uzbrukuma ķēdes. Tajā izmantots nepubliskots iekšējs pētniecības modelis. Izpēte veikta kontrolēti, ievērojot saskaņotu ievainojamību atklāšanu. Piemērs rāda spēju ne tikai atrast kļūdas, bet arī izstrādāt uzbrukumu. Tas nepierāda, ka modelis ir publiski pieejams vai izmantots konkrētā noziedzīgā kampaņā.

Anthropic ievainojamību izpētes publikācija, 27.10.2026.

Kā AI var pārbaudīt tik daudz koda?

Lielu projektu var sadalīt vairākos izpētes uzdevumos. Vienā analizē datu apstrādi, citā piekļuves tiesības, vēl citā savienojumus starp programmas daļām. AI palīdz izsekot loģikai un meklēt situācijas, kurās paredzētie ierobežojumi varētu nedarboties. Strādājot paralēli, var pārbaudīt vairāk variantu.

Pēc tam speciālistam jāpārbauda, vai atrastā situācija sistēmā vispār var rasties, vai tā jau nav zināma, kādas tiesības vajadzīgas un ko uzbrucējs varētu izdarīt. Jāpārskata un jātestē arī labojums. Virsraksts par “simtiem kļūdu” šo darbu bieži neparāda. Iepriekš minētie pētījumi neļauj solīt, ka ar vienu pieprasījumu AI rīkam jebkurā vietnē varēs atrast simtiem izmantojamu kļūdu.

Noziedzniekiem ne vienmēr vajag jaunu ievainojamību

Google Threat Intelligence 8. septembra ziņojumā aprakstīta 2026. gada otrajā ceturksnī novērota kampaņa, kuras iespējamais motīvs bija finansiāls ieguvums. Pēc mākoņvides kompromitēšanas uzbrucējs mazāk nekā sešās stundās ar AI aģentu palīdzību sagatavoja un īstenoja plašu piekļuves datu iegūšanas kampaņu. Ziņojumā minēti tūkstošiem kompromitētu trešo pušu piekļuves datu.

Šie skaitļi nenozīmē tūkstošiem jaunu ievainojamību vai uzlauztu uzņēmumu. Piemērs parāda, kā AI paātrina pazīstamus noziedzīgas kampaņas uzdevumus, palīdzot to sagatavot, pielāgot rīkus un novērst problēmas darbības laikā.

Google GTIG/Mandiant par AI ļaunprātīgu izmantošanu, 08.09.2026. Tā ir pakalpojuma sniedzēja novērotā situācija, nevis visu uzbrukumu statistika.

Nozagta parole, aizmirsts testa serveris vai mēnešiem neatjaunināts modulis var pavērt ceļu uzbrukumam. AI var palīdzēt uzbrucējam rīkoties ātrāk, taču piekļuves kontrole, atjauninājumi un pārbaudītas rezerves kopijas joprojām ir svarīgas. Arī Microsoft 2026. gada pārskats uzsver identitāšu, uzticamu piekļuves ceļu un cilvēku lomu.

Microsoft Digital Defense Report 2026 kopsavilkums, 01.10.2026.

AI iesaisti konkrētā PHP uzbrukumā nevar secināt tikai pēc tā ātruma vai pieprasījumu skaita. Tam vajadzīgi atsevišķi pierādījumi. Arī aizsardzībā AI rīka atbilde ir jāpārbauda, pirms to izmanto incidenta gala slēdzienā.

Kam sagatavoties nākamajos mēnešos?

Programmatūras atbalsta beigu datumus var pārbaudīt, bet nākotnes uzbrukumus precīzi paredzēt nevar. Tālāk aprakstītais ir mūsu vērtējums par 2026. gada novembri un 2027. gada sākumu, balstoties iepriekš minētajos novērojumos. Tie ir iespējami scenāriji. Konkrētā uzņēmuma risks jāvērtē atsevišķi.

PHP 8.2 drošības atbalstam ir zināms beigu datums

PHP projekta tabulā norādīts, ka PHP 8.2 drošības atbalsts beidzas 2026. gada 31. decembrī. Šī brīža kritiskais labojums un pāreja uz ilgāk atbalstītu versiju zaru ir divi atsevišķi darbi. Labojumu nevajag atlikt, gaidot šo pāreju. Tai jau tagad jāplāno saderības pārbaude un ieviešanas laiks.

Ja hostinga pakalpojuma sniedzējs piedāvā pagarinātu vecas versijas uzturēšanu, noskaidrojiet tās apjomu un termiņu. Ārkārtas labojums vienai kļūdai vēl nenozīmē pilnu turpmāku atbalstu. Ikdienā izmantotās sistēmas pāreju plānojiet uz atbalstītu stabilu versiju.

PHP oficiālā atbalstīto versiju tabula, atkārtoti pārbaudīta 04.11.2026.

Laiks starp paziņojumu un uzbrukuma mēģinājumiem var kļūt īsāks

Oktobra PHP gadījumā uzbrukuma mēģinājumi sākās vēl pirms publiskā paziņojuma. Ar AI palīdzību veikta analīze var paātrināt darbu arī pēc labojuma publicēšanas. Tāpēc uzņēmumam iepriekš jānosaka, kurš reaģēs uz steidzamu brīdinājumu un kā uzstādīs ārkārtas atjauninājumu. Ar plānotu pārbaudi reizi ceturksnī šādam gadījumam nepietiek.

Viltus ziņas var kļūt pārliecinošākas

Hostinga, bankas vai piegādātāja vārdā rakstīta ziņa var būt gramatiski laba un precīzi pieskaņota uzņēmuma darbībai. Valodas kvalitāte vairs nav drošs uzticamības tests. Maksājumu rekvizītu maiņu un piekļuves pieprasījumus pārbaudiet pa iepriekš zināmu kanālu. Īpaši tad, ja ziņa steidzina un prasa apiet parasto kārtību.

Vairāk atradumu prasīs rūpīgāku pārbaudi un prioritāšu izvēli

Jo vairāk iespējamu kļūdu rīki atrod, jo svarīgāk pārbaudīt, kuras tiešām attiecas uz uzņēmuma sistēmu. Jānoskaidro ietekme un jāpārbauda labojums. Simts neizvērtētu brīdinājumu maz palīdz, ja nevienam nav uzdots tos pārbaudīt un nav noteikts termiņš.

Izmantoto sistēmu sarakstā jāiekļauj arī uzņēmuma AI čatboti un aģenti. Kādiem datiem tie piekļūst? Vai drīkst mainīt ierakstus, nosūtīt e-pastus vai izmantot maksas API? Kurš apstiprina nozīmīgas darbības? Konta kompromitēšanas sekas nosaka arī tam piešķirtās tiesības un savienojumi.

30 dienu plāns, lai nākamais brīdinājums nepārsteigtu nesagatavotus

Šo plānu var izmantot, kamēr sistēma darbojas stabili. Aktīva incidenta risināšanu, kritisku labojumu vai obligātu ziņošanu nedrīkst atlikt līdz plānā norādītajai nedēļai.

Pēc šo darbu pabeigšanas uzņēmumam jābūt sistēmu sarakstam, atbildīgajiem, atjaunošanas pārbaudes pierakstam un turpmāko darbu prioritātēm. Drošības spraudņa iegāde vien to nenodrošina.

Jautājumi, kurus uzņēmumi uzdod visbiežāk

Mājaslapa izskatās normāli. Vai tā tik un tā var būt uzlauzta?

Jā. Fonā var notikt neatļauta e-pastu sūtīšana, datu lasīšana vai administratora konta izveide. Ļaunprātīgs kods var tikt rādīts tikai daļai apmeklētāju. Sākumlapas izskata pārbaude vien neļauj novērtēt sistēmas drošību.

Hostings saka, ka PHP ir atjaunināts. Ko vēl prasīt?

Noskaidrojiet, kurām vietnēm un izpildvidēm uzstādīts labojums, kāds ir pilns pakotnes numurs un kā pārbaudīti strādājošie procesi. Atsevišķi jautājiet, vai meklētas uzlaušanas pazīmes. Apstiprinājums par atjauninājumu vēl nav incidenta izmeklēšanas rezultāts.

Vai pietiek nomainīt visas paroles?

Paroļu maiņa var būt vajadzīga, bet jānovērš arī uzbrucēja piekļuves ceļš. Jāpārbauda esošās sesijas, API piekļuves marķieri, SSH atslēgas un citi mehānismi. Ja saglabājas ļaunatūra vai kompromitēta pārvaldības vide, arī jaunie piekļuves dati var nonākt pie uzbrucēja.

Vai drošības skeneris var pateikt, ka viss ir tīrs?

Skenera iespējas nosaka tā metodes un piešķirtās piekļuves. Tas ir viens no informācijas avotiem. Rezultāts jāvērtē kopā ar failiem, kontiem, žurnāliem, konfigurāciju un incidenta notikumu secību.

Vai katrs uzbrukuma mēģinājums jāziņo DVI?

Nē. Svarīgi ir personas datu pārkāpuma fakti un risks cilvēku tiesībām un brīvībām. Taču aizdomas ir jāizpēta savlaicīgi, un apstiprinātam pārkāpumam jāpiemēro iepriekš aprakstītā ziņošanas un dokumentēšanas kārtība.

Cik maksā un cik ilgi notiek atjaunošana?

To nosaka skarto sistēmu apjoms, piekļuves, rezerves kopiju kvalitāte, pieejamie pierādījumi un tas, vai jāatjauno arī saistīti pakalpojumi. Pirmajā sarunā vienojas par tuvākajiem darbiem un noskaidro, kas vēl jāpārbauda. Precīzu termiņu bez šīs informācijas apsolīt nebūtu godīgi.

Vai labāk uzreiz pasūtīt jaunu mājaslapu?

Vispirms jāaptur kaitējums un jānoskaidro, kas ir skarts. Jauna mājaslapa pati par sevi neatrisina uzbrucēja pārņemtu hostinga kontu, apdraudētu pastkasti vai kopējās infrastruktūras problēmu. Tikai pēc šīs pārbaudes var izvēlēties, vai vietni atjaunot, tehniski uzlabot vai pārbūvēt.

CreateIT, atjaunošana pēc uzbrukuma

Atjaunojam to, ko lieto jūsu klienti

Vispirms apturam kaitējumu un aizveram ceļu, pa kuru uzbrucējs iekļuva, pēc tam pārbaudām un atjaunojam nepieciešamo darbību. Pārbaudām failus, datubāzi un kontus, saglabājam izmeklēšanai vajadzīgo informāciju un izvērtējam atjaunošanu no tīras kopijas vai tīrā vidē.

Pārbaudām, vai atjaunotā mājaslapa spēj pieņemt pieteikumu, noformēt pasūtījumu, apstrādāt maksājumu un nodot informāciju vajadzīgajai sistēmai. Strādājam ar WordPress, Drupal, Laravel un individuāli veidotiem risinājumiem, tostarp citu izstrādātāju projektiem.

Palīdzam noskaidrot, kuri dati un sistēmas bija apdraudēti, un sagatavot tehnisko informāciju paziņojumam. Juridisko izvērtējumu veic jūsu datu aizsardzības speciālists vai jurists. Darba sākumu un tuvākos soļus saskaņojam pirmajā sarunā.

Pirmajai sarunai sagatavojiet domēnu, novērotās pazīmes, to pamanīšanas laiku un hostinga pakalpojuma sniedzēja nosaukumu. Paroles, slepenās atslēgas un klientu datubāzi sākotnējā pieteikumā nesūtiet. Piekļuves nodošanas kārtību saskaņosim atsevišķi.

Atjaunošana pēc uzbrukuma, drošības atjauninājumi, mājaslapu uzturēšana, kiberdrošība.