Tedarikçinin Refleksi, Müşterinin Sorumluluğu: cPanel ve Copy Fail Zafiyetleri Karşısında Hukuki Çerçeve
cPanel, Copy Fail ve Olanlar
28-29 Nisan 2026 günleri, küresel internet altyapısının iki ayrı katmanını sarsan iki kritik güvenlik açığı kamuoyuyla paylaşıldı. Birincisi, dünya genelinde milyonlarca web sitesinin ve e-posta sunucusunun yönetildiği cPanel & WHM adlı kontrol panelini doğrudan etkiliyor. İkincisi, sunucu dünyasının büyük bölümünün üzerine kurulu olduğu Linux çekirdeğinin içinde, dokuz yıldır fark edilmemiş bir mantık hatasını ortaya çıkardı.
30 Nisan sabahı itibarıyla yamalanmamış sunucularda yaygın istismar girişimleri gözlemlenmeye başlandı. Bu yazı, olayın boyutunu, sahadaki gerçekliğini ve hukuki sorumluluk çerçevesini ortaya koymayı amaçlıyor.
İlk açık, resmi tanımıyla CVE-2026-41940. Önem derecesi 10 üzerinden 9.8 — bilişim dünyasında pratik olarak en üst seviyeye yakın. Açığın işleyişi şu: cPanel ve WHM (kontrol paneli ve web barındırıcı yönetim arayüzü), kullanıcının oturum açması sırasında bir oturum dosyası oluşturuyor. Saldırgan, gönderdiği isteğin içine özel karakterler enjekte ederek, henüz kimliği doğrulanmamış olmasına rağmen sisteme “ben yöneticiyim” diye yazdırıyor. Şifre yok, doğrulama yok, atlatma var. Saldırgan bu noktadan itibaren sunucudaki tüm web sitelerine, e-postalara, veritabanlarına ve dosyalara erişim potansiyeli kazanıyor.
İnternet tarama verilerine göre aramaya açık ve potansiyel olarak savunmasız yaklaşık 1.5 milyon cPanel sunucusu var; Türkiye merkezli siber tehdit istihbaratı şirketlerinin tespitlerine göre bunların 600.000’i aşkını 30 Nisan sabahı itibarıyla aktif tehdit altında. Üstelik açığın 23 Şubat 2026 kadar erken bir tarihte hedefli saldırılarda kullanılmış olabileceği değerlendiriliyor — yani açıklanmadan iki aya yakın bir sürede de istismar edilmiş olma ihtimali yüksek.
İkinci açık, CVE-2026-31431 — sahaya verilen ismiyle Copy Fail (Kopyalama Hatası). Bu zafiyet, Linux çekirdeğinin içinde, şifreleme işlemleri yapan bir alt sistemde gizli kaldı. Etki alanı çarpıcı: 2017’den bu yana yayımlanan tüm büyük Linux dağıtımları — Ubuntu, Red Hat Enterprise Linux, Amazon Linux, SUSE — varsayılan yapılandırmalarda etkileniyor.
Saldırı şekli daha da çarpıcı: uygun koşullarda, sıradan bir kullanıcı (yetkisiz, normal hesap), 732 baytlık bir Python betiği çalıştırarak sistemin tüm yetkilerine sahip yönetici (root) konumuna yükselebiliyor. Belirli bulut izolasyon mimarileri (Firecracker, gVisor gibi) bu zincire kapalı olsa da paylaşılan çekirdek üzerinde çalışan sistemler genel risk altında.
Üstelik açığı bulan, yapay zekâ destekli bir güvenlik tarama sistemi: Theori adlı şirketin Xint Code aracı, Linux çekirdeğinin şifreleme kodunu yaklaşık bir saatlik bir tarama sonucunda zafiyeti yakaladı. Bu boyut, hem güvenlik araştırmacılarının üretkenliğini katlayan, hem de saldırganların eline benzer araçlar geçtiğinde tehdit yüzeyinin nasıl genişleyebileceğini gösteren bir an.
İki açığın birlikte değerlendirilmesi gerekiyor. cPanel açığı, internetten doğrudan saldırıya açık — saldırganın sisteme uzaktan girmesini sağlıyor. Copy Fail, içeride zaten sıradan kullanıcı yetkisine sahip olan saldırganın, sistemin tüm yetkilerine yükselmesini sağlıyor. Yani biri kapıyı açıyor, diğeri içeride anahtarları topluyor. Bir saldırgan cPanel açığını kullanarak sınırlı bir kullanıcı hesabıyla sisteme girip, ardından Copy Fail ile o sistemin tamamını ele geçirebilir. Bu zincir, saldırı ekonomisinde çok yaygın bir kalıbın somut karşılığı.

Görsel 1: Saldırı vektörü diyagramı — cPanel ve Copy Fail saldırı yollarının paralel akışı ve kesişim noktası
Sahada Ne Yaşandı?
cPanel zafiyetinin açıklandığı 28 Nisan akşamı, Türkiye’de internet altyapısı sektörünün aktif çekirdeği — hosting şirketleri, sistem yöneticileri, sunucu operatörleri — saatler içinde alarm durumuna geçti. Sektörel iletişim kanalları, ağ operatörleri toplulukları (TRNOG), gece yarısından sabaha kadar kesintisiz teknik bilgi paylaşımına sahne oldu. Tarama betikleri, azaltıcı önlem komut zincirleri, IP bazlı saldırı imzaları, hangi cPanel sürümünün hangi yamayı aldığına dair karşılaştırma tabloları — hepsi sektörel topluluğun kendi inisiyatifiyle, herhangi bir resmi koordinasyon merkezinin yönlendirmesi olmaksızın paylaşıldı.
30 Nisan sabah saatlerine gelindiğinde manzara netleşti. Sektörel gözlemlere göre Türkiye’deki büyük bir hosting sağlayıcısının yamalanmamış cPanel sunucularındaki iki yüze yakın müşteri sitesi hizmet dışı kaldı; saldırganlar sistemleri ele geçirdi, dosyaları sildi veya değiştirdi, hizmetler kesildi. Profesyonel yedekleme çözümleri kullanan müşteriler kademeli olarak geri döndü; yedeği aynı sunucuda tutan ya da yedek mimarisi olmayan müşteriler beklemeye geçti.
Bu tabloda karşımıza çıkan pratik gerçek şu: yedeklerin fiziksel ve mantıksal olarak ana sistemden ayrılmış olması, bir teknik tercih değil, hayat kurtarıcı bir mimari karar.
Saha gerçekliğinin ikinci katmanı, lisans modelinin yarattığı paradoks. Türk hosting sektörünün belirli bir kesimi, cPanel’in resmi lisansı yerine gri pazardan tedarik edilen ucuz lisans çözümlerini kullanıyor. Bu lisanslarla çalışan sunucular, cPanel’in sürüm güncelleme altyapısından doğrudan bilgi ve yama almıyor.
28 Nisan akşamı cPanel’in tüm lisanslı yönetim ekranlarına gönderdiği acil yama uyarısı, gri pazar lisanslı sistemlere ulaşmadı; sabaha kadar geçen kritik pencerede bu sunucular savunmasız kaldı. İkinci paradoks lisanslı tarafta yaşandı: cPanel’in işletim sistemi destek listesinden çıkardığı belirli Linux dağıtımlarını hâlâ kullanan sunucular, en güncel cPanel sürümüne yükseltme imkânı bulamıyor. Lisans var, güncelleme erişimi var, ama altyapı uyumsuzluğu yamayı engelliyor. Tek tedarikçiye bağımlılık (vendor lock-in) burada bile somutlaştı.
Yamayı uygulayanların bile rahatlamasına izin vermeyen üçüncü bir teknik gerçek var. Açığın yapısı şöyle: saldırgan sisteme girdiğinde bir oturum dosyası yaratılıyor; bu dosya yamadan sonra da diskte kalıyor, yamanın kapsamı dışında.
Yani saldırgan zafiyeti açıklanmadan önceki dönemde sisteme girip oturum oluşturmuşsa, sistem yamalandıktan sonra bile o oturum üzerinden erişimini sürdürebiliyor. Tek başına yama yetmiyor; mevcut oturum dosyalarının temizlenmesi, ilgili hizmetlerin yeniden başlatılması, güvenlik ihlali göstergelerine yönelik tarama yapılması da gerekli. Yamanın kendisi bir kapıyı kapatıyor; ama açık kapıdan içeri zaten girmiş olan saldırganı dışarı atmıyor.
Türkiye dışında resmi koordinasyon zinciri farklı bir tabloya işaret etti. cPanel kendi güvenlik bültenini 28 Nisan akşamı yayımladı. CVE numarası MITRE tarafından 29 Nisan’da atandı. Kanada Siber Güvenlik Merkezi 29 Nisan’da AL26-008 numaralı resmi alarmı yayımladı; “istismar olasılığı çok yüksek, acil aksiyon gerekli” uyarısıyla. Linux çekirdeği tarafında koordineli açıklama, Theori firmasının teknik yayını ve mainline yama ile birlikte tamamlandı; Ubuntu, Red Hat, SUSE, Amazon Linux gibi büyük dağıtımlar yamalarını sırayla yayımlamaya başladı.
Türkiye’de aynı koordinasyon zincirinin ulusal halkası ise farklı bir tabloda duruyordu. 30 Nisan saat 11:00 itibarıyla USOM’un (Ulusal Siber Olaylara Müdahale Merkezi) Güvenlik Bildirimleri sayfası Wireshark, Jenkins ve Google Chrome zafiyetleri için bildirim yayımlamış durumdaydı; cPanel CVE-2026-41940 ya da Copy Fail için ise henüz bir bildirim mevcut değildi.
Açıklamadan istismara açılan kritik 48 saatlik penceresinde, sektörün resmi koordinasyon mekanizmasının harekete geçişi, eş zamanlı uluslararası muadil kurumların ve sektörel topluluğun gerisinde kaldı. Türk hosting şirketleri bu pencereyi kendi öz-örgütlenmesiyle doldurdu — ancak bu koordinasyon, hesap verebilirlik zincirinin ve resmi yetkinin dışında kalıyor.
Hukuki Çerçeve: Dört Yükümlülük Katmanı
Bu olayın hukuki anlamını anlayabilmek için, sahanın çoğu zaman karıştırdığı dört ayrı yükümlülük katmanını ayrı ayrı görmek gerekiyor.
Birinci katmanda, KVKK m.12 yükümlülüğü var: işlenen kişisel verilere hukuka aykırı erişimi önlemek için “uygun güvenlik düzeyini temin etmeye yönelik gerekli her türlü teknik ve idari tedbiri” almak. İhlal gerçekleştiğinde, m.12/5 gereği veri sorumlusu durumu en kısa sürede ilgili kişiye ve Kurul’a bildirmek zorunda; KVKK Kurulu’nun yerleşik içtihadına göre bu süre 72 saat olarak somutlaşmış durumda.
İkinci katmanda, Türk Ticaret Kanunu m.553 yöneticilerin kanuni yükümlülüklerini ihmal etmesinden doğan zararlar için sorumluluk öngörüyor; m.369 ise tedbirli bir yöneticinin özeniyle hareket etmeyi emrediyor.
Üçüncü katmanda, 7545 sayılı Kanun m.7 — kritik altyapı operatörleri için tespit edilen zafiyet veya siber olayların gecikmeksizin Siber Güvenlik Başkanlığı’na bildirimi. Dördüncü katmanda, BTK Şebeke ve Bilgi Güvenliği Yönetmeliği m.38 — elektronik haberleşme işletmecileri için abonelerin yüzde beşinden fazlasını etkileyen ihlaller için bildirim yükümlülüğü.
Bu dört katman birbirinden bağımsız işliyor; biri yerine getirildi diye diğerleri otomatik karşılanmış sayılmıyor. Bir telekom işletmecisi, aynı olay için aynı anda BTK’ya, SGB’ye ve KVKK’ya raporlama yapmak zorunda kalabilir. Sıradan bir e-ticaret sitesi sahibi ise sadece KVKK m.12/5 ve TTK m.553/m.369 çerçevesinde hesap veriyor olabilir. Hangi yükümlülüklerin tetiklendiğini, somut olayın somut tablosu belirliyor.
İhlal Bildirimini Kim Yapacak?
Sahada zaman zaman duyulan önemli bir yanılgıya karşı uyarı gerek. “Açık cPanel’in, biz ne yapalım?” ya da “Linux çekirdeği zafiyetini Linux Foundation bildirsin” türü yaklaşımlar, hukuki çerçeveyi yanlış kuruyor.
Ne cPanel, ne Linux çekirdeğini geliştiren konsorsiyum, Türk hukukunda KVKK anlamında veri sorumlusu sıfatına sahip — bu kuruluşlar yazılım ürünü sağlıyor, son kullanıcıların verisini doğrudan işlemiyor. KVKK m.12/5’in bildirim yükümlülüğü, kişisel veriyi fiilen işleyen veri sorumlusuna ait. Bu, çoğu zaman hosting sağlayıcısı ve onun müşterisi olan web sitesi sahibi şirket.
Hosting sağlayıcısı, kendi sunucusunda barındırdığı verilere yetkisiz erişim olduğunu fark ettiği anda hem KVKK m.12/5 kapsamında 72 saatlik kronometre başlamış demektir, hem de veri işleyen sıfatı taşıyorsa veri sorumlusu olan müşterilerini gecikmeksizin bilgilendirmek zorunda. Müşteri şirketi — e-ticaret sitesi, üyelik portalı, kurumsal web sitesi sahibi — kendi adına KVKK Kurulu’na bildirim yapmaktan sorumlu. AB tarafında Siber Dayanıklılık Tüzüğü (Cyber Resilience Act), yazılım üreticilerine de doğrudan ürün güvenliği yükümlülükleri getirmeye başladı; Türkiye’de bu tip bir düzenleme henüz yok.
“İyi Tedarikçi” Tek Başına Yeterli mi?
Sahada sıkça karşılaşılan ikinci bir yanılgıya değinmek gerek. “Bizim hosting sağlayıcımız güvenilir, lisanslı, yamayı hemen yapıyor — biz koruma altındayız” yaklaşımı, teknik olarak iyi tedarikçi seçimini gösteriyor olabilir; ama hukuki olarak yetersiz bir pozisyon. Üç sebepten ötürü.
İlki, yama hızı, açıklamadan önceki dönemde — bu olayda iki aya yakın sürede — gerçekleşmiş olabilecek sıfırıncı gün (zero-day) istismarlarını geriye dönük telafi etmiyor. İkincisi, KVKK m.12/5 anlamında bildirim yükümlülüğü veri sorumlusunda; tedarikçinin teknik müdahalesi, müşterinin hukuki sorumluluğunu ortadan kaldırmıyor. Üçüncüsü, KVKK Kurulu’nun yerleşik doktrini, ihlalden sonra alınan tedbirin ihlalden önce alınmamış olanın yerini doldurmadığını söylüyor.
Bu doktrin soyut bir prensip değil, somut bir Kurul kararıyla netleşmiş durumda. KVKK’nın 8 Ağustos 2024 tarihli ve 2024/1385 sayılı Kararı, bir e-ticaret platformuna 3.250.000 TL idari para cezası uygularken gerekçesinde dört unsuru sıraladı.
- anomali tespit kapasitesinin yetersizliği; aynı IP’den iki günde dört yüzü aşkın oturum açma denemesi yapılmasına rağmen veri sorumlusu olayı ancak müşteri şikâyetleri üzerine fark edebilmişti.
- alınması gereken tedbirlerin ihlalden sonra alınmış olması; çift faktörlü kimlik doğrulama, tek seferlik parola, gelişmiş bot koruması — hepsi olaydan sonra devreye girmişti.
- çok faktörlü kimlik doğrulamanın yokluğunun açıkça mimari kusur olarak nitelendirilmesi.
- mevcut bot trafiği koruma servisinin saldırganlar tarafından aşılabilmiş olması.
Kurul bu dört unsurdan hareketle, “ihlalden sonra alınan tedbirler, ihlalden önce alınması gereken tedbirlerin yerini doldurmaz” prensibini uyguladı. Bugün cPanel ekosisteminde yaşanan tablo, bu prensibin teknik karşılığını ortaya koyuyor: yamayı uygulayan bir sistem, zafiyet açıklanmadan önceki dönemde oluşturulmuş oturum dosyalarını temizlemediği sürece açık kalıyor.
Yapılması Gerekenler: İki Paralel Akış
Bugünkü olayın ışığında, cPanel kullanan ya da Linux sunucularda hizmet veren her kurum için iki paralel kontrol akışı işlemeli. Teknik tarafta, yamalama, oturum dosyalarının temizlenmesi, IOC tarama betiklerinin çalıştırılması, port erişim kontrolü ve kernel modül yapılandırması gibi adımlar, sistem yöneticisinin uzmanlık alanına giriyor.
cPanel’in yayımladığı resmi güvenlik bülteni ve teknik destek dokümantasyonu bu adımların ayrıntısını içeriyor; uygulanacak müdahalelerin sunucunun mevcut yapılandırmasına göre farklılaşabileceği için, sistem yöneticisinin doğrudan üreticinin kaynaklarına başvurması ve gerekirse uzman destek alması gerekiyor.
Hosting hizmeti satın alan müşteri kurumun pratik talebi ise net: tedarikçinin yamayı uyguladığına, oturum dosyalarını temizlediğine, IOC taramasını yaptığına dair yazılı teyit istemek. Bu teyit hem operasyonel bir doğrulama, hem de olası bir hukuki incelemede özen yükümlülüğünün yerine getirildiğine dair kanıt değeri taşıyor.
Hukuki tarafta paralel bir kontrol listesi işlemeli. Web sitesi üzerinden kişisel veri toplanıyor mu, ihlal anında veriler etkilendi mi, yetkisiz erişim tespit edildi mi — bu üç soru hızla yanıtlanmalı. Eğer ihlal göstergesi varsa KVKK m.12/5’in 72 saatlik bildirim süresi başlamış demektir; olayın boyutu, etkilenen kişi sayısı, alınan tedbirler dahil bir bildirim hazırlanır. Telekom işletmecileri için BTK m.38 eşiği (abonelerin yüzde 5’i) ayrıca değerlendirilir. Kritik altyapı operatörleri için 7545 m.7 kapsamında SGB’ye bildirim yapılır.
Tedarikçinin teknik özeni ise yetmediği için, müşterinin denetim hakkını sözleşme düzeyinde kurmuş olması gerekiyor. AB’nin haziran 2025’te yayımladığı NIS2 Uygulama Rehberi, tedarikçi sözleşmelerinde sekiz unsurun bulunmasını şart koşuyor — tedarikçinin denetim hakkına tabi olması, olayları gecikmeksizin bildirme yükümlülüğü, alt yüklenicilerin de aynı standartlara tabi olması bunların başında. Türkiye’de bu standartlar henüz yasal zorunluluk değil; ama KVKK Kurulu içtihadı ve TTK m.369’un “tedbirli yönetici özeni” kavramı çerçevesinde özen yükümlülüğünün doğal bileşeni olarak yorumlanabilir durumda.
İki Prensip, Bir Sonuç
Bugünkü olay, siber güvenlik yönetiminin son on yıldır gelişen iki temel prensibini somut biçimde gösterdi. Birincisi, olay öncesi mimari kararların olay sonrasındaki sorumluluğu nasıl şekillendirdiği. Yedek izolasyonu, oturum yönetimi, çok katmanlı kimlik doğrulama, anomali tespiti, tedarikçi denetim hakkı — bunlar olay olduğunda eklenen değil, olaydan önce kurulmuş olması gereken mimari katmanlar.
İkincisi, tedarikçi seçiminin sağlam olmasının gerekli ama yeterli olmadığı; özen yükümlülüğünün doğrulanabilir denetim üzerinden işlediği. Bu iki prensibi somut sözleşme klozlarına, teknik kontrollere ve yönetim kurulu raporlama yapılarına yansıtmamış olan kurumlar, olay sonrası savunmalarında zorlu bir hukuki zeminde duruyor.
Bu yazıda anlatılanlar, daha geniş bir yapısal tabloya işaret ediyor. ENISA’nın aralık 2025’te yayımladığı NIS Investments 2025 raporu, AB’de siber güvenlik bütçelerinin sabit kaldığını ama içerideki ekipten teknoloji ve dış hizmete kaydığını ortaya koyuyor; aynı raporda, şirketlerin yatırımlarına yön veren etkenlerin başında yüzde yetmişle düzenleyici uyum baskısı yer alırken, yönetim kurulunun proaktif talebi yalnızca yüzde yedide kalıyor.
Aynı kurumun haziran 2025’te yayımladığı NIS2 Uygulama Rehberi ise yönetim kurulu sorumluluğunu, tedarikçi sözleşme klozlarını ve erişim kontrolü mimarisini somut beklentiler hâline getiriyor. İki belge yan yana okunduğunda ortaya çıkan tablo şu: yatırım yapıyoruz, ama yatırımın yöneldiği yer derin yapısal sorunları çözmek yerine yüzeyde çözüm üretiyor.
Türkiye’nin 19 Mart 2026’da yürürlüğe girmesi gereken alt düzenlemeleri henüz yayımlanmamışken, bu tablo yerel olarak nasıl tezahür ediyor? Avrupa’nın yatırım sapması Türkiye için de geçerli mi, yoksa BTK rejiminin yapısal eksikleri Türkiye’yi daha şiddetli bir versiyona mı sürüklüyor? Yarınki yazımızda bu soruları KVKK içtihadı, BTK Yönetmeliği’nin paradigma yaşı, telekom sektörünün çoklu rejim çıkmazı ve Yargıtay’ın müterafik kusur yaklaşımı etrafında ele alacağız.
Bugün acil olan, refleksin kurulması. Yarın konuşacağımız, bu refleksin yapısal hâle gelmesi için neyin değişmesi gerektiği.
Kavram Sözlüğü
cPanel & WHM: Web hosting hizmeti veren şirketlerin kullandığı kontrol paneli yazılımı. cPanel son kullanıcının web sitesini yönettiği arayüz; WHM (WebHost Manager) ise sunucu yöneticisinin tüm cPanel hesaplarını yönettiği üst düzey arayüz.
Linux çekirdeği (kernel): İşletim sisteminin merkezi yazılım parçası. Donanım ile uygulamalar arasındaki bağlantıyı yönetir. Sunucu dünyasının büyük bölümü Linux temelli işletim sistemleri üzerinde çalışıyor.
CVE (Common Vulnerabilities and Exposures): Ortak Zafiyet ve Maruziyet Kayıt Numarası. Dünya genelinde kamuya açıklanmış güvenlik zafiyetlerinin uluslararası standart bir kimlik sistemi altında izlenmesini sağlayan kayıt sistemi. CVE numaraları MITRE Corporation tarafından atanır.
CVSS (Common Vulnerability Scoring System): Bir güvenlik zafiyetinin önem derecesini sayısal olarak ölçen standart skorlama sistemi. 0 ile 10 arasında bir puan verir; 9.0 ve üstü “kritik” seviye olarak sınıflandırılır.
Root: Linux/Unix sistemlerde sınırsız yetkilere sahip yönetici kullanıcı. Bir saldırganın root yetkisine ulaşması, o sistem üzerinde tam kontrol elde etmesi anlamına gelir.
Authentication bypass (kimlik doğrulama atlatma): Sistemin geçerli kullanıcı adı ve şifreyi sormasına rağmen, saldırganın bu kontrol mekanizmasını teknik bir zaaf üzerinden devre dışı bırakarak doğrulanmış kullanıcı gibi sisteme girmesi.
Session file (oturum dosyası): Bir kullanıcı bir sisteme giriş yaptığında, sistemin o kullanıcının oturumunu hatırlamak için diskte tuttuğu geçici dosya. Saldırgan bu dosyayı manipüle edebilirse, geçerli kullanıcı gibi davranabilir.
Privilege escalation (yetki yükseltme): Bir saldırganın, sınırlı yetkili bir kullanıcı hesabıyla erişim sağladıktan sonra, sistem üzerindeki yetkilerini yönetici (root) seviyesine yükseltmesi.
Zero-day (sıfırıncı gün): Yazılım üreticisinin henüz keşfetmediği veya yamasını yayımlamadığı bir güvenlik açığı. Bu açıklar açıklanmadan önce hedefli saldırılarda kullanıldığında “zero-day exploit” denir.
Defense in depth (savunmada derinlik): Tek bir güvenlik kontrolüne bağımlı kalmama prensibi. Sistemde birden fazla güvenlik katmanı olur — bir katman aşılırsa diğeri durdurur.
Vendor lock-in (tek tedarikçiye bağımlılık): Bir kurumun ürün, hizmet veya teknoloji tercihinde tek bir tedarikçiye bağımlı hâle gelmesi ve farklı bir tedarikçiye geçişin teknik veya ekonomik olarak imkânsız hâle gelmesi durumu.
MFA (Multi-Factor Authentication, çok faktörlü kimlik doğrulama): Kullanıcının kimliğini doğrularken birden fazla bağımsız doğrulama unsurunun kullanılması. KVKK Kurulu’nun 2024/1385 sayılı Kararı’nda MFA eksikliği açıkça mimari kusur olarak nitelendirilmişti.
IOC (Indicator of Compromise, güvenlik ihlali göstergesi): Bir sistemin saldırıya uğradığını veya uğramakta olduğunu gösteren teknik izler. Şüpheli IP adresleri, anormal log girişleri, beklenmeyen dosya değişiklikleri — hepsi IOC kategorisindedir.
Patch (yama): Bir yazılımdaki güvenlik açığını veya hatayı düzeltmek üzere üreticinin yayımladığı güncelleme. Yama uygulandıktan sonra sistem yeni saldırılara karşı korunur ama yama öncesi gerçekleşmiş istismarlara karşı geriye dönük etkili olmayabilir.
