Dua Celah Kritis TLS dan DNS Node.js Terungkap: CVE-2026-105482 dan CVE-2026-105483 Ancam Keamanan Koneksi

Eksploitasi membutuhkan kondisi spesifik terkait representasi alamat IP, sertifikat yang disajikan, dan kendali penyerang terhadap endpoint atau jalur komunikasi.

Perbedaan CVE-2026-105482 dan CVE-2026-105483

Walaupun sama-sama berkaitan dengan hostname, kedua kerentanan memiliki mekanisme berbeda.

Perbedaan tersebut penting karena mitigasi pada tingkat aplikasi juga tidak sepenuhnya sama.

Untuk kerentanan DNS, perhatian utama berada pada validasi input dan tujuan resolusi.

Sementara itu, untuk kerentanan TLS, perhatian utama berada pada normalisasi hostname dan penerapan pemeriksaan sertifikat yang benar.

Versi Node.js yang Terdampak dan Telah Diperbaiki

Pada 21 Oktober 2026, proyek Node.js merilis pembaruan keamanan untuk tiga cabang yang didukung.

CVE-2026-105482 memengaruhi ketiga cabang tersebut sebelum pembaruan.

Sementara itu, CVE-2026-105483 memengaruhi cabang 24.x dan 26.x sebelum pembaruan.

Pengguna disarankan menggunakan versi keamanan terbaru pada cabang Node.js yang masih didukung.

Versi Node.js yang telah mencapai End-of-Life tidak lagi menerima pembaruan keamanan reguler dan sebaiknya dimigrasikan ke cabang yang masih didukung.

Cara Memeriksa Versi Node.js

Pengembang dapat memeriksa versi Node.js menggunakan terminal.

node --version

Contoh hasil:

v24.22.0

Apabila sistem menggunakan versi yang lebih lama daripada versi perbaikan pada cabang terkait, pengembang perlu melakukan pembaruan.

Untuk melihat lokasi binary Node.js yang digunakan:

which node

Pada sistem yang menggunakan nvm, daftar versi Node.js dapat diperiksa menggunakan:

nvm ls

Pemeriksaan perlu dilakukan pada seluruh lingkungan yang menjalankan aplikasi, termasuk server produksi, container, dan pipeline CI/CD.

Cara Mengatasi Kerentanan TLS dan DNS Node.js

1. Perbarui Node.js ke Versi yang Telah Diperbaiki

Langkah utama adalah memasang pembaruan keamanan resmi.

Jika menggunakan nvm dan ingin tetap pada cabang 24.x:

nvm install 24.22.1
nvm use 24.22.1

Untuk cabang 22.x:

nvm install 22.23.4
nvm use 22.23.4

Untuk cabang 26.x:

nvm install 26.12.1
nvm use 26.12.1

Setelah pembaruan, periksa kembali versi runtime:

node --version

Pastikan aplikasi telah diuji sebelum perubahan diterapkan secara menyeluruh pada lingkungan produksi.

2. Tolak Hostname yang Mengandung Null Byte

Aplikasi yang menerima hostname dari pengguna perlu menolak karakter NUL.

Contoh:

function validateHostname(hostname) {
  if (typeof hostname !== "string") {
    return false;
  }

  if (hostname.includes("\0")) {
    return false;
  }

  return true;
}

Pemeriksaan ini membantu mengurangi risiko ketidaksesuaian interpretasi string antara JavaScript dan pustaka native.

Namun, validasi tersebut hanya merupakan salah satu lapisan perlindungan.

3. Gunakan Normalisasi dan Validasi Hostname yang Konsisten

Aplikasi perlu memastikan hostname yang divalidasi merupakan identitas yang sama dengan hostname yang digunakan untuk membangun koneksi.

Hindari penggunaan beberapa metode normalisasi yang berbeda tanpa pemeriksaan konsistensi.

Untuk koneksi yang menerima tujuan dari pengguna, gunakan parser URL yang sesuai dan terapkan aturan validasi yang ketat.

4. Jangan Menonaktifkan Verifikasi Sertifikat TLS

Salah satu kesalahan konfigurasi yang berbahaya adalah menonaktifkan pemeriksaan sertifikat.

Contoh konfigurasi yang tidak aman:

import https from "node:https";

const agent = new https.Agent({
  rejectUnauthorized: false,
});

Penggunaan rejectUnauthorized: false menonaktifkan verifikasi sertifikat TLS pada koneksi yang menggunakan agent tersebut.

Konfigurasi seperti ini tidak boleh digunakan sebagai solusi terhadap CVE-2026-105483.

Perbaikan yang benar adalah memperbarui runtime dan mempertahankan mekanisme verifikasi sertifikat.

5. Terapkan Domain Allowlist yang Ketat

Jika aplikasi hanya diperbolehkan mengakses domain tertentu, gunakan pemeriksaan identitas hostname yang tepat.

Hindari validasi sederhana yang hanya mengandalkan pencocokan akhiran string tanpa mempertimbangkan batas label domain.

Sebagai contoh, pemeriksaan berikut tidak cukup untuk kebijakan keamanan yang ketat:

hostname.endsWith("example.com");

Karena string seperti notexample.com juga dapat memenuhi kondisi tersebut.

Gunakan pencocokan domain yang memperhatikan batas label:

function isAllowedDomain(hostname) {
  const allowed = "example.com";

  return (
    hostname === allowed ||
    hostname.endsWith(`.${allowed}`)
  );
}

Contoh tersebut merupakan ilustrasi pemeriksaan batas label, bukan implementasi allowlist lengkap.

Dalam aplikasi produksi, lakukan normalisasi hostname secara konsisten, tolak karakter yang tidak valid, dan verifikasi alamat tujuan setelah resolusi DNS.

6. Batasi Akses Jaringan dari Server

Pembatasan koneksi keluar dapat membantu mengurangi dampak apabila aplikasi memproses hostname yang tidak tepercaya.

Pada sistem yang menangani URL dari pengguna, pertimbangkan penerapan egress filtering dan pembatasan akses ke jaringan internal.

Langkah ini penting untuk mengurangi risiko SSRF dan koneksi ke tujuan yang tidak diizinkan.

7. Lakukan Pengujian Setelah Pembaruan

Setelah memperbarui Node.js, lakukan pengujian terhadap fitur yang menggunakan DNS dan TLS.

Pengujian dapat mencakup:

• Koneksi HTTPS ke layanan eksternal.

• Resolusi domain.

• Koneksi database menggunakan TLS.

• Integrasi API pihak ketiga.

• Validasi sertifikat.

• Penanganan hostname tidak valid.

• Pemeriksaan koneksi jaringan internal.

Pengujian tersebut membantu memastikan pembaruan tidak mengganggu fungsi aplikasi.

Apakah Aplikasi Next.js dan Framework Lain Terdampak?

Node.js merupakan runtime yang digunakan oleh banyak framework JavaScript, termasuk Next.js, Express, NestJS, dan berbagai aplikasi backend.

Namun, penggunaan framework tersebut tidak otomatis membuat aplikasi dapat dieksploitasi melalui kedua CVE ini.

Risiko bergantung pada versi Node.js, penggunaan API yang terdampak, dan apakah aplikasi memproses input atau tujuan koneksi yang dapat dikendalikan penyerang.

Sebagai contoh, aplikasi yang menggunakan dns.resolve() terhadap hostname dari pengguna dapat memiliki permukaan serangan yang berbeda dibandingkan aplikasi yang hanya menggunakan domain statis yang telah ditentukan.

Demikian pula, aplikasi yang menggunakan koneksi TLS dengan representasi alamat IP tertentu memiliki kondisi risiko yang berbeda dibandingkan aplikasi yang menggunakan hostname DNS biasa.

Karena itu, pemeriksaan keamanan perlu dilakukan berdasarkan arsitektur dan perilaku aplikasi, bukan hanya framework yang digunakan.

Mengapa Pembaruan Runtime Lebih Penting daripada npm audit?

Kedua kerentanan ini berada pada komponen Node.js itu sendiri.

Artinya, pemeriksaan dependensi npm tidak selalu dapat mendeteksi apakah runtime yang digunakan telah mendapatkan perbaikan.

Perintah:

npm audit

bermanfaat untuk memeriksa kerentanan dependensi npm.

Namun, perintah tersebut bukan pengganti pemeriksaan versi runtime Node.js.

Pengembang perlu memeriksa versi Node.js secara terpisah, termasuk pada container image dan server produksi.

Selain itu, pembaruan package JavaScript tidak otomatis memperbaiki kerentanan pada runtime yang digunakan untuk menjalankan aplikasi.

Rekomendasi Keamanan untuk Lingkungan Produksi

Untuk mengurangi risiko kerentanan serupa, pengembang dan administrator sistem sebaiknya menerapkan beberapa langkah keamanan.

Pertama, gunakan cabang Node.js yang masih mendapatkan dukungan keamanan.

Kedua, lakukan pembaruan runtime secara berkala dan pantau pengumuman resmi Node.js.

Ketiga, terapkan validasi hostname yang ketat sebelum melakukan resolusi DNS atau membangun koneksi jaringan.

Keempat, jangan menonaktifkan verifikasi sertifikat TLS untuk mengatasi masalah koneksi.

Kelima, batasi akses jaringan keluar dari aplikasi sesuai kebutuhan.

Keenam, lakukan monitoring terhadap koneksi yang tidak biasa dan kegagalan verifikasi sertifikat.

Ketujuh, pastikan seluruh lingkungan pengembangan, pengujian, dan produksi menggunakan versi runtime yang telah diperiksa.

Pendekatan keamanan berlapis tersebut membantu mengurangi dampak apabila kelemahan serupa ditemukan kembali.

Kesimpulan

Dua kerentanan CVE-2026-105482 dan CVE-2026-105483 menunjukkan bahwa proses dasar komunikasi jaringan seperti resolusi DNS dan verifikasi sertifikat TLS tetap membutuhkan perhatian keamanan.

CVE-2026-105482 memungkinkan hostname yang mengandung karakter NUL diproses secara tidak konsisten, sehingga aplikasi berpotensi melakukan resolusi terhadap domain yang berbeda dari domain yang telah divalidasi.

Sementara itu, CVE-2026-105483 memungkinkan bypass verifikasi identitas sertifikat TLS dalam kondisi tertentu ketika alamat IPv4 direpresentasikan menggunakan karakter Unicode fullwidth.

Kedua kerentanan tersebut diklasifikasikan sebagai High oleh proyek Node.js dan telah mendapatkan perbaikan melalui pembaruan keamanan tanggal 21 Oktober 2026.

Pengguna Node.js disarankan memperbarui runtime ke versi 22.23.4, 24.22.1, atau 26.12.1 sesuai cabang yang digunakan, atau versi lebih baru yang telah mendapatkan perbaikan terkait.

Selain melakukan pembaruan, pengembang perlu memastikan bahwa validasi hostname, resolusi DNS, dan pemeriksaan sertifikat TLS diterapkan secara konsisten.

Keamanan komunikasi jaringan tidak hanya bergantung pada penggunaan HTTPS, tetapi juga pada ketepatan aplikasi dalam menentukan dan memverifikasi identitas server yang dihubungi.

---