DeepSeek Harness memungkinkan penyerang dalam sandbox menjalankan perintah arbitrer hanya dengan mengubah header HTTP Host menjadi 127.0.0.1, yang mendapatkan skor 9.4 pada skala CVSS. Celah ini menunjukkan bagaimana satu keputusan kepercayaan yang salah dapat mengubah batas perlindungan menjadi pintu belakang (backdoor) yang terbuka.

Bagaimana bug tersebut bisa lolos

Kode yang rentan berada dalam satu fungsi yang membaca header Host pada permintaan dan, jika nilainya sama dengan alamat loopback, memperlakukan permintaan tersebut seolah-olah berasal dari mesin lokal.

Penyerang yang dapat mengeksekusi kode di dalam sandbox tidak memerlukan payload yang canggih. Dengan mengirimkan satu permintaan HTTP dengan Host: 127.0.0.1, backend akan percaya bahwa panggilan tersebut berasal dari host itu sendiri dan melewati semua perintah keamanan, pemeriksaan rate-limit, serta langkah-langkah validasi perintah. Hasilnya: eksekusi perintah tanpa batasan tanpa memerlukan interaksi lebih lanjut.

Mengapa mempercayai header itu berbahaya

Header adalah string teks biasa yang disediakan oleh pemanggil. Baik bidang tersebut bernama Host, X-Forwarded-For, atau nama kustom lainnya, klien dapat mengaturnya ke nilai apa pun yang diinginkannya. Satu-satunya sumber kebenaran yang andal tentang dari mana koneksi benar-benar berasal adalah lapisan transport – alamat IP sumber soket yang dicatat oleh sistem operasi saat jabat tangan TCP (TCP handshake) selesai.

Ketika sebuah aplikasi memutuskan untuk mempercayai header tanpa mengonfirmasi bahwa proxy yang dikonfigurasi dengan benar telah menyuntikkannya, aplikasi tersebut memberikan kunci akses penuh kepada penyerang. Bug DeepSeek Harness adalah contoh klasik dari kesalahan ini.

Dampak dunia nyata: contoh shell.online

Proyek open-source shell.online, yang menawarkan terminal berbasis web, baru-baru ini mendokumentasikan jebakan yang sama. Proyek ini menggunakan flag konfigurasi bernama TRUST_PROXY:

  • TRUST_PROXY = 0 – aplikasi mengabaikan header X-Forwarded-For dan mengandalkan alamat jarak jauh (remote address) soket. Ini mencegah klien memalsukan alamat IP untuk menghindari pembatasan laju (rate limits) atau menyamar sebagai pengguna tepercaya.
  • TRUST_PROXY = 1 – aplikasi mempercayai header X-Forwarded-For sebagai identitas klien. Jika layanan tidak berada di belakang proxy nyata yang menyaring header ini, penyerang dapat menyertakan alamat IP baru pada setiap permintaan, yang secara efektif mereset pembatasan (throttling) per-IP.

Bug DeepSeek mencerminkan skenario ini: kode mempercayai Host seolah-olah proxy yang mengaturnya, padahal layanan tersebut dapat diakses secara langsung.

Apa yang perlu dilakukan pengembang sekarang

  1. Audit setiap tempat di mana Anda membaca header yang disediakan klien. Identifikasi header mana yang Anda anggap sebagai otoritas (misalnya, Host, X-Forwarded-For, X-Real-IP) dan verifikasi bahwa proxy tepercaya dijamin akan menulis ulang header tersebut sebelum mencapai aplikasi Anda.
  2. Hubungkan keputusan keamanan dengan alamat soket jika memungkinkan. Gunakan IP sumber yang disediakan OS untuk autentikasi, pembatasan laju (rate-limiting), dan pemeriksaan kontrol akses.
  3. Aktifkan flag kepercayaan proxy hanya jika reverse proxy yang dikonfigurasi dengan benar berada di depan layanan. Jika Anda menjalankan aplikasi secara langsung, biarkan flag tersebut dinonaktifkan.
  4. Dokumentasikan topologi deployment yang diperlukan dalam README atau panduan deployment proyek Anda, sehingga pengguna yang melakukan self-host mengetahui persyaratan kepercayaan proxy tersebut.
  5. Jalankan alat analisis statis atau peninjauan kode yang menandai penggunaan langsung header untuk keputusan keamanan tanpa logika validasi proxy yang menyertainya.

Apa yang perlu diperhatikan selanjutnya

Komunitas yang merilis layanan web self-hosted kemungkinan besar akan meninjau kembali pengaturan kepercayaan proxy mereka sendiri setelah insiden ini.

Pelajaran utamanya sangat jelas: jangan pernah membiarkan potongan teks yang dapat ditulis oleh siapa pun di internet mendikte postur keamanan sistem Anda. Percayalah pada lapisan jaringan (network layer), bukan lapisan permintaan (request layer).