90 günlük açıklama politikası öldü

• 90 günlük sorumlu açıklama, LLM’lerle birlikte keşif ve exploit geliştirme hızının artması nedeniyle koruyucu etkisini yitirdi
• 6 hafta içinde 11 kişi aynı kritik ödeme doğrulama hatasını bildirerek eşzamanlı yeniden keşif olgusunu ortaya koydu
• React yama diff’i, yapay zeka desteğiyle yalnızca 30 dakikada çalışan bir exploit’e dönüştürüldü
• Copy Fail ve Dirty Frag, herkese açık PoC’lerden gerçek saldırılara uzanarak embargo modelini çökertti
• Kritik sorunlar P0 olarak anında ele alınmalı ve LLM’ler güvenlik hattına dahil edilmeli

---

90 günlük sorumlu açıklama modelinin neden çöktüğü

• 90 günlük sorumlu açıklama süresi, hata bulanların nadir olduğu ve exploit geliştirmenin yavaş ilerlediği bir ortam varsayımıyla oluşturuldu
• Son 12 ayda güvenlik ekiplerinin, saldırganların ve araştırmacıların kullandığı araçlar benzer hızda daha akıllı hale geldi; değerlendirmeye göre LLM’ler, zafiyet keşfi ve exploit geliştirme süresini neredeyse sıfıra indirdi
• 2019 tipi modelde, Google Project Zero yaklaşımında olduğu gibi üreticiye 90 gün veriliyor ve bu süre boyunca şu varsayımlar geçerli sayılıyordu
  • Aynı hatayı bulan kişi sayısı çok az olur
  • Başkaları bulsa bile zaman alır
  • Üretici yama hazırlamak için yeterli ön zamana sahip olur
  • Yama yayımlandıktan sonra saldırganların tersine mühendislikle çalışan bir exploit üretmesi günler ya da haftalar sürer
• Bu varsayımların tamamı yanlış çıktı ve 90 günlük pencere, kullanıcıları korumaktan çok hatayı zaten bilenlere 90 günlük bir avantaj süresi sağlayan bir yapıya dönüştü

Vaka 1: 6 hafta içinde 11 kişi aynı kritik hatayı bildirdi

• Nisan sonlarında bir şirkete ciddi bir hata raporlandı, ancak triyaj ekibi bunun mart ayında ilk kez bildirildiğini ve kendisinin 11. raporlayan kişi olduğunu söyledi
• Hatanın yapısı şuydu: Bir kullanıcı siteden ürün satın aldıktan sonra saldırganın elle değiştirdiği bir yanıt sunucuya geri gönderilebiliyor, fakat yanıta ilişkin imza doğrulaması olmadığı için sunucu bunu olduğu gibi kabul ediyordu
  • Örneğin 5.000 dolarlık bir ürünü 0 dolara almak ya da gerçek ödeme yapmadan satın almayı tamamlanmış göstermek mümkündü
• Yaklaşık 6 hafta içinde birbirinden farklı 11 kişinin aynı kritik hatayı bulmuş olması, LLM destekli araştırmacıların neredeyse aynı anda aynı tür zafiyetlere yöneldiğini gösterdi
• BlueWater CTF çevresinden bir tanıdık, birkaç aydır birbiriyle ilgisiz raporlayıcıların ve iş akışlarının LLM desteğiyle aynı hatalarda birleştiğini gözlemlediğini söylemişti
• Triyaj tarafı da aynı olguyu gözlemliyor
  • @d0rsky, LLM istemleri, beceri ve otomasyon sayesinde yeni bir zafiyet bulunduğunda birkaç gün içinde aynı kök nedene dayanan yinelenen raporların akın ettiğini yazdı
  • Araştırmacılar bunu bu kadar hızlı tekrarlayabiliyorsa, yama çıkmadan önce black-hat aktörlerin de aynısını yapabileceği kaygısı büyüyor
• 10 kişi raporladıysa raporlamayan başkaları da olabilir ve aynı LLM’ler yalnızca iyi niyetli araştırmacılara değil herkese açık
• CVE kredisi ve bug bounty yalnızca 1 kişiye verilebildiği için kalan 9 kişi ya da baştan hiç raporlamayanlar 90 günlük sayaçla bağlı değil
• Bu durumda 90 günlük açıklama penceresi, kullanıcıları koruyan bir mekanizma olmaktan çıkıp hatayı zaten elinde tutanlara zaman kazandıran bir araca dönüşüyor

Vaka 2: React yamasından çalışan exploit’e 30 dakikada geçiş

• React, çeşitli güvenlik sorunlarını yamalayıp herkese açık bir blog yazısı yayımladı
  • CVE-2026-23870
  • CVE-2026-44575
  • CVE-2026-44579
  • CVE-2026-44574
  • CVE-2026-44578
• Yerel bir test uygulaması üzerinde yamayı okuyup çalışan bir exploit üretmek 30 dakika sürdü
• Açıklanan sorun hizmet reddi (DoS) türündeydi ve AI, diff’in anlaşılması, zafiyetli kod yolunun belirlenmesi ve PoC yazımının büyük bölümünü üstlendi
• Geçmişte herkese açık yamaları çalışan n-day exploit’lere dönüştürmek için yetkin bir tersine mühendis günler ya da haftalar harcar, bu zaman farkı da yöneticilere güncelleme yapabilmeleri için bir güvenlik tamponu sağlardı
• Artık basit hatalar dakikalar, karmaşık olanlar ise saatler ölçeğinde exploit’e dönüşebiliyor; yetkin bir tersine mühendis de artık zorunlu değil
• Yama çıkar çıkmaz exploit’in de var olduğunu varsaymak gerekiyor; bir sonraki bakım penceresine kadar dağıtımı ertelemek artık uygun değil

Vaka 3: Linux çekirdeğinde peş peşe patlayan Copy Fail ve Dirty Frag

• Son 2 hafta içinde Linux çekirdeğinde art arda iki kritik zafiyet ortaya çıktı; ikisinin de herkese açık exploit’i vardı ve büyük dağıtımları etkiliyordu

• Copy Fail

  • 29 Nisan’da Xint Code, Copy Fail çalışmasını yayımladı
  • Xint Code, Theori ekibinin arkasındaki takım olarak tanıtılıyor ve DEF CON CTF’i 9 kez kazandığı belirtiliyor
  • Copy Fail, CVE-2026-31431 olup çekirdeğin crypto alt sistemindeki doğrusal bir mantık kusuru olarak açıklanıyor
  • Yarış durumu olmadan %100 güvenilir olduğu ve 732 baytlık bir Python betiği ile 2017’den bu yana yayımlanan tüm Linux dağıtımlarında root yetkisi elde edilebildiği söyleniyor
  • Ubuntu, RHEL, Amazon Linux, SUSE gibi büyük dağıtımlar etkileniyor
  • AI kullanılarak çekirdeğin crypto/ alt sistemi yaklaşık 1 saat boyunca otomatik taranarak bulunduğu ve zafiyetin 9 yıldır açık olduğu belirtiliyor
  • Teknik analiz Xint’in yazısında yer alıyor
  • mainline commit’i a664bf3d603d ile yama yayımlandı; ayrıca algif_aead modülünü devre dışı bırakma azaltımı da vardı
  • Sonrasında İranlı saldırganların bu zafiyeti kullanarak Ubuntu sunucularını ele geçirip DDoS kampanyası düğümleri olarak yeniden kullandığına dair işaretler gözlemlendiği aktarıldı
  • AI ile bulunan çekirdek ayrıcalık yükseltme zafiyetinin herkese açık PoC’den devlet ölçekli saldırganların silahlandırmasına dönüşmesi yalnızca birkaç gün sürdü

• Dirty Frag

  • Yaklaşık 1 hafta sonra, 7 Mayıs’ta Hyunwoo Kim(@v4bel) Dirty Frag çalışmasını yayımladı
  • Dirty Frag, CVE-2026-43284 ile CVE-2026-43500’ın zincirlenmesiyle oluşan bir zafiyet
  • Çekirdeğin IPSec ESP (esp4/esp6) ve RxRPC ağ modüllerindeki iki zafiyeti bir araya getiriyor
  • Copy Fail ve Dirty Pipe gibi hata ailesine, aynı page-cache corruption tekniğine dayanıyor; ancak saldırı yolu farklı
  • Copy Fail azaltımı uygulanmış olsa bile Dirty Frag çalışıyor
    • algif_aead kara listeye alınsa bile Dirty Frag bu modülü kullanmıyor
  • Yetkisiz kullanıcıdan root’a deterministik biçimde yükselme sağladığı ve Ubuntu, RHEL 10.1, openSUSE, CentOS Stream, AlmaLinux, Fedora 44 gibi büyük dağıtımlarda çalıştığı söyleniyor
  • Derleme ve çalıştırma tek satırlık bir komutla yapılabiliyor

• Dirty Frag’in açıklama süreci ve ambargonun çöküşü

  • Hyunwoo Kim, 29-30 Nisan’da [email protected] adresine rapor gönderdi ve yamayı herkese açık şekilde sundu
  • 7 Mayıs’ta linux-distros e-posta listesiyle koordinasyon sağlandı ve 5 günlük bir ambargo üzerinde anlaşıldı
  • Aynı gün, birkaç saat içinde ilgisiz bir üçüncü taraf ESP zafiyetine ilişkin ayrıntılı exploit bilgisini yayımlayarak ambargoyu bozdu
  • Dağıtım bakımcılarıyla görüştükten sonra Hyunwoo, Dirty Frag’in tam analizini, exploit kodunu ve çalışan PoC’yi yayımladı
  • O anda yama sunabilen Linux dağıtımı sayısı sıfırdı
  • Mevcut durumda yalnızca CVE-2026-43284, yani ESP tarafı için mainline düzeltme bulunuyor; CVE-2026-43500, yani RxRPC bileşeni içinse henüz upstream yama yok
  • Ubuntu, Red Hat, Tenable gibi kurumlar kendi güvenlik duyurularını yayımladı

• Dirty Frag’in gerçek dünyada kötüye kullanımı

  • Microsoft Defender ekibi, açıklamadan 24 saat içinde sınırlı düzeyde gerçek kötüye kullanımı tespit etti
  • Saldırganların SSH erişimi elde ettiği, ELF ikili dosyaları dağıttığı, su ile root yetkisi aldığı, kimlik doğrulama ayarlarını değiştirdiği, oturum dosyalarını sildiği ve yatay hareket gerçekleştirdiği bildirildi
  • CTS(@gf_256) bunu “responsible disclosure is dead🤦” diye özetledi

Gerçekte ölen şeyler

• 90 günlük açıklama penceresi, düzeltilebilecek bir sorun değil; sona ermiş bir model
• Bu model, keşfedenlerin az ve exploit geliştirmenin yavaş olduğu bir dünyaya uygundu; ancak LLM’ler keşfeden sayısını artırıp exploit geliştirmeyi hızlandırıyor
• Birbirinden bağımsız 10 kişi 6 hafta içinde aynı hatayı bulabiliyor ve AI bir patch diff’ini 30 dakikada çalışan exploit’e dönüştürebiliyorsa, 90 günlük pencere kimseyi koruyamıyor
• Copy Fail, AI taramasından herkese açık PoC’ye ve devlet ölçekli saldırganların silahlandırmasına birkaç gün içinde uzandı
• Dirty Frag’de ise aynı hata ailesini bağımsız bulan üçüncü bir taraf nedeniyle ambargo birkaç saat içinde çöktü
• Aynı zafiyetin birden fazla araştırmacı ve AI aracı tarafından eşzamanlı, bağımsız biçimde yeniden keşfedildiği bir ortamda kontrollü açıklamayı sürdürmek zor
• Aylık yama döngüsü de sona erdi
  • Zafiyet ile düzeltme arasında 30 günlük pencere, saldırganların yayın takviminden daha yavaş hareket ettiği varsayımına dayanıyordu
  • Microsoft’un Dirty Frag’in gerçek kötüye kullanımını 24 saat içinde gördüğü bir ortamda aylık bakım penceresi güvenli bir tampon değil, saldırı penceresi haline geliyor
• Güvenlik duyurusunu bekleme yaklaşımı da sona erdi
  • Savunmacılar CVE açıklamasını okurken saldırganlar git log --diff-filter=M okuyor
  • Güvenlik duyuruları aşağı akış ürünleridir; asıl sinyal patch diff’idir

Sektörün değiştirmesi gereken yaklaşım

• Sonuç şu: tüm kritik güvenlik sorunları P0 kabul edilip anında düzeltilmeli
• “24 saat içinde”, “bir sonraki sprintte”, “etki değerlendirmesinden sonra” değil; yapılan iş bırakılıp hemen düzeltilecek seviyede ele alınmalı
• Üretim dağıtımının karmaşık olması ve değişiklik yönetimi gerektirmesi anlaşılır; ancak tehdit ortamı değişiklik yönetimi prosedürlerini beklemiyor

• Üreticiler

  • Kritik hata raporu geldiği anda saat işlemeye başlar
  • Esas alınacak an, triyajın bittiği ya da işin mühendisliğe geçtiği zaman değil; raporun ulaştığı andır
  • Biri raporladıysa 10 kişinin daha zaten bildiğini ve bunlardan en az 1’inin dostça niyet taşımadığını varsaymak gerekir

• Araştırmacılar

  • Kritik hataları uzun süre elde tutmamalı, mümkün olan en kısa açıklama penceresini zorlamalı
  • Bir üretici 1 hafta içinde düzeltemiyorsa bu bir açıklama sorunu değil, üretici sorunudur
  • Geçmişte “zaman tanımak” nezaket sayılabiliyordu çünkü tek keşfeden siz olabilirdiniz; artık büyük olasılıkla tek keşfeden siz değilsiniz

• Zafiyet yönetimi

  • Zafiyet yönetimi gerçek zamanlı olmalı
  • “Haftalık tarama, sprintte triyaj, döngüye göre yama” yaklaşımı, saldırganların çoktan geçtiği bir zaman çizelgesi
  • Kritik sorunlar için yeni azami yanıt süresi günler değil saatler; hatta bu bile yavaş kalabilir

Blue team neden LLM’leri savunma hattına koymalı?

• Saldırganlar LLM’leri exploit hattına zaten entegre etti; savunma tarafının da aynı hızda hareket etmesi gerekiyor
• Kod push anında LLM entegrasyonu gerekli
  • Tüm pull request, merge ve deploy süreçlerinde AI destekli güvenlik incelemesi CI hattının bir parçası olarak çalışmalı
  • Bu süreç, linter ve unit test gibi push anında çalışmalı; üç aylık denetim ya da sonradan yapılan inceleme olmamalı
  • Zafiyetler üretime ulaşmadan önce yakalanmalı; PR incelemesinde düzeltmenin maliyeti, CVE açıklandıktan sonra düzeltmeye göre çok daha düşüktür
• Yama analizi için de LLM entegrasyonu gerekli
  • Upstream bağımlılıklar güvenlik yaması yayımladığında, hat otomatik olarak diff’i çekmeli, değişiklikleri analiz etmeli, kendi kod tabanındaki etkiyi değerlendirmeli ve alarm üretmeli
  • Bir insanın e-posta listelerini okuyup Jira bileti açmasına dayanmak yerine, herkese açık depoya yama düştüğü anda bu işlemler dakikalar içinde otomatik yapılmalı
  • Xint Code Copy Fail’i 1 saatlik otomatik taramayla bulabildiyse, kurumlar kendi bağımlılıklarını da aynı şekilde taramalı
• Bağımlılık taramasında da LLM kullanılmalı
  • Tedarik zinciri, en zayıf geçişli bağımlılığı kadar güçlüdür
  • AI tabanlı bağımlılık tarayıcıları, zafiyet etkisini bağımlılık ağacı boyunca izleyebilir, etkilenen sürümleri işaretleyebilir ve yükseltme yolunu önerebilir
  • Bu haftalık değil, sürekli çalışan bir süreç olmalı
• Yama yayımlanmadan önce AI ile yama test edilmeli
  • React örneğinde LLM’ler 30 dakikada yamayı exploit’e çevirebiliyorsa, savunmacılar da aynı araçlarla bunu herkese açık olmadan önce doğrulamalı
  • Yamanın gerçekten sorunu çözüp çözmediği ve yeni sorunlar üretip üretmediği kontrol edilmeli
  • Regresyon testi üretmek ve aynı kalıbın kod tabanının başka yerlerinde bulunup bulunmadığını taramak için de kullanılmalı
• “Zafiyet mevcut” ile “zafiyet sömürülüyor” arasındaki pencere sıfıra yaklaşıyor; savunma tarafı da saldırı tarafıyla aynı hızda otomasyona geçmek zorunda
• Daha fazla zero-day daha hızlı şekilde gerçek ortamlarda kötüye kullanılacak; bunun nedeni aynı araçlar, düşen giriş bariyeri, artan keşfeden sayısı ve kısalan zaman çizelgeleri
• Bu geçişten sağ çıkan ekipler, zorla mecbur kalmadan önce AI’yi güvenlik hattının birinci sınıf bileşeni haline getirenler olacak

Sonuç

• Dirty Frag güvenlik duyurusunu okuyan bir sistem yöneticisinin; ortada yama yokken exploit’in zaten herkese açık olduğu, Microsoft’un gerçek kötüye kullanım gördüğü, azaltımın ise IPSec modülünü devre dışı bırakmak olduğu bir ortamda 400 sunucuya müdahale etmek zorunda kalması yeni normal haline geldi
• 90 günlük açıklama politikası, aylık yama döngüsü ve açıklama ile kötüye kullanım arasında zaman olduğu varsayımı artık öldü
• Geriye kalan tek şey; hızlı hareket etme, güçlü otomasyon kurma ve kritik hataları gerçek bir acil durum gibi ele alma yeteneği
• Eski modeli yıkan AI dalgası, aynı zamanda hızlı yama, otomatik tarama, gerçek zamanlı tehdit istihbaratı ve AI destekli kod incelemesi gibi yeni modeli de mümkün kılıyor
• Araçlar zaten mevcut; asıl mesele savunmacıların bunları saldırganlardan önce kullanıp kullanamayacağı ve şu anda bu yarışta saldırganlar önde

[GN⁺]

Lobste.rs görüşleri

• İstemeyerek de olsa katılmak zorundayım. Bizim şirkette de bu konuda araştırma yaptık ve patch'ten exploit'e geçen sürenin neredeyse anlık seviyede olduğunu gördük

• Sorumlu açıklama politikası en başından beri insanların karşılıklı nezaketen inanıyormuş gibi yaptığı bir kurguydu. Zaten baştan beri ortama uyup gidilen bir şeydi; LLM tabanlı zafiyet bulma araçları da sadece bunun gerçek yüzünü ortaya çıkardı

• Bu yazının kendisinin de LLM tarafından yazılmış gibi kokması oldukça ironik geliyor

  • Mantıklı. Özgün bir fikrin varsa, başkası yapmadan önce yayımlaman gerekir. Eleştirel düşünme ve öz değerlendirme öldü; aklına bir fikir geldikten sonra 39 dakika içinde bloga koymazsan bir başkası senden önce davranıyor :P
  • Bana öyle görünmüyor. Bu yazım tarzı LLM öncesi teknik yazılarda da uzun zamandır vardı ve büyük LLM'ler genelde bu yazıdan biraz farklı bir şekilde yazıyor
  • Korku pompalayan bir reklam gibi okunuyor
  • İyi ya da kötü, artık işlerin akışı galiba böyle

• Belki de ölen şey, görev açısından kritik durumlarda kullanılan el yapımı butik C programları çağıdır