CVE-2026-85180 yang baru saja diungkapkan memungkinkan penyerang tanpa autentikasi mengeksploitasi model-puller Ollama untuk meluncurkan serangan server-side request forgery (SSRF) terhadap layanan internal, termasuk endpoint metadata cloud. Celah ini masih ada pada rilis saat ini, versi 0.33.2, dan dapat dipicu tanpa akun Ollama yang valid.

Mengapa kerentanan ini penting

Banyak tim menjalankan server Ollama internal untuk menyediakan model LLM kepada pengembang dan pipeline CI. API yang mengirimkan model sering kali dibiarkan terbuka sehingga pengguna mana pun di jaringan internal dapat meminta model berdasarkan namanya. Kemudahan tersebut menciptakan jalur langsung dari API yang menghadap ke publik ke dalam jaringan pribadi. CVE-2026-85180 mengubah jalur tersebut menjadi senjata.

Penyerang yang menghosting registry model berbahaya dapat membuat manifest yang mengalihkan permintaan unduhan ke alamat mana pun yang dapat dijangkau oleh proses Ollama. Saat API pull menerima manifest tersebut, ia akan mengikuti pengalihan secara otomatis. Karena endpoint pull tidak memerlukan autentikasi, penyerang tidak memerlukan akun Ollama. Pengalihan tersebut dapat mengarah ke loopback, link-local, atau subnet pribadi mana pun, memberikan pijakan bagi penyerang di dalam VPC cloud atau jaringan on-premise korban.

Target yang paling berbahaya adalah layanan metadata cloud (biasanya 169.254.169.254). Endpoint tersebut memberikan kredensial sementara ke instance.

Bagaimana bug ini lolos dari perbaikan sebelumnya

Awal tahun ini, Ollama menambal masalah pengalihan yang diidentifikasi sebagai CVE-2026-5530. Perbaikan tersebut menambahkan pemeriksaan yang memblokir pengalihan ke alamat pribadi, tetapi hanya diterapkan pada komponen downloader utama. Tensor model downloader, yang menangani kelas file model yang berbeda, menggunakan pustaka HTTP client terpisah. Pustaka tersebut memproses pengalihan secara manual dan tidak memiliki validasi terhadap tujuan baru. Akibatnya, mekanisme perlindungan lama tidak pernah berjalan untuk unduhan tersebut, sehingga vektor SSRF tetap terbuka.

Siapa yang berisiko rugi

Perusahaan yang mengekspos endpoint Ollama ke banyak pengembang menghadapi risiko tertinggi. Beban kerja cloud-native yang mengandalkan kredensial berbasis metadata sangat rentan.

Apa yang dapat dilakukan sekarang

Patch belum dirilis, dan kerentanan ini masih ada pada versi 0.33.2. Hingga perbaikan resmi tersedia, operator harus memperkuat lapisan jaringan di sekitar proses Ollama.

  • Hentikan referensi model sembarangan. Batasi API sehingga hanya pengguna atau layanan tepercaya yang dapat mengirimkan nama model. Tolak URL registry yang tidak dikenal atau yang diberikan oleh pengguna.
  • Kunci lalu lintas keluar (outbound). Pada tingkat kontainer, host, atau firewall, blokir koneksi ke loopback, link-local, dan rentang IP pribadi dari proses Ollama. Tolak akses ke alamat metadata cloud (169.254.169.254) secara eksplisit kecuali beban kerja benar-benar membutuhkannya.
  • Gunakan registry yang dikurasi. Host registry model internal yang hanya melayani manifest yang telah diverifikasi. Terapkan daftar izin (allow-list) hostname dan tolak pengalihan apa pun yang mengarah ke tempat lain.
  • Pantau pull yang mencurigakan. Pindai log Ollama untuk permintaan pull yang segera menghasilkan lalu lintas jaringan ke alamat internal. Korelasikan dengan telemetri jaringan untuk mendeteksi koneksi keluar yang tidak terduga.

Apa yang perlu diperhatikan selanjutnya

Pantau catatan rilis dan advisori keamanan proyek untuk patch mendatang. Sementara itu, perlakukan model-puller sebagai layanan yang memiliki kemampuan jaringan dan terapkan empat mitigasi tersebut segera.

Kesimpulan: Celah SSRF tanpa autentikasi pada model downloader Ollama dapat mengekspos kredensial cloud dan API internal; hingga patch tersedia, blokir akses keluar ke jaringan pribadi, batasi referensi model, dan pantau aktivitas pull.