İçeriğe geç

Linux Çekirdeğinde TCP Açığı (CVE-2026-98432): Düzeltme Durumu ve Atılacak Adımlar

Linux çekirdeğindeki CVE-2026-98432 TCP açığı: önem derecelerindeki farklar, dağıtımların düzeltme durumu ve düzeltme gelene kadar atılabilecek adımlar.

15 Ekim 2026’da Linux çekirdeği ekibi, çekirdeğin IPv4 TCP el sıkışma kodundaki bir bellek hatası için CVE-2026-98432 numarasını yayımladı. Hata, bir yarış koşuluna bağlı “use-after-free” (serbest bırakılmış belleğin kullanılması) türünde. CVE kaydı kimlik doğrulaması gerektirmeyen, ağ üzerinden bir saldırıyı tarif ediyor ve 9.8 (“kritik”) puan veriyor. 27 Ekim’de Anthropic, bu açık için uzaktan kod çalıştıran bir istismar geliştirdiğini açıkladı (şirketin kendi beyanı). Dağıtımların durumu ise birbirinden çok farklı: bazıları düzeltilmiş çekirdek yayımladı, Ubuntu hazırlıyor, Red Hat RHEL 8, 9 ve 10 için henüz düzeltme yayımlamadı. Bu yazıda önce açığın ne olduğunu ve kaynakların neden farklı önem dereceleri verdiğini, sonra dağıtımların durumunu ve düzeltme gelene kadar neler yapılabileceğini anlatıyoruz. Dağıtım durumları 30 Ekim 2026’da ilgili sayfalardan okunmuş ve son olarak 09:47’de (TSİ) yeniden denetlenmiştir; saatler içinde değişebilir.

Kısaca

  • Ne: IPv4 TCP el sıkışmasında, iki işlemcinin aynı bellek alanını aynı anda kullanmasından doğan bir use-after-free. Hata 4.4 sürümünden beri çekirdekte. Düzeltme, iki yerde kfree() çağrısını kfree_rcu() ile değiştiren iki satırlık bir yama.
  • Önem derecesi tek değil: Çekirdek CNA’sı ve Ubuntu 9.8 veriyor; SUSE, Oracle, Amazon Linux ve Red Hat 8.1 veriyor. Fark, yarışı kazanmanın zorluğuna bakıştan geliyor. NVD henüz değerlendirme yapmadı.
  • Düzeltme dağıtıma göre değişiyor: Debian 12 ve 13 güvenlik depoları, SUSE’nin bir bölümü, Oracle Linux UEK ve Amazon Linux 2023’ün bazı çekirdek paketleri düzeltildi. Ubuntu 22.04’ten 26.10’a kadar düzeltmeyi hazırlıyor; Red Hat RHEL 8, 9 ve 10’u etkilenmiş olarak listeliyor ve henüz düzeltme yayımlamadı.
  • İstismar: CISA’nın bilinen sömürülen açıklar kataloğunda yok. 30 Ekim’de GitHub’da, kendini açığı tetikleyen ve çekirdek adresi sızdıran bir araç olarak tanıtan en az iki topluluk deposu açıldı. Bunları çalıştırmadık, çalıştıklarını doğrulamadık. Anthropic, MPTCP dinleyicisi olan bir sunucuya karşı uzaktan root komutu çalıştıran bir kavram kanıtı geliştirdiğini söylüyor. Bu, şirketin kendi beyanıdır; yazı istismar koduna bağlantı vermiyor. Go Güvenlik Ekibi ise hatanın MPTCP’ye özgü olmadığını belirtiyor.
  • Karıştırmayın: Aynı hafta kataloğa giren çekirdek açığı CVE-2026-46300 ayrı bir hatadır ve düzeltilmiş çekirdekler aylardır mevcuttur.
  • Ne yapmalı: Çalışan çekirdeği dağıtımınızın durumuyla karşılaştırın, internete açık TCP servisleri çalıştıran ana makineleri öne alın, düzeltme gelince yeniden başlatarak uygulayın. Konteynerlerde çözüm, ana makinenin çekirdeğinin güncellenmesidir.

Ne oldu?

Tarih (2026) Olay
1 Ekim Düzeltme yaması yazıldı (Eric Dumazet). Yama, hatayı bildiren kişi olarak Xinyang Ge’yi anıyor; bildirimde anthropic.com alan adlı bir adres kullanılmış.
15 Ekim Linux çekirdeği CVE kaydını yayımladı; dağıtımların izleme sayfaları açıldı.
16 Ekim Oracle Linux, UEK çekirdekleri için düzeltmeleri yayımladı.
24 Ekim Amazon Linux 2023 için kernel6.18 paketi düzeltildi (ALAS2023-2026-3251).
27 Ekim Anthropic, bu açık için geliştirdiği istismarı da anlatan araştırma yazısını yayımladı.
29 Ekim SUSE, düzeltme paketlerinin duyurularını yayımladı (SUSE-SU-2026:24386-1 ve 24422-1). Amazon Linux 2023 için kernel6.12 paketi düzeltildi (ALAS2023-2026-3335).

Açık nasıl işliyor?

TCP bağlantısı kurulurken sunucu, önce “yarı açık” bir bağlantı isteği (request socket) tutar; el sıkışma bitince bu istek, gerçek bağlantıyı temsil eden bir “çocuk sokete” dönüşür. Gelen SYN paketi IP seçenekleri taşıyorsa çekirdek bunları isteğin içinde saklar. Hata şurada: çocuk soket oluşurken bu seçenekler kopyalanmıyor, sahipliği çocuğa devrediliyor. O sırada başka bir işlemci, aynı istek için yeniden gönderilen bir SYN’e yanıt (SYN+ACK) hazırlarken aynı seçenekleri okuyabiliyor. Çocuk soket bu arada kapanır ve seçenekleri düz kfree() ile serbest bırakırsa, yanıtı hazırlayan kod serbest bırakılmış belleği okuyor ve onunla işlem yapıyor. Düzeltme, belleği hemen değil, ondan okuyan tüm işlemlerin işini bitirmesini bekledikten sonra (RCU “grace period”) serbest bırakıyor.

Kayıttaki ve düzeltme yamasındaki koşullar şöyle:

  • Yalnız IPv4. IPv6, birinci yoldan etkilenmiyor çünkü seçenekleri kopyalıyor. IPv6’daki benzer bir bağlantı göçü sorunu (yalnızca CALIPSO ile kullanılan seçenekler için) ayrı bir yamayla ele alınacak.
  • IP seçenekleri. CVE kaydındaki saldırı senaryosu, kimlik doğrulamasız bir eşin SYN paketine IPv4 “Record Route” ya da “Timestamp” seçeneği koymasına ve yarışı tekrar tekrar denemesine dayanıyor. Senaryo, saldırının zaten dinleyen bir servise karşı yapıldığını varsayıyor.
  • İkinci yol. İstek soketlerinin başka bir dinleyiciye taşınması (net.ipv4.tcp_migrate_req=1 ya da BPF_SK_REUSEPORT_SELECT_OR_MIGRATE türünde bir eBPF programı) benzer bir sorunun ikinci bir yolunu açıyor; yama ikisini birlikte düzeltiyor. Bu ayarın çekirdek belgelerindeki varsayılan değeri 0 (kapalı).

Ne kadar ciddi? Kaynaklar neden ayrışıyor?

Kaynak Derece, puan ve gerekçe
Linux çekirdeği CNA’sı Kritik, CVSS 3.1: 9.8. Saldırı karmaşıklığı “düşük”; gizlilik, bütünlük ve erişilebilirlik etkisi “yüksek”.
Ubuntu Yüksek, 9.8 (v3) ve 8.3 (v4). v3 vektörü CNA’nınkiyle aynı.
SUSE Önemli, 8.1 (v3) ve 9.2 (v4). v3’te saldırı karmaşıklığı “yüksek”, v4’te “düşük” (saldırı gereksinimi: mevcut).
Oracle Linux Önemli, 8.1. Kendi sayfasında “ön değerlendirme” olarak işaretli.
Amazon Linux Önemli, 8.1. Saldırı karmaşıklığı “yüksek”.
Red Hat Önemli (“Important”), 8.1 (taslak). Saldırı karmaşıklığı “yüksek”. Red Hat’ın veri servisi (API) ise hâlâ daha eski bir değerlendirmeyi gösteriyor: Orta, 5.9, ağırlıklı olarak hizmet reddi.
NVD Henüz değerlendirme yok (“Received”). CNA’nın puanını ikincil olarak gösteriyor.
Debian Aciliyet belirtilmemiş.

Fark ağırlıklı olarak tek soruya verilen cevaptan geliyor: yarışı kazanmak ne kadar zor? CNA “düşük” diyor (9.8); SUSE, Oracle, Amazon Linux ve Red Hat “yüksek” diyor (8.1). Değerlendirmeler de değişiyor: Red Hat’ın veri servisi (API) hâlâ daha eski bir değerlendirmeyi (5.9, ağırlıklı olarak hizmet reddi) gösteriyor, CVE sayfası ise 8.1 gösteriyor. Hangisinin haklı olduğuna biz karar vermiyoruz; planlama için yüksek ucu varsaymak ihtiyatlı olur.

İstismar olasılığı için iki göstergeye bakılabilir. FIRST’ün EPSS modeli 29 Ekim’de önümüzdeki 30 gün için istismar gözlenme olasılığını yaklaşık %0,4 olarak tahmin ediyor. CISA’nın bilinen sömürülen açıklar kataloğunda (29 Ekim sürümü) bu CVE yok. İkisi de “güvendesiniz” anlamına gelmez; bir tahmin ve bir kayıttır.

Anthropic’in açıklaması: ne söylüyor, ne söylemiyor?

Anthropic’in 27 Ekim 2026 tarihli araştırma yazısı bu açığı CVE numarasıyla anıyor. Yazıya göre, Anthropic’in yayımlanmamış dahili bir araştırma modeliyle yürüttüğü çalışmada Claude, MPTCP (çok yollu TCP) dinleyicisi olan Linux sunucularına paket göndererek kimlik bilgisi ya da kullanıcı etkileşimi olmadan root olarak komut çalıştıran bir istismar yazdı. İstismar iki aşamalı: önce çekirdeğin adres düzeni rastgeleleştirmesini (KASLR) uzaktan aşıyor, sonra bir geri çağırma işaretçisini ezerek kontrolü ele geçiriyor. Yazı, kaybedilen bir yarışın yalnızca el sıkışmayı başarısız kıldığını, sistemi çökertmediğini; bu yüzden saldırganın sınırsız deneyebildiğini söylüyor. Kavram kanıtında bir çekirdek işaretçisinin sızdırılması 48 dakika, kabuk komutunun çalışması ise 5 dakika daha sürmüş. Anthropic ayrıca açığın yukarı akışta yamalandığını ve bakımı süren tüm kararlı çekirdek dallarına geri taşındığını belirtiyor.

Bunların hepsi şirketin kendi beyanıdır. Okurken şunları akılda tutun:

  • Yazı istismar koduna bağlantı vermiyor ve bağımsız bir doğrulama bulamadık.
  • CVE kaydı ve düzeltme yaması MPTCP’den söz etmiyor. Go Güvenlik Ekibi’nin 29 Ekim tarihli duyurusu, gösterilen istismarın bir MPTCP dinleyicisi gerektirdiğini, ancak hatanın MPTCP’ye özgü olmadığını ve MPTCP dinleyicisi olmayan sistemlerin de benzer saldırılara açık olabileceğini söylüyor.
  • Bizim çıkarımımız (kaynaklarda yok): yöntem yarışın tekrar tekrar denenmesine dayandığı için, dakikalarca süren bir deneme akışı ağ izlemede fark edilebilir.
  • Anthropic, yazısında yapay zekâ modellerinin açıkları bulup birleştirerek çalışan istismarlara dönüştürebildiğini söylüyor. Bu iddiayı bu sayfada bağımsız olarak doğrulamadık. Savunma tarafı için sonuç değişmiyor: envanter, önceliklendirme ve düzeltmenin gerçekten uygulandığının doğrulanması.

Hangi dağıtım düzeltildi?

Aşağıdaki durumlar ilgili sayfalardan 30 Ekim 2026’da okunmuş ve son olarak 09:47’de (TSİ) yeniden denetlenmiştir. Kayıtlar saatler içinde değişiyor; yukarıdaki okuma saatine bakın. Red Hat’ın CVE sayfası ile veri servisi (API) de farklı değerler gösteriyor.

Dağıtım Durum
Debian 12 (bookworm) Düzeltildi (güvenlik deposu): 6.1.190-1 (DLA-4841-1). Ana depodaki 6.1.176-1 sürümü etkilenmiş görünüyor.
Debian 13 (trixie) Düzeltildi (güvenlik deposu): 6.12.113-1 (DSA-6568-1). Ana depodaki 6.12.107-1 sürümü etkilenmiş görünüyor.
Ubuntu 22.04, 24.04, 26.04, 26.10 Düzeltme hazırlanıyor, henüz yayımlanmadı: sırasıyla 5.15.0-203.213, 6.8.0-149.149, 7.0.0-43.43 ve 7.3.0-10.10 sürümlerinde. Bulut çekirdeklerinde durum karışık: aws, azure ve oracle’ın ana hatlarında düzeltme hazırlanıyor, gcp ve birçok alt hat için henüz “gerekli” olarak görünüyor.
Ubuntu 20.04, 18.04, 16.04 Etkilenmiş, düzeltme yok. 14.04 etkilenmiyor.
Red Hat Enterprise Linux 8, 9, 10 Etkilenmiş, düzeltme henüz yok (OpenShift 4 düğümleri dahil; CVE sayfasında “Affected”). RHEL 7 etkilenmiyor. Red Hat, azaltmanın ya bulunmadığını ya da kendi ölçütlerini karşılamadığını belirtiyor. Veri servisi aynı ürünler için “düzeltme ertelendi” diyor.
SUSE Linux Enterprise Karışık: SLES 16.0 ve 15 SP4, SP5, SP6 (LTSS) için yayımlandı; 15 SP7, 12 SP5 ve Micro 6.0, 6.1 için etkilenmiş ya da çalışma sürüyor.
Oracle Linux Kısmen: UEK çekirdekleri için 7, 8, 9 ve 10’da düzeltme var; Red Hat uyumlu çekirdek (RHCK) için sayfa bilgi vermiyor.
Amazon Linux Kısmen: AL2023’te kernel6.12 (ALAS2023-2026-3335) ve kernel6.18 (ALAS2023-2026-3251) düzeltildi; AL2023 kernel paketi ve AL2 (destek sonu) için “düzeltme bekleniyor”.

AlmaLinux, Rocky Linux gibi RHEL türevlerinin ve diğer dağıtımların durumuna kendi duyurularından bakın; burada onları ayrıca incelemedik.

Kendi çekirdeğini derleyenler ya da kernel.org çekirdeği kullananlar için düzeltilmiş sürümler 5.10.272, 5.15.223, 6.1.190, 6.6.159, 6.12.113, 6.18.56 ve 7.2.10; ana hatta düzeltme 7.3 sürümünde. 5.4 ve daha eski dallar için kayıtta düzeltilmiş sürüm yok.

Kayıt, düzeltmeyi 5.10’dan 7.2’ye yedi kararlı dalda listeliyor; bu, Anthropic’in yazısındaki “bakımı süren tüm kararlı dallara geri taşındı” ifadesiyle uyumlu görünüyor. Ancak dağıtımlar kendi çekirdeklerini kendi takvimlerinde derliyor: çekirdek ekibinin düzeltme yayımlaması, sizin dağıtımınızda düzeltilmiş bir paket olduğu anlamına gelmiyor. Ubuntu ve Red Hat kullanıcıları için belirleyici olan bu boşluktur.

Aynı hafta kataloğa giren başka bir çekirdek açığı: CVE-2026-46300

28 Ekim’de CISA, bilinen sömürülen açıklar kataloğuna başka bir Linux çekirdeği açığını, CVE-2026-46300’ü ekledi. Bu, soket arabelleklerinin birleştirilmesinde bir işaretin korunmamasından doğan yerel bir hata (CVSS 7.8). CISA’nın kaydına göre PHP açıklarıyla (CVE-2026-109618 ve CVE-2026-109619) zincirlenerek PHP web kabuğu yerleştirmek ve root olarak komut çalıştırmak için kullanılabiliyor. CVE-2026-98432 ile ilgisi yok ve ikisini karıştırmamak gerekiyor: CVE-2026-46300 için çekirdek düzeltmeleri aylardır dağıtımlarda var (düzeltilmiş kararlı sürümler 5.10.257, 5.15.208, 6.1.174, 6.6.141, 6.12.91, 6.18.33 ve 7.0.10; Red Hat’ın ilk erratalarının tarihi 20 Mayıs 2026). Çekirdeğinizin bu düzeltmeyi içerdiğini, dağıtımınızın CVE-2026-46300 sayfasındaki düzeltilmiş sürümle karşılaştırarak doğrulayın; içermiyorsa bu hafta öncelikle güncellenmesi gereken açık budur. CVE-2026-98432 ise katalogda değil.

Ne yapmalısınız?

  1. Maruziyeti çıkarın. Hangi Linux ana makineleriniz IPv4 üzerinde TCP bağlantısı kabul ediyor ve hangileri internete ya da güvenmediğiniz ağlara açık? ss -ltn dinleyen TCP servislerini listeler; ss -M -l -n MPTCP dinleyicilerini gösterir. Konteynerler ana makinenin çekirdeğini kullanır: imajı yeniden derlemek bu açığı kapatmaz, ana makinenin (ya da yönetilen düğüm havuzunun) çekirdeği güncellenmelidir.
  2. Çalışan çekirdeği dağıtım durumuyla karşılaştırın. uname -r çalışan çekirdeği, Debian ve Ubuntu’da dpkg -l 'linux-image*', RHEL ailesinde rpm -qa 'kernel*' kurulu paketleri gösterir. Dağıtımlar yamaları kendi sürüm numaralarıyla geri taşır; tek başına çekirdek numarası yetmez. Dağıtımınızın CVE sayfasındaki düzeltilmiş paket sürümüyle karşılaştırın ya da paket değişiklik kaydında CVE numarasını arayın (rpm -q --changelog kernel | grep CVE-2026-98432; Debian ve Ubuntu için apt changelog linux-image-$(uname -r)). Çıktının boş olması “etkilenmiyorsunuz” demek değildir.
  3. Önceliği belirleyin. Önce internete açık ve TCP dinleyen sistemler (web, e-posta, VPN, yük dengeleyici), çok kiracılı ana makineler ve MPTCP dinleyicisi olanlar gelir. Katalogda olmamak bekleme gerekçesi değildir: PHP açıkları da 23 Ekim kataloğunda yoktu, 26 Ekim’de eklendi.
  4. Düzeltmeyi izleyin ve geldiğinde uygulayın. Dağıtımınızın CVE sayfasını izleyin (bağlantılar Kaynaklar’da). Canlı yama (live patch) kullanmıyorsanız çekirdek güncellemesi yeniden başlatma gerektirir; bakım penceresini şimdiden planlayın. Güncellemeden sonra uname -r ile yeni çekirdeğin gerçekten çalıştığını doğrulayın (örneğin Debian ve Ubuntu’da needrestart -k, RHEL ailesinde dnf needs-restarting -r). Canlı yama sağlayıcınız varsa düzeltmeyi içerip içermediğini onların duyurusundan öğrenin.
  5. Düzeltme gelene kadar ek sertleştirme düşünün (yama değildir).
    • IP seçenekli paketler. CVE kaydındaki saldırı senaryosu SYN paketinde Record Route ya da Timestamp seçeneği bulunmasına dayanıyor. RFC 7126 (BCP 186), güvenlik duvarlarının ve yönlendiricilerin bu seçenekleri taşıyan paketleri varsayılan olarak düşürmesini öneriyor ve IPv4 seçenekli paketleri engellemenin yaygın bir uygulama olduğuna işaret eden veriler bulunduğunu belirtiyor. Sınır güvenlik duvarınız ya da yük dengeleyiciniz bunu zaten yapıyor olabilir; varsaymayın, test edin. Bu, incelediğimiz dağıtım duyurularında bu CVE için belgelenmiş bir azaltma değildir (Red Hat, ölçütlerini karşılayan bir azaltma olmadığını söylüyor). Filtrenin arkasındaki ya da aynı ağdaki bir saldırganı durdurmaz ve IP seçeneklerini kullanan tanılama araçlarını etkileyebilir. Uygulamadan önce sistem yöneticinizle değerlendirin.
    • Bağlantı göçü. sysctl net.ipv4.tcp_migrate_req çıktısı 0 olmalı ve BPF_SK_REUSEPORT_SELECT_OR_MIGRATE türünde bir eBPF programı çalışmıyor olmalı; aksi halde ikinci yol açık demektir (sysctl anahtarı yoksa çekirdeğinizde bu özellik bulunmuyor olabilir). Bunları kapatmak yalnız ikinci yolu kapatır, ana yarışı kapatmaz.
    • MPTCP. Anthropic’in anlattığı istismar, MPTCP dinleyicisi olan bir sunucuyu hedefliyor. ss -M -l -n ile MPTCP dinleyicisi olup olmadığına bakın: Go 1.24’ten beri Go programları Linux’ta dinleme soketleri için MPTCP’yi varsayılan olarak etkinleştiriyor (Go Güvenlik Ekibi), yani siz açmamış olsanız da Go ile yazılmış servisleriniz MPTCP dinleyicisi açıyor olabilir. Go programlarında GODEBUG=multipathtcp=0 ortam değişkeni bunu çalışma zamanında kapatır. net.mptcp.enabled=0 ayarı da MPTCP soketlerinin oluşturulmasını engeller; ancak ad alanı başınadır (konteynerlerde ayrıca uygulanması gerekir). Go ekibi, programları tek tek ayarlamayı kırılgan bir azaltma olarak niteliyor: tek bir açık MPTCP dinleyicisi sistemi savunmasız bırakır. MPTCP’yi kapatan her yöntem ayrıca, tüm istismarların MPTCP’ye bağlı olduğunu varsayar; oysa hata MPTCP’ye özgü değildir. Asıl çözüm yamalı çekirdektir.
    • İzleme. Olağan dışı IP seçenekli SYN akışına ve tekrarlanan başarısız el sıkışmalara bakın. CVE kaydı, istismarın skb_under_panic ya da ip_options_build içeren çekirdek hatalarına yol açabileceğini belirtiyor; bu ifadeleri çekirdek günlüklerinde (dmesg, journald) arayabilirsiniz.
    • Üçüncü taraf betikler. GitHub’da 29 Ekim’de açılan, azaltma, denetim ve canlı yama (livepatch) amaçlı birkaç topluluk deposu var. Bunları denetlemedik ve önermiyoruz. Üçüncü taraf betikler tedarik zinciri riski taşır: çekirdeğe ya da güvenlik duvarına dokunan bir betiği, kaynağını okumadan ve test ortamında denemeden üretim sistemlerinde çalıştırmayın.
  6. Destek ömrünü doldurmuş çekirdekleri ayrı listeye alın. Kayıt, 4.4’ten itibaren etkilenen tüm sürümleri sayıyor ama yalnızca yukarıdaki dallar için düzeltme listeliyor. Ubuntu’nun izleyicisi 20.04, 18.04 ve 16.04’ü etkilenmiş gösteriyor. Bu sistemler için genişletilmiş destek, dağıtım yükseltmesi ya da cihaz üreticisinin yazılımı gibi ayrı bir plan gerekir; yönlendirici, NAS ve güvenlik duvarı gibi cihazlarda üretici duyurusunu bekleyin.

Zafiyet taraması ve sızma testi bu açıkta ne işe yarar?

Önce sınırı koyalım: Bu tür bir çekirdek açığının varlığı dışarıdan çoğu zaman görülemez. Dışarıdan yapılan bir zafiyet taraması internete açık servisleri ve görünen sürüm bilgisini çıkarır, ama çalışan çekirdeğin yama düzeyini ve dağıtımın geri taşıdığı düzeltmeleri güvenilir biçimde göremez. Hiçbir test bu konuda garanti vermez. Bu açıkta değerleri dört yerde görünür olur:

  1. Maruziyet haritası. Dış ağ zafiyet taraması, internete açık IP adreslerinizi ve TCP servislerinizi çıkarır: hangi sistemler dışarıdan bağlantı kabul ediyor, beklemediğiniz bir servis var mı? Bu liste yukarıdaki önceliklendirmeyi besler.
  2. Çekirdek yama düzeyi. İç ağ zafiyet taraması, mümkün olduğunda kimlik doğrulamalı yapılırsa kurulu çekirdek paketlerini yama kayıtlarıyla karşılaştırabilir; yani “hangi ana makinede hangi çekirdek var” sorusuna envanter düzeyinde yanıt verir. Kimlik doğrulamasız tarama bunu yapamaz.
  3. Etkinin sınırı. Dış ağ sızma testi ve iç ağ sızma testi, bir ana makine ele geçirilirse saldırganın nereye ulaşabileceğini, ağ bölümlendirmesinin işe yarayıp yaramadığını sınar. Bu testler bu açığın kendisini istismar etmeyi hedeflemez: yarış koşuluna dayanan bir çekirdek açığını üretim sistemine karşı denemek hizmet kesintisine yol açabilir; böyle bir deneme ancak sistem sahibinin kapsamı ve yazılı yetkisiyle düşünülebilir.
  4. Yeniden test. Düzeltmeler uygulandıktan sonra yapılan yeniden test, dışarıdan görünen servis envanterinin beklendiği gibi olduğunu gösterir. Çekirdeğin gerçekten güncellendiği sistem tarafında, yukarıdaki komutlarla ayrıca doğrulanmalıdır.

Seemarter Security ile

Dış ağınızın mevcut durumunu görmek için dış ağ zafiyet taraması ve dış ağ sızma testi hizmetlerimizi inceleyebilir ya da bizimle iletişime geçebilirsiniz. Tüm çalışmalar, sistem sahibinin yazılı yetkisiyle ve önceden belirlenen kapsamda yapılır.

Kaynaklar

Bu yazı 30 Ekim 2026 itibarıyla yayımlanmış kaynaklara dayanır; gelişmelere göre güncellenir.

Bir sonraki adım

Kapsamı Birlikte Belirleyelim.

İlk görüşmede varlıklarınızı, zaman pencerelerini ve çalışma kurallarını birlikte netleştiriyoruz. Hiçbir tarama ya da test, yazılı onayınız olmadan başlamaz.