Kibertəhlükəsizlikdə qara oktyabr 2026: sayt sahibi nəyi yoxlamalıdır

«Qara oktyabr»da nə baş verdi

Aşağıda sayt sahibinin nəzərdən keçirməsi faydalı olan dörd təsdiqlənmiş hadisə təqdim edilir. Bu, oktyabr insidentlərinin tam siyahısı deyil.

PHP2Shell: CMS yeniləməsi niyə kifayət etmir

Oktyabrın 21-də PHP tərtibatçıları CVE-2026-109618 və CVE-2026-109619 üçün düzəlişlər buraxdılar. Bu boşluqlar autentifikasiya olmadan uzaqdan kod icrasına imkan verə bilər. Rəsmi xəbərdarlıq veb-sorğuları emal edən PHP quraşdırmalarını, o cümlədən PHP-FPM və mod_php ilə Apache-ni əhatə edir.

Düzəlişlər PHP 8.5.12, 8.4.27, 8.3.36 və 8.2.35 versiyalarına daxil edilib. Linux paketlərində düzəliş başqa nömrəli paketə köçürülə bilər: paket təchizatçısının bildirişini yoxlamaq lazımdır. Windows üçün oktyabrın 26-da Brotli düzəlişini də ehtiva edən -1şəkilçili yenidən yığılmış paketlər təqdim edilib. PHP-nin 23 oktyabr tarixli əlavə bildirişi sessiyaların emalı parametrlərinin xüsusi kombinasiyasına aiddir: icraçı konfiqurasiyanı yoxlayarkən bunu da nəzərə almalıdır. PHP-nin oktyabr üzrə rəsmi bildirişləri.

Sayt WordPress, 1C-Bitrix və ya başqa PHP sistemi üzərində işləyirsə, onun modullarının yenilənməsi serverdəki PHP-nin yenilənməsini əvəz etmir. Hostinqdən və ya administratordan məhz sayt üçün düzəldilmiş paketi təsdiqləməsini istəyin. Əmr sətrindəki PHP versiyası ziyarətçilərə xidmət edən versiyadan fərqlənə bilər.

Brotli: daxil olan məlumatların emalını yoxlamaq lazımdır

Brotli məlumatların sıxılması texnologiyasıdır. Oktyabrda tərtibatçılar dekoder üçün CVE-2026-111497 düzəlişlərini yayımladılar: 1.0.10, 1.1.1 və 1.2.1 buraxılışlarında uzaqdan kod icrasına imkan verən xətanın aradan qaldırıldığı göstərilir. Google Brotli buraxılışları.

Riski qiymətləndirmək üçün tətbiqin etibarsız mənbədən gələn sıxılmış məlumatları həssas komponent vasitəsilə emal edib-etmədiyini müəyyənləşdirmək lazımdır. Saytda səhifələrin sıxılmasının olması bu suala öz-özlüyündə cavab vermir. Kitabxana sayt sahibinin xəbəri olmayan icra mühitinin, HTTP müştərisinin və ya konteyner obrazının daxilində yerləşə bilər.

İdarə olunan hostinq də yoxlama tələb edir. Məsələn, AWS Lambda xidmətinin və onun icra mühitlərinin vəziyyətini ayrıca təsvir edir, yenilənmiş baza obrazları üçün isə yenidən yığma və yerləşdirmə tövsiyə edir. Provayderin yeniləməsi əvvəldən yığılmış konteynerinizin artıq düzəliş aldığı demək deyil. AWS-nin Brotli üzrə təhlükəsizlik bülleteni.

Railway: sayt açılırsa da açarları niyə dəyişmək lazımdır

Railway ilkin hesabatında daxili sistemlərə giriş və müştərilərin bir hissəsinin məxfi məlumatlarının açıqlanması barədə məlumat verib. Şirkət oktyabrın 21-dən əvvəl qeydiyyatdan keçmiş müştərilərə platformada saxladıqları açarları dəyişməyi tövsiyə edib. Hesabata əsasən, işləyən tətbiqlər əlçatan qalıb; insidentə reaksiya zamanı yığma və yerləşdirmə prosesləri dayandırılıb. Railway-in ilkin hesabatı.

Sayt sahibi üçün bu, mühit dəyişənlərinin yoxlanması deməkdir: orada verilənlər bazası parolları, poçt girişləri, ödəniş və süni intellekt xidmətlərinin açarları saxlanıla bilər. Paneldə dəyəri dəyişmək kifayət etmir. Köhnə açarı təchizatçıda ləğv etmək, yenisini tətbiqə qoşmaq və sonra inteqrasiyanın işini yoxlamaq lazımdır.

LiteLLM: təhlükə rəsmi yeniləmə ilə də gələ bilər

Oktyabrın 21-də LiteLLM-in buraxılış infrastrukturu vasitəsilə komprometasiya edilmiş 1.107.0versiyası yayımlanıb. Səbəblərin təhlilində tərtibatçılar hücumu əvvəllər açıq repozitoriyaya düşmüş və fayl silindikdən sonra ləğv edilməmiş inzibati açarla əlaqələndiriblər. Hücumçu onun vasitəsilə hazırlama infrastrukturuna əlavə giriş əldə edib. LiteLLM hücum zəncirinin təhlili.

Təkcə cari asılılıqlar siyahısını yoxlamaq kifayət deyil. Quraşdırma və yığma tarixçəsinə baxın: təhlükəli versiya müvəqqəti, o cümlədən avtomatik yığma sistemində işlədilmiş ola bilər. İstifadə edilibsə, təmizləmə və məxfi məlumatların dəyişdirilməsi qaydasını LiteLLM-in təsirlənmiş buraxılış barədə bildirişi.

Saytınızın təsirlənib-təsirlənmədiyini necə müəyyən etmək olar

İcraçıya yoxlama siyahısını göndərin və hər bənd üzrə nəticə istəyin. «Bizdə hər şey yenilənib» cavabı məhz nəyin yoxlandığını qiymətləndirməyə imkan vermir.

Belə hesabata məxfi dəyərləri daxil etmək lazım deyil. Xidmətin adı, açarın təyinatı, dəyişmə tarixi və köhnə girişin ləğvinin təsdiqi kifayətdir.

Fəaliyyət planı: yoxlamadan nəticənin təsdiqinə qədər

1. Məsul şəxsi təyin edin və araşdırma üçün məlumatları qoruyun

İşi kimin əlaqələndirdiyini müəyyən edin: administrator, tərtibatçı və ya insidentlərə reaksiya mütəxəssisi. Problemin aşkarlandığı vaxtı və komponentlərin cari versiyalarını qeyd edin.

Hücum əlamətləri varsa, təmizləmədən əvvəl mövcud jurnalları və sistem surətlərini məhdud girişlə saxlayın. Prioritet zərəri dayandırmaq və mümkün qədər hücum yolunu anlamağa kömək edən məlumatları qorumaqdır. Faylların üzərinə yazılması və jurnalların silinməsi araşdırmanı çətinləşdirə bilər.

2. Təsdiqlənmiş boşluğu aradan qaldırın

İcraçı mühitinizə uyğun düzəldilmiş paketi seçməli, uyğunluğu yoxlamalı və yeniləməni tətbiq etməlidir. Bundan sonra işləyən proseslərin və konteynerlərin həqiqətən yeni paketdən istifadə etdiyinə əmin olmaq lazımdır.

İdarəetmə panelinə girişi, sifarişi, formaları, ödənişi, müraciətlərin CRM-ə ötürülməsini və fon tapşırıqlarını yoxlayın. Ana səhifənin uğurla açılması bu ssenarilərin yoxlanmasını əvəz etmir. Uyğunsuzluq yaranarsa, işi təhlükəsiz bərpa etmək yolu lazımdır: məlum həssas paketə qayıdışı tamamlanmış düzəliş saymaq olmaz.

3. Açıqlanmış girişləri ləğv edin

Təsirlənmiş sistemin çata bildiyi məxfi məlumatların siyahısını tərtib edin: verilənlər bazası, poçt, bulud, repozitoriya, ödəniş provayderi, CRM, süni intellekt xidmətləri. Dəyişməni etibarlı cihazdan və təmizlənmiş mühitdə edin. Hələ yoluxmuş serverə daxil edilən yeni məxfi məlumat təkrar sıza bilər.

Dəyişmədən sonra iki məqamı təsdiqləyin: tətbiq yeni məlumatlarla işləyir və köhnə giriş artıq etibarlı deyil. Açar və parolları yazışmada və ya hesabatda paylaşmayın.

4. Hücumçunun giriş saxlayıb-saxlamadığını yoxlayın

Yeniləmə boşluğu bağlayır, lakin ondan əvvəl istifadə edilmədiyini sübut etmir. Naməlum inzibati hesabları, fayl dəyişikliklərini, şübhəli planlı tapşırıqları, yeni giriş açarlarını, kənar prosesləri və qeyri-adi çıxış bağlantılarını yoxlayın.

Saytda gizli keçidləri, ödəniş rekvizitlərinin dəyişdirilməsini, ziyarətçi yönləndirmələrini və kənar səhifələri də yoxlayın. Hər tapıntını qanuni dəyişikliklərlə tutuşdurmaq lazımdır: qeyri-adi fayl öz-özlüyündə hücumu sübut etmir.

5. Yoxlamanın sərhədlərini qeyd edin

Hesabatda yoxlanmış sistemləri, jurnalların dövrünü, tətbiq edilmiş düzəlişləri və açıq qalan sualları göstərin. «Göstərilən dövr üzrə mövcud məlumatlarda komprometasiya əlaməti aşkarlanmadı» ifadəsi qeyd-şərtsiz «sayt sındırılmayıb» ifadəsindən daha dəqiqdir.

Sayt artıq sındırılıbsa nə etməli

Naməlum administratorlar, zərərli fayllar və ya məzmunun dəyişdirilməsi aşkarlandıqda insident qaydasında hərəkət edin. Təhlükəli girişi məhdudlaşdırın, sübutları qoruyun, miqyası müəyyənləşdirin və sistemi etibarlı vəziyyətdən bərpa edin. Səbəb aradan qaldırıldıqdan sonra təsirlənmiş məxfi məlumatları dəyişin və müşahidəni gücləndirin.

Dünənki nüsxənin bərpası təmizlənməyə zəmanət vermir: hücum daha əvvəl baş vermiş ola bilər. Əvvəl seçilən ehtiyat nüsxəyə və onun bərpa ediləcəyi mühitə etibarın mümkünlüyünü qiymətləndirmək lazımdır.

Yoluxma əlamətləri olduqda ayrıca saytın viruslardan təmizlənməsitapşırığı faydalıdır, səbəblərin və giriş sərhədlərinin yoxlanmasını isə saytın təhlükəsizlik auditinə.

Növbəti insidentin nəticələrini necə azaltmaq olar

Təhlükəsizliyi müşahidə edilə bilən nəticələrlə yoxlayın. Komponentlər üçün yeniləmələrə və tərtibatçı bildirişlərinə abunəliyə cavabdeh şəxslər təyin edin. Məxfi məlumatlar üçün hüquqları məhdudlaşdırın, hazırlama və işlək sistemin girişlərini ayırın. Ehtiyat nüsxələri ayrıca mühitdə bərpa etməklə yoxlayın. Jurnallar üçün saxlanma müddətini və məsul şəxsin reaksiya verməli olduğu hadisələri müəyyənləşdirin.

Saytın asılılıqlar xəritəsini əvvəlcədən hazırlayın: hostinq, server mühiti, CMS, paketlər, konteynerlər, xarici inteqrasiyalar və açar təchizatçıları. Növbəti xəbərdarlıq zamanı o, əsas suala tez cavab verməyə kömək edəcək: «Bu bizdə istifadə olunurmu və harada?»

Belə xəritənin yoxlanmasına saytın təhlükəsizliyitapşırığından başlamaq olar: komponentləri müəyyənləşdirmək, düzəlişləri təsdiqləmək və reaksiya qaydasını razılaşdırmaq. Praktik nəticə yoxlanmış sistemlərin, aradan qaldırılmış problemlərin və məsul şəxsi ilə müddəti müəyyən edilmiş tədbirlərin siyahısıdır.