Claude Code, 23 yıldır gizli kalan bir Linux açığını buldu

• Anthropic'in Claude Code'u, Linux çekirdeğinde uzaktan istismar edilebilen bir açığı otomatik olarak tespit ederek 23 yıldır fark edilmeyen NFS sürücüsündeki bir heap buffer overflow sorununu ortaya çıkardı
• Sadece “güvenlik açığı nerede?” şeklindeki bir prompt ile tüm çekirdeği analiz edip neredeyse hiç denetim olmadan açığı belirledi
• Söz konusu hata, 2003'te çekirdek kodundaki 112 baytlık sabit buffer tasarımından kaynaklandı; daha sonra LOCK işlemi eklenirken owner ID uzunluğu sınırı göz ardı edildi
• Carlini bunun dışında da yüzlerce olası çekirdek açığı buldu, ancak insan doğrulamasındaki darboğaz nedeniyle bunların çoğu hâlâ raporlanmadı
• En yeni Claude Opus 4.6 modeli, önceki sürümlere göre çok daha yüksek tespit yeteneği göstererek yapay zeka tabanlı güvenlik araştırmalarında bir dönüm noktası olarak değerlendirildi

---

Claude Code, 23 yıldır gizli kalan bir Linux açığını buldu

• Anthropic araştırmacısı Nicholas Carlini, Claude Code'u kullanarak Linux çekirdeğinde uzaktan istismar edilebilen birden fazla açık buldu
  • Bunlardan biri, 23 yıldır fark edilmeyen NFS (Network File System) sürücüsündeki bir buffer overflow açığıydı
  • Carlini, “Bu tür açıkları daha önce hiç kendim bulmamıştım” diyerek Claude Code'un performansı karşısındaki şaşkınlığını dile getirdi

• Claude Code'un açık tespit yöntemi

  • Claude Code, Linux çekirdeğindeki güvenlik açıklarını neredeyse hiç denetim olmadan tespit etti
    • Carlini, yalnızca “güvenlik açığı nerede?” şeklinde bir prompt verdi ve tüm çekirdek kaynak dosyalarını dolaşacak şekilde ayarladı
  • Kullanılan script, her dosya için CTF (hack yarışması) senaryosu varsayımıyla Claude Code'un en ciddi açığı /out/report.txt içine yazmasını sağlayacak şekilde kurgulandı
    • find komutuyla tüm dosyalar tarandı ve her dosya için Claude Code'un açık araması tekrar tekrar çalıştırıldı
  • Aynı açığın mükerrer raporlanmaması için sistem buna göre tasarlandı ve çekirdekteki tüm dosyalar tek tek analiz edildi

• NFS (Network File System) açığı

  • Claude Code'un bulduğu başlıca açık, Linux NFS sürücüsündeki bir heap buffer overflow olup saldırganın ağ üzerinden çekirdek belleğini okuyabilmesini sağlıyor
  • Saldırı senaryosu, iş birliği yapan iki NFS istemcisi (Client A, Client B) tarafından tek bir NFS sunucusuna karşı yürütülüyor
    • Client A, 1024 bayt uzunluğunda bir owner ID ile dosya kilidi talep ediyor ve onay alıyor
    • Ardından Client B aynı dosya için kilit istediğinde sunucu bunu reddediyor ve bir yanıt mesajı oluşturuyor
  • Sorun şu ki bu ret yanıtı buffer boyutu yalnızca 112 bayt, ancak gerçek mesaj owner ID dahil toplam 1056 bayta ulaşıyor
    • Sonuç olarak çekirdek, 1056 baytı 112 baytlık buffera yazarak saldırganın kontrol ettiği verilerle çekirdek belleğinin üzerine yazıyor
  • Claude Code, bu açığı raporlarken ASCII protokol diyagramı da otomatik üretip ekledi

• 23 yıl boyunca neden fark edilmedi?

  • Bu hata, Mart 2003'te Linux çekirdeğine eklenen koddan kaynaklanıyor
    • O dönemki commit mesajında NFSD4_REPLAY_ISIZE adlı 112 baytlık sabit bufferın OPEN, CLOSE gibi NFSv4 işlemleri için yeterli olduğu belirtiliyordu
    • Daha sonra LOCK işlemi eklendiğinde owner ID uzunluğu sınırı hesaba katılmadığı için açık ortaya çıktı
  • Bu kod, Git'in kullanılmaya başlanmasından (2005) önceki bir değişikliğe ait olduğundan bugün doğrudan bağlantı vermek bile mümkün olmayan eski bir kod tabanına dayanıyor

• Raporlanamamış yüzlerce ek açık

  • Carlini, yüzlerce olası Linux çekirdeği açığı daha buldu, ancak insan doğrulama sürecindeki darboğaz nedeniyle bunların çoğu henüz raporlanmadı
    • “Doğrulanmamış sonuçları çekirdek maintainer'larına gönderemediğimiz için, henüz kontrol edemediğim yüzlerce crash var” dedi
  • Şu ana kadar Carlini'nin doğrudan düzelttiği veya raporladığı açık sayısının 5 olduğu doğrulandı
    • nfsd: fix heap overflow in NFSv4.0 LOCK replay cache
    • io_uring/fdinfo: fix OOB read in SQE_MIXED wrap check
    • futex: Require sys_futex_requeue() to have identical flags
    • ksmbd: fix share_conf UAF in tree_conn disconnect
    • ksmbd: fix signededness bug in smb_direct_prepare_negotiation()

• Yapay zeka tabanlı açık tespitindeki ilerleme

  • Carlini bu açığı bulmak için Claude Opus 4.6'yı kullandı (yayınlanmasından 2 ay önce)
    • Önceki sürümler olan Opus 4.1 (8 ay önce) ve Sonnet 4.5 (6 ay önce) ile aynı sonuç yeniden üretilemedi
    • En yeni modelin çok daha fazla açık tespit edebildiği görüldü
  • Carlini, “Önümüzdeki birkaç ay içinde hem araştırmacılar hem de saldırganlar bu yapay zeka modellerinin gücünü fark ettikçe, büyük ölçekli güvenlik açığı keşiflerinde bir dalga gelecek” öngörüsünde bulundu

• Sunum ve diğer bilgiler

  • Bu içerik [un]prompted AI security conference 2026 etkinliğinde sunuldu
  • Claude Code'un bu bulgusu, yapay zekanın gerçek güvenlik araştırmalarındaki üretkenliği dramatik biçimde artırabildiğini gösteren bir örnek olarak değerlendiriliyor

[m3op0w94]

Umutlu versiyon: Linux güvenlik açığı bulundu
Umutsuz versiyon: curl'de bounding kaldırıldı

[GN⁺]

Hacker News yorumları

• Şaşırtıcı değil. Ancak haberde değinilmeyen nokta, Claude Code'un 1.000 tane yanlış pozitif hata da bulduğu ve geliştiricilerin bunları ayıklamasının 3 ay sürdüğü kısmı

  • Artık böyle çalışmıyor. LLM, kendi ikinci aşama pipeline'ında yeniden üretilemeyen hataları eliyor. Gerçekte tetiklenebilen bir açık olup olmadığını doğrulamak, bulmaktan çok daha kolay bir iş; bu yüzden neredeyse %100 doğrulukla yalnızca gerçek hatalar kalıyor. LLM'lerin ilerlemesini hâlâ inkâr eden çok kişi var ama faydasını inkâr etmek zor
  • Kaynağı merak ettim. Böyle bir şey görmedim. Benim deneyimimde Claude Opus 4.6'nın açık tespitindeki yanlış pozitif oranı %20'nin altındaydı
  • Statik/dinamik analiz araçları da her zaman açık bulur. Büyük projelerin çoğunda, tarayıcıların yığdığı bir issue backlog zaten var. Sorun, bunların içinden gerçekten tehlikeli olanları ayıklamak. Claude'un eski bir hatayı bulması ilginç ama yeni bir tarayıcı çıktığında hep böyle şeyler olur
  • Haberde yanlış pozitiflerin çok olduğundan söz edilmiyor. Aksine, “henüz doğrulayamadığımız çok fazla hata var” deniyor
  • Buradan çıkarılacak ders Claude Code işe yaramıyor değil; doğru kişinin elinde güçlü bir araç olduğudur

• Yeni kodu topluca yapıştırıp Claude'a “Neyi kaçırdım? Hata nerede?” diye sormak, AI'a yeni başlayan geliştiriciler için çok ikna edici bir yaklaşım. Özellikle threading ya da dağıtık sistem hatalarını hızlı buluyor. Muhtemelen şu sıralar kripto para kodları topluca analiz ediliyordur

  • Ben Claude'un “burada bir hata var” diye varsayması için prompt'u önyargılı hale getirmeyi seviyorum. “Bu kodda bir hata var. Bulabilir misin?” diye sormak ya da “Hata bariz değil” diye eklemek başarı oranını artırdı
  • Ben de CC/codex'i neredeyse tam olarak böyle kullanıyorum
  • “Bunu Codex yazdı, tuhaf görünen bir şey var mı?” diye soruyorum

• Buna “gizli” hata demektense “kimse bakmadı” demek daha doğru olur. Kodun yapısı, 112 baytlık bir arabelleğe 1056 bayt yazıyordu. Statik analiz aracıyla da kolayca yakalanabilecek bir sorun ama LLM'e “tüm sabit boyutlu buffer'ları kontrol et” derseniz halüsinasyon çıktıları da karışabilir. Yine de iyi bir başlangıç noktası

  • Çoğu açık, “kimse bakmadığı” için kalıyor. Sistem karmaşıklığı biriktikçe insanların takip etmesi zorlaşıyor. Eğer bu sorunu çözebiliyorsa büyük haber olur. Statik analiz araçları olası tüm arabellek kopyalama yollarını raporlar ama gerçek girdiler çoğu zaman sınırlıdır; bu yüzden Linux çekirdeğinde çok iyi çalışmaz
  • Aslında “kimse bakmadı” denmesinin sebebi insan gücü eksikliği. Açık kaynak açıklarını bulabilecek insan ve zaman sınırlıydı. Ama artık modeller yeterince yetkin hale geldikçe bu sınır kırılıyor. Bu yıl çok ilginç olacak gibi görünüyor
  • Statik analiz aracının kolayca bulabileceği söyleniyor ama gerçekte kimse 20 yılı aşkın süredir bulamamıştı. LLM bir şey başardığında hep “o kadar da önemli değil” tepkisinin gelmesi komik

• İlginç şekilde, bulunan 5 hatanın 3-4 tanesi linux-hardened patch ile hafifletilmiş olurdu. Örneğin io_uring'in devre dışı bırakılması, UAF durumunda kernel çökmesi, heap overflow istismarının engellenmesi gibi

• “Tehlikeli bir silahı kamuya açıklıyoruz, hadi dünyayı daha güvenli yapmamıza yardım edin. Ama önce abonelik ücreti ödeyin” tarzı duyuru komik. Sanki bir biyokimyacı kimyasal bomba salıp ardından “bunu durdurmak için para ödeyin” diyormuş gibi. Yazılım sektörü bugünlerde gerçekten ironik

  • Bu saçma. Açık bulup raporlamayı biyokimyasal silah yayma ile kıyaslamak aşırıya kaçıyor

• Birden fazla production kod tabanında deneyi yeniden yaptım; tekrar eden, yanlış pozitif ve istismar edilemeyen hatalar çoktu. Yine de epey sayıda gerçek kritik açık (crit) vardı

• Sunumdaki Soru-Cevap sırasında arkada oynatılan video dikkatimi çekti. USB ağ üzerinden NFS hatasını kullanan bir exploit demosu muydu?

• Bu, güvenlik laboratuvarımızın ilgili çalışması. AI güvenlik ajanlarıyla sadece bu yıl 23 açık bulduk

  • Security Lab raporu
  • Taskflow çalıştırma kılavuzu

• Üç harfli kurumların (istihbarat teşkilatları) 0-day stokları hızla azalacak gibi görünüyor

• Bundan sonra daha fazla açık raporu beklemeyin; daha fazla saldırı girişimi bekleyin