Apache HTTP/2 zəifliyi CVE-2026-119618: 2.4.71-ə yeniləyin

CVE-2026-119618 nədir?

CVE-2026-119618 Apache HTTP Server-də HTTP/2 trafikini emal edən mod_http2 modulundakı kritik zəiflikdir; heap-in korlanmasına və uzaqdan kod icrasına gətirib çıxara bilər ^[1].

Apache onu “Apache HTTP Server-in mod_http2 modulunda assign_headers() funksiyasında ortaq resursdan düzgün olmayan sinxronizasiya ilə eyni vaxtda istifadə zəifliyi” kimi təsvir edir və “RCE-yə gətirib çıxara bilər” deyir ^[1]. Lüksemburqun milli kompüter fövqəladə hallar reaksiya qrupu CIRCL izah edir ki, HTTP/2 axınlarının paralel emalı zamanı işçi proses başqa icra konteksti üçün ayrılmış başlıq cədvəlini dəyişə bilər və ortaq yaddaşa bu təhlükəli giriş heap-i korlaya bilər ^[2].

Uğurlu hücumçu giriş etmədən Apache veb server prosesinin imtiyazları ilə kod işlədə bilər ^[2][4]. BleepingComputer-ə görə, Apache HTTP Server təxminən hər beş veb saytdan birində işləyir ^[4].

Upstream düzəliş modules/http2/h2_request.c faylındakı bir yazını ortaq sorğu başlıq cədvəlindən cari sorğunun öz giriş başlıqlarına dəyişir ^[2].

Hansı Apache versiyaları təsirlənir?

Apache HTTP Server 2.4.55-dən 2.4.70-ə qədər, həmçinin GitHub-dakı müstəqil mod_h2 2.0.8-dən 2.0.42-yə qədər buraxılışlar təsirlənir; 2.4.71 versiyası bunu düzəldir ^[1].

Distributiv paketləri versiya yoxlamasını çətinləşdirir. CIRCL distribütorların saxladığı paketlərdən istifadə edən təşkilatlara yalnız upstream versiya nömrəsinə arxalanmaq əvəzinə təhlükəsizlik backport-unu yoxlamağı məsləhət görür ^[2]. CIRCL-in xülasəsinə görə, Red Hat öz RHEL 9 və 10 paketlərini Kritik yox, Vacib kimi qiymətləndirir, çünki onların yaddaş ayırıcısı istismarı çətinləşdirir, RHEL 8 və əvvəlkilərin isə təsirlənmədiyini bildirir ^[2].

Red Hat ümumi CVSS v3.1 balını 9,8 (Kritik) verir ^[2][3]. Apache-nin öz qiymətləndirməsi Kritikdir ^[1].

Apache serverim zəifdirmi?

Yalnız təsirlənmiş build işlədirsə və həqiqətən HTTP/2 bağlantıları qəbul edirsə: Red Hat bildirir ki, yalnız HTTP/1.1 təqdim etmək üçün konfiqurasiya olunmuş serverlər zəif deyil ^[3]. CIRCL vurğulayır ki, mod_http2 sadəcə quraşdırıldığı və ya yükləndiyi üçün kod yoluna çatmaq mümkün olmur ^[2].

• HTTP/2-ni Protocols direktivi idarə edir: “h2” onu TLS üzərindən, “h2c” isə açıq mətn üzərindən aktiv edir ^[2].
• Apache-nin əsas defoltu http/1.1-dir və mod_http2-nin yüklənməsi bunu özü dəyişmir ^[2]. BleepingComputer qeyd edir ki, HTTP/2 defolt olaraq söndürülüb ^[4].
• Virtual host öz Protocols direktivini təyin edə bilər, ona görə yalnız qlobal konfiqurasiyanı yoxlamaq HTTP/2 aktiv saytı gözdən qaçıra bilər ^[2].
• Əgər reverse proxy, yük balanslaşdırıcı və ya CDN HTTP/2-ni sonlandırıb Apache-yə yalnız HTTP/1.1 ötürürsə, müştərinin HTTP/2 sessiyası özü-özlüyündə Apache-ni əlçatan etmir, lakin hər addımda protokolu yoxlamalısınız ^[2].

CIRCL versiyaya və yüklənmiş modullara (apachectl -v, apachectl -M), konfiqurasiya olunmuş virtual hostlara (apachectl -S) və hər açıq Protocols parametrinə baxmağı təklif edir ^[2]. Son nöqtənin HTTP/2 qəbul etdiyini göstərən test onun backend-inin zəif olduğunu sübut etmir, mənfi test isə hər portun və ya virtual hostun HTTP/2-ni rədd etdiyini sübut etmir ^[2].

Serverimin HTTP/2 qəbul edib-etmədiyini necə yoxlayım?

CIRCL iki yoxlama təklif edir: əvvəlcə serverin özündə Apache konfiqurasiyasına baxın, sonra razılaşdırılmış protokolu şəbəkədən, ideal olaraq proxy vasitəsilə yox, birbaşa Apache-yə qoşularaq test edin ^[2].

1. Versiyanı və modulları yoxlayın. Versiyanı görmək üçün apachectl -v, modulun yüklənib-yüklənmədiyini görmək üçün isə http2 üçün süzülmüş apachectl -M işlədin ^[2].
2. Virtual hostları siyahıya alın. apachectl -S konfiqurasiya olunmuş bütün virtual hostları göstərir; bu vacibdir, çünki hər biri öz Protocols sətrini daşıya bilər ^[2].
3. Hər Protocols direktivini tapın. CIRCL /etc/apache2 və /etc/httpd qovluqlarında virtual host override-ları da daxil olmaqla açıq Protocols parametrlərini axtaran grep əmri verir; yollar distributivdən asılı olaraq fərqlənir ^[2].
4. TLS üzərindən test edin. HTTP versiyasını çap edən --http2 seçimi ilə curl sorğusu HTTPS son nöqtəsinin HTTP/2 razılaşdırıb-razılaşdırmadığını göstərir ^[2].
5. Açıq mətni test edin. --http2-prior-knowledge ilə curl adi HTTP son nöqtəsinin h2c qəbul edib-etmədiyini yoxlayır ^[2].

Nəticələri diqqətlə oxuyun. HTTP/2 bildirən cavab test olunan son nöqtənin HTTP/2 qəbul etdiyini göstərir, lakin onun Apache backend-inin zəif olduğunu təsdiqləmir; mənfi nəticə hər ünvanın, portun və ya virtual hostun onu rədd etdiyini sübut etmir ^[2]. CIRCL-in məsləhəti effektiv Apache konfiqurasiyasını və təchizatçının yamaqlı paket statusunu birlikdə təsdiqləməkdir ^[2]. Bulud mühitlərində Wiz xəbərdarlıq edir ki, pozulmuş Apache instansı yaxındakı mikroservislərə və ya bulud metadata son nöqtələrinə yanal hərəkət üçün giriş nöqtəsinə çevrilə bilər; bu, yalnız ictimai veb saytı yox, hər instansı yoxlamağın başqa bir səbəbidir ^[5].

CVE-2026-119618-i necə düzəltmək olar?

Apache HTTP Server 2.4.71 və ya daha yeni versiyaya yeniləyin və ya distributivinizin yamaqlı paketini quraşdırın, sonra Apache-ni yenidən başladın və işləyən proseslərin yeni build-dən istifadə etdiyini təsdiqləyin ^[2][1].

1. Apache-ni yeniləyin. 2.4.71 və ya CVE-2026-119618 üçün açıq şəkildə yamaqlanmış təchizatçı build-ini quraşdırın ^[2].
2. Müstəqil mod_h2-ni yeniləyin, əgər istifadə edirsinizsə, onun təchizatçısının göstərişinə uyğun; Wiz 2.0.42-dən yuxarı keçməyi deyir, CIRCL isə yoxlamadan daha yeni müstəqil buraxılışın mövcud olduğunu güman etməməyi xəbərdar edir ^[5][2].
3. Yenidən başladın və yoxlayın ki, işləyən proseslər düzəldilmiş build-dən istifadə edir ^[2].
4. Hələ yamaq edə bilmirsinizsə, HTTP/2-ni söndürün: Protocols-u http/1.1 təyin edin, h2 və h2c-ni override edən hər virtual hostdan silin, apachectl -t ilə test edin və yenidən yükləyin ^[2]. Bu, zəifliyin yolunu bağlayır, lakin kodu düzəltmir ^[2].
5. Girişi məhdudlaşdırın - yamaq və ya protokol dəyişikliyi mümkün olmadıqda müvəqqəti tədbir kimi etibarlı şəbəkələrlə ^[2].

BleepingComputer yazır ki, watchTowr tədqiqatçıları bunu “indi yamaq edin və ya bacarana qədər h2-ni atın” kimi ümumiləşdirib ^[4]. SecurityWeek yazır ki, Defiant da xəbərdarlıq edib: WordPress təhlükəsizlik yeniləmələri problemi həll edə bilməz, çünki o, əsas veb serverə təsir edir ^[3].

CVE-2026-119618 istismar olunurmu?

Wiz-in 2026-cı il noyabrın 11-dəki yazısına olan vəziyyətə görə, heç bir exploit mövcud deyildi və real hücumlarda istismar barədə məlumat yox idi ^[5]. Lakin vəziyyət sürətlə dəyişir.

• Red Hat bildirir ki, açıq tədqiqat mod_http2 aktiv olan serverə qarşı etibarlı exploit nümayiş etdirib, lakin onun bildirişi tədqiqatı göstərmir ^[3]. CIRCL qeyd edir ki, bu, özü-özlüyündə real hücumlarda istismarı sübut etmir ^[2].
• GitHub-dakı açıq proof of concept yaddaş korlanmasını və Apache çökmələrini təkrarladığını bildirir, lakin uzaqdan kod icrasını nümayiş etdirmir ^[3].
• Wiz məlumatları göstərir ki, bulud mühitlərinin 64%-i təsirlənmiş versiyaları işlədən resurslar ehtiva edir və 51%-də ictimai şəkildə açıq instanslar var; Wiz qeyd edir ki, bu, konfiqurasiyanı nəzərə almır, ona görə bunlar mütləq istismar oluna bilən sistemlər deyil ^[5][3].

CIRCL araşdırılmağa dəyər əlamətləri sadalayır: gözlənilməz işçi çökmələri, anormal yenidən başlamalar, şübhəli uşaq prosesləri, icazəsiz fayl dəyişiklikləri və gözlənilməz çıxan bağlantılar ^[2]. Bunlar ipucudur, təsdiqlənmiş kompromis göstəriciləri deyil, yamaq isə yenilənmədən əvvəl qurulmuş davamlılığı aradan qaldırmır ^[2].

Apache HTTP/2 zəifliyini kim tapıb?

Apache zəifliyi 26 oktyabr 2026-da bildirmiş Anthropic-in OSS Scanner-ini və onu noyabrın 3-də müstəqil olaraq bildirmiş Google Cloud Vulnerability Research-dən Anthony Weems və Simon Scannell-i qeyd edir ^[1].

Anthropic-in tapıntısı ANT-2026-MAPKT6MZ daxili identifikatoru altında siyahıya alınıb ^[1]. SecurityWeek iki hesabatı müstəqil kəşflər kimi təsvir edir ^[3]. Bu, avtomatlaşdırılmış və AI dəstəkli alətlərin geniş istifadə olunan açıq mənbəli proqram təminatında ciddi xətalar tapmasının daha bir nümunəsidir; bu tendensiyanın nə demək olduğuna Təhlükəsizlik xətalarını tapan AI: Glasswing və yeni CVE-lər sizin üçün nə deməkdir məqaləsi baxır.

Düzəliş commit edilib və 2.4.71 noyabrın 11-də buraxılıb, yəni Apache problemi oss-security poçt siyahısında açıqladığı gün ^[1][2].

Apache 2.4.71 daha nələri düzəldir?

Apache HTTP Server 2.4.71 cəmi üç CVE-ni düzəldir: biri kritik, biri vacib və biri aşağı ^[1].

• CVE-2026-106023 (vacib): sorğu emalı zamanı mod_md-də child prosesi çökdürə bilən NULL pointer dereference; 2.4.30-dan 2.4.70-ə qədər təsir edir ^[1].
• CVE-2026-109163 (aşağı): mod_vhost_alias-da bir baytlıq stack bufer üzərinə yazma; Apache onu “CVE-2026-63292-dən sonra” adlandırır (həmin əvvəlki zəiflik 2.4.69-da düzəldilib); 2.4.69 və 2.4.70-ə təsir edir ^[1].

Əvvəlki buraxılış, 2026-cı ilin oktyabrındakı 2.4.69, 20 CVE-ni düzəldib ^[1]. Onu atlayan administratorlar 2.4.71-ə keçməklə həmin düzəlişləri də alırlar. Digər son server zəifliyi üçün CVE-2026-98432 izah olunur: Linux TCP zəifliyi və serverlərinizi necə qorumaq olar məqaləsinə baxın.

Administratorlar bundan sonra nəyi izləməlidir?

Açıq uzaqdan kod icrası exploit-ini, distributivinizə uyğun təchizatçı backport-larını və real hücumlar barədə hər hansı məlumatı izləyin ^[3][5].

CIRCL HTTP/2 aktiv instansları siyahıya almağı, hər mod_http2 build-inin təsirlənib-təsirlənmədiyini yoxlamağı və açıq sistemləri gecikdirmədən yamaqlamağı tövsiyə edir; prioritet internetə açıq veb saytlar, API-lər, paylaşılan hostinq və HTTP/2 ötürən frontend-lərin arxasındakı Apache serverləridir ^[2]. Şübhəli fəaliyyət görən təşkilatlar insidentə reaksiya prosedurlarına əməl etməli və milli CSIRT ilə əlaqə saxlamalıdır ^[2].