Claude Code menemukan kerentanan Linux yang tersembunyi selama 23 tahun

• Claude Code dari Anthropic secara otomatis mendeteksi kerentanan yang dapat dieksploitasi dari jarak jauh di kernel Linux, dan menemukan heap buffer overflow pada driver NFS yang tidak terdeteksi selama 23 tahun
• Hanya dengan prompt sederhana, “di mana letak kerentanan keamanannya?”, ia menganalisis seluruh kernel dan mengidentifikasi kerentanan hampir tanpa pengawasan
• Bug tersebut berasal dari desain buffer tetap 112 byte pada kode kernel tahun 2003, lalu muncul ketika operasi LOCK ditambahkan dan batas panjang owner ID tidak diperhitungkan
• Carlini juga menemukan ratusan potensi kerentanan kernel lainnya, tetapi sebagian besar masih belum dilaporkan karena bottleneck pada verifikasi manusia
• Model Claude Opus 4.6 terbaru menunjukkan kemampuan deteksi yang jauh lebih tinggi dibanding versi sebelumnya, dan dinilai sebagai titik balik riset keamanan berbasis AI

---

Claude Code menemukan kerentanan Linux yang tersembunyi selama 23 tahun

• Peneliti Anthropic Nicholas Carlini menemukan beberapa kerentanan kernel Linux yang dapat dieksploitasi dari jarak jauh menggunakan Claude Code
  • Salah satunya adalah kerentanan buffer overflow pada driver NFS (Network File System) yang tidak ditemukan selama 23 tahun
  • Carlini mengatakan bahwa ia “belum pernah menemukan kerentanan jenis ini sendiri,” dan mengungkapkan keterkejutannya atas performa Claude Code

• Cara Claude Code mendeteksi kerentanan

  • Claude Code mendeteksi kerentanan keamanan di kernel Linux hampir tanpa pengawasan
    • Carlini hanya memberi prompt, “di mana letak kerentanan keamanannya?”, lalu mengaturnya untuk menelusuri seluruh file sumber kernel
  • Skrip yang digunakan disusun agar Claude Code, untuk setiap file, mengasumsikan situasi CTF (kompetisi hacking) dan mencatat kerentanan paling serius ke /out/report.txt
    • Perintah find digunakan untuk menelusuri semua file, lalu Claude Code dijalankan berulang untuk tiap file agar mencari kerentanan
  • Sistem ini dirancang agar kerentanan yang sama tidak dilaporkan berulang, sehingga semua file kernel dianalisis secara terpisah

• Kerentanan NFS (Network File System)

  • Kerentanan utama yang ditemukan Claude Code adalah heap buffer overflow pada driver Linux NFS, yang memungkinkan penyerang membaca memori kernel melalui jaringan
  • Skenario serangan dilakukan terhadap satu server NFS oleh dua klien NFS yang bekerja sama (Client A, Client B)
    • Client A meminta dan mendapatkan persetujuan lock file dengan owner ID sepanjang 1024 byte
    • Setelah itu, saat Client B meminta lock pada file yang sama, server menolaknya dan membuat pesan respons
  • Masalahnya adalah buffer respons penolakan ini hanya berukuran 112 byte, sementara pesan sebenarnya mencapai total 1056 byte jika menyertakan owner ID
    • Akibatnya, kernel menulis 1056 byte ke buffer 112 byte, sehingga memori kernel tertimpa data yang dikendalikan penyerang
  • Saat melaporkan kerentanan ini, Claude Code juga secara otomatis membuat dan menyertakan diagram protokol ASCII

• Mengapa tidak ditemukan selama 23 tahun

  • Bug ini berasal dari kode yang dimasukkan ke kernel Linux pada Maret 2003
    • Saat itu, pesan commit menyatakan bahwa buffer tetap 112 byte bernama NFSD4_REPLAY_ISIZE sudah cukup untuk operasi NFSv4 seperti OPEN dan CLOSE
    • Setelah operasi LOCK ditambahkan, kerentanan muncul karena batas panjang owner ID tidak dipertimbangkan
  • Kode ini berasal dari perubahan sebelum Git diperkenalkan (2005), sehingga sekarang merupakan basis kode lama yang bahkan tidak bisa ditautkan langsung

• Ratusan kerentanan tambahan yang belum sempat dilaporkan

  • Carlini juga menemukan ratusan potensi kerentanan kernel Linux tambahan, tetapi sebagian besar masih belum dilaporkan karena bottleneck dalam proses verifikasi manusia
    • Ia menyebut, “karena saya tidak bisa mengirim hasil yang belum diverifikasi ke maintainer kernel, masih ada ratusan crash yang belum saya periksa.”
  • Hingga kini, kerentanan yang sudah diperbaiki atau dilaporkan langsung oleh Carlini tercatat ada 5
    • 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()

• Perkembangan deteksi kerentanan berbasis AI

  • Carlini menemukan kerentanan ini menggunakan Claude Opus 4.6 (dirilis 2 bulan kemudian)
    • Pada versi sebelumnya, Opus 4.1 (8 bulan lalu) dan Sonnet 4.5 (6 bulan lalu), hasil yang sama tidak bisa direproduksi
    • Model terbaru mampu mendeteksi jauh lebih banyak kerentanan
  • Ia memperkirakan bahwa “dalam beberapa bulan ke depan, baik peneliti maupun penyerang akan menyadari betapa kuatnya model AI semacam ini, dan gelombang penemuan kerentanan keamanan skala besar akan datang”

• Presentasi dan informasi lainnya

  • Konten ini dipresentasikan di [un]prompted AI security conference 2026
  • Kasus temuan Claude Code dinilai sebagai contoh bahwa AI dapat secara drastis meningkatkan produktivitas riset keamanan nyata

[m3op0w94]

Bagian penuh harapan: menemukan kerentanan Linux
Bagian penuh keputusasaan: penghapusan bounding di curl

[GN⁺]

Komentar Hacker News

• Tidak mengejutkan. Hanya saja, yang tidak disebutkan dalam artikel adalah bahwa Claude Code juga menemukan 1.000 bug false positive, dan butuh 3 bulan bagi para developer untuk menyaringnya

  • Sekarang tidak lagi bekerja seperti itu. LLM menyaring bug yang tidak bisa direproduksi sendiri di pipeline sekunder. Memverifikasi apakah itu benar-benar kerentanan yang bisa dipicu jauh lebih mudah daripada menemukannya, jadi hasil akhirnya hampir 100% hanya menyisakan bug nyata. Masih banyak orang yang menyangkal kemajuan LLM, tetapi sulit menyangkal kegunaannya
  • Penasaran sumbernya. Saya belum pernah melihat hal seperti itu. Dari pengalaman saya, tingkat false positive deteksi kerentanan pada Claude Opus 4.6 di bawah 20%
  • Alat analisis statis/dinamis juga selalu menemukan kerentanan. Sebagian besar proyek besar sudah punya backlog isu yang ditumpahkan oleh scanner. Masalahnya adalah memilah mana yang benar-benar berbahaya. Menarik bahwa Claude menemukan bug lama, tetapi hal seperti ini selalu terjadi saat scanner baru muncul
  • Artikelnya tidak menulis bahwa false positive-nya banyak. Justru disebutkan bahwa “masih ada terlalu banyak bug yang belum diverifikasi”
  • Pelajarannya bukan bahwa Claude Code tidak berguna, tetapi bahwa di tangan orang yang tepat, ini bisa menjadi alat yang sangat kuat

• Menempelkan banyak kode baru sekaligus lalu bertanya ke Claude, “Apa yang saya lewatkan? Di mana bug-nya?” adalah pendekatan yang sangat meyakinkan bagi developer yang baru mulai memakai AI. Terutama karena ia cepat menemukan bug threading atau bug sistem terdistribusi. Mungkin sekarang banyak kode kripto sedang dianalisis dengan cara ini

  • Saya suka membiasakan prompt agar Claude berasumsi bahwa “ada bug”. Menanyakan “Ada bug di kode ini. Bisa kamu temukan?” atau menambahkan “bug-nya tidak mencolok” memberi saya tingkat keberhasilan yang lebih tinggi
  • Saya juga hampir memakai CC/codex seperti ini
  • Saya memakainya dengan cara seperti bertanya, “Ini kode yang ditulis Codex, ada yang terlihat aneh?”

• Lebih tepat disebut bug yang “tidak pernah diperiksa” daripada bug yang “tersembunyi”. Struktur kodenya menulis 1056 byte ke buffer 112 byte. Ini masalah yang mudah ditangkap dengan analisis statis, tetapi jika Anda meminta LLM untuk “periksa semua buffer berukuran tetap”, hasil halusinasi juga bisa ikut muncul. Meski begitu, ini tetap titik awal yang bagus

  • Sebagian besar kerentanan tetap ada karena “tidak ada yang memeriksanya”. Kompleksitas sistem terus menumpuk sehingga sulit diikuti manusia. Jika ini bisa menyelesaikan masalah tersebut, itu kabar besar. Alat analisis statis memang melaporkan semua jalur penyalinan buffer yang mungkin, tetapi dalam banyak kasus input sebenarnya dibatasi, sehingga kurang cocok di kernel Linux
  • Sebenarnya “tidak ada yang memeriksanya” terjadi karena kekurangan tenaga. Orang dan waktu untuk mencari kerentanan open source sangat terbatas. Namun sekarang model sudah cukup mumpuni, batas itu mulai runtuh. Tahun ini sepertinya akan sangat menarik
  • Katanya alat analisis statis bisa menemukannya dengan mudah, tetapi kenyataannya tidak ada yang menemukannya selama lebih dari 20 tahun. Lucu juga, setiap kali LLM melakukan sesuatu yang keren, selalu ada reaksi “ah, itu bukan hal besar”

• Menariknya, dari 5 bug yang ditemukan, 3~4 kemungkinan sudah akan dimitigasi oleh patch linux-hardened. Misalnya menonaktifkan io_uring, kernel crash saat UAF, pencegahan eksploit heap overflow, dan sebagainya

• Lucu melihat pengumuman model “kami merilis senjata berbahaya, jadi bantulah membuat dunia lebih aman. Tapi bayar biaya langganan dulu.” Rasanya seperti ahli biokimia melepaskan bom kimia lalu berkata, “kalau mau menghentikannya, bayar dulu.” Industri software akhir-akhir ini benar-benar ironis

  • Itu tidak masuk akal. Menyamakan pencarian dan pelaporan kerentanan dengan penyebaran senjata biokimia itu berlebihan sekali

• Saya mereproduksi eksperimennya di beberapa codebase production, dan ada banyak duplikasi, false positive, dan bug yang tidak bisa dieksploitasi. Meski begitu, tetap ada cukup banyak kerentanan kritis (crit) yang nyata

• Saya penasaran dengan video yang diputar di latar saat sesi tanya jawab presentasi. Apakah itu demo exploit yang memanfaatkan bug NFS lewat jaringan USB?

• Ini pekerjaan terkait dari lab keamanan kami. Tahun ini saja kami menemukan 23 kerentanan dengan agen keamanan AI

  • Laporan Security Lab
  • Panduan menjalankan Taskflow

• Lembaga tiga huruf (intelijen) tampaknya akan mengalami penurunan tajam dalam stok 0-day mereka

• Jangan berharap akan ada lebih banyak laporan kerentanan ke depan; yang harus diantisipasi adalah lebih banyak upaya serangan