Cara memperbaiki kerentanan CVE-2025-1097, CVE-2025-1098, CVE-2025-1974, CVE-2025-24513, dan CVE-2025-24514 - Container Service for Kubernetes

Tingkat keparahan: KRITIS (CVSS 9,8) | Aksi yang diperlukan: Segera lakukan upgrade Beberapa kerentanan pada NGINX Ingress controller memungkinkan penyerang dengan akses jaringan pod untuk mengeksekusi kode arbitrer dan mengakses seluruh Secrets di seluruh kluster—tanpa kredensial atau hak istimewa administratif. Jika kluster ACK Anda menjalankan NGINX Ingress controller dengan admission webhook diaktifkan, perlakukan hal ini sebagai keadaan darurat dan segera ambil tindakan.

Apakah saya terdampak?

Gunakan Pohon keputusan berikut untuk menentukan apakah kluster Anda berisiko.

Langkah 1: Periksa apakah NGINX Ingress controller terinstal

kubectl get pods -n kube-system --selector app=ingress-nginx

Jika tidak ada pod yang dikembalikan, kluster Anda tidak memiliki NGINX Ingress controller yang terinstal dan tidak terdampak. Tidak diperlukan tindakan lebih lanjut.
Jika pod dikembalikan, lanjutkan ke Langkah 2.

Langkah 2: Periksa versi yang sedang berjalan

Versi NGINX Ingress controller yang terdampak:

Semua versi sebelum v1.11.5
v1.12.0

Jika kluster Anda menjalankan v1.11.5, v1.12.1, atau versi yang lebih baru, Anda sudah menggunakan rilis yang telah diperbaiki. Tidak diperlukan tindakan lebih lanjut.

Untuk mengetahui versi yang terinstal, lihat Cara memeriksa metode instalasi dan versi Anda.

Langkah 3: Periksa apakah admission webhook diaktifkan

Kluster dengan admission webhook yang dimatikan tidak terdampak oleh kerentanan paling kritis (CVE-2025-1974). Namun, kerentanan injeksi berbasis anotasi (CVE-2025-1097, CVE-2025-1098, CVE-2025-24514, CVE-2025-24513) tetap berlaku jika ada pengguna yang memiliki izin menulis resource Ingress. Anda tetap harus melakukan upgrade.

Instalasi melalui Add-ons: Jalankan perintah berikut. Jika resource tidak ditemukan, admission webhook dimatikan.
```
  kubectl get validatingwebhookconfigurations ingress-nginx-admission
```
Instalasi melalui Marketplace: Lihat informasi dasar aplikasi terkait dan periksa apakah ada resource bertipe ValidatingWebhookConfiguration.

Rangkuman

Kondisi	Tingkat risiko
NGINX Ingress controller tidak terinstal	Tidak terdampak
Terinstal, versi >= v1.11.5 (1.11.x) atau >= v1.12.1 (1.12.x)	Tidak terdampak (sudah diperbaiki)
Terinstal, versi terdampak, admission webhook dimatikan	Risiko berkurang (tetap lakukan upgrade)
Terinstal, versi terdampak, admission webhook diaktifkan	Terdampak — segera ambil tindakan

Cara memeriksa metode instalasi dan versi Anda

NGINX Ingress controller dapat diinstal di kluster ACK melalui dua cara: halaman Add-ons atau Marketplace (Helm chart). Langkah remediasi berbeda tergantung metode yang digunakan.

Diinstal melalui halaman Add-ons

Metode 1: Periksa di halaman Add-ons

Masuk ke Konsol ACK. Di panel navigasi kiri, klik Clusters.
Di halaman Clusters, temukan kluster yang ingin Anda kelola dan klik namanya. Di panel navigasi kiri, klik Add-ons.
Di halaman Add-ons, cari dan temukan Nginx Ingress Controller, lalu periksa pada kartu komponen apakah komponen tersebut terinstal dan versi saat ini.

Metode 2: Kueri menggunakan kubectl

kubectl get pods -n kube-system --selector app=ingress-nginx

Diinstal melalui Marketplace (Helm chart)

Masuk ke Konsol ACK. Di panel navigasi sebelah kiri, klik Clusters.
Di halaman Clusters, temukan kluster yang ingin Anda kelola dan klik namanya. Di panel navigasi kiri, pilih Applications > Helm.
Di daftar Helm, periksa apakah ack-ingress-nginx atau ack-ingress-nginx-v1 ada di kolom Chart Name, di mana Application Version adalah versi saat ini dari komponen NGINX Ingress controller.

Detail kerentanan

Komunitas Kubernetes telah mengungkap lima kerentanan keamanan pada NGINX Ingress controller. Empat di antaranya memungkinkan penyerang menyuntikkan konfigurasi berbahaya melalui anotasi Ingress yang dibuat khusus. Kerentanan paling kritis, CVE-2025-1974, memungkinkan eksekusi kode tanpa autentikasi oleh entitas apa pun dengan akses jaringan pod, melewati admission webhook sepenuhnya.

Dalam praktiknya, workload apa pun yang berjalan di jaringan pod kluster Anda—atau entitas apa pun dengan akses jaringan ke titik akhir admission controller—dapat mengeksploitasi kerentanan ini untuk mengeksekusi kode arbitrer dalam NGINX Ingress controller dan mengambil seluruh Secrets di seluruh kluster. Dalam banyak skenario umum, jaringan pod dapat diakses oleh semua workload di VPC cloud Anda, atau bahkan oleh siapa pun yang terhubung ke jaringan perusahaan Anda. Artinya, Secrets seperti Sertifikat TLS, kredensial API, dan data sensitif lainnya yang disimpan di Kubernetes mungkin terpapar.

ID CVE	Tingkat keparahan	Skor CVSS v3.1	Deskripsi	Risiko	Referensi
CVE-2025-1097	Tinggi	8,8	Penyerang dengan izin menulis resource Ingress dapat mengeksploitasi anotasi `auth-tls-match-cn` yang disediakan oleh komunitas NGINX Ingress untuk menyuntikkan konfigurasi berbahaya.	Penyerang dapat mengeksekusi kode arbitrer dalam konteks NGINX Ingress controller dan selanjutnya memperoleh Secrets di seluruh kluster.	#131007
CVE-2025-1098	Tinggi	8,8	Penyerang dengan izin menulis resource Ingress dapat mengeksploitasi anotasi `mirror-target` dan `mirror-host` yang disediakan oleh komunitas NGINX Ingress untuk menyuntikkan konfigurasi berbahaya.	Penyerang dapat mengeksekusi kode arbitrer dalam konteks NGINX Ingress controller dan selanjutnya memperoleh Secrets di seluruh kluster.	#131008
CVE-2025-1974	Kritis	9,8	Penyerang dengan akses jaringan pod dapat melewati admission webhook untuk menyuntikkan konfigurasi.	Penyerang dapat mengeksekusi kode arbitrer dalam konteks NGINX Ingress controller dan selanjutnya memperoleh Secrets di seluruh kluster.	#131009
CVE-2025-24514	Tinggi	8,8	Penyerang dengan izin menulis resource Ingress dapat mengeksploitasi anotasi `auth-url` yang disediakan oleh komunitas NGINX Ingress untuk menyuntikkan konfigurasi berbahaya.	Penyerang dapat mengeksekusi kode arbitrer dalam konteks NGINX Ingress controller dan selanjutnya memperoleh Secrets di seluruh kluster.	#131006
CVE-2025-24513	Sedang	4,8	NGINX Ingress controller gagal memvalidasi atau memfilter data masukan yang dikirimkan oleh pengguna dengan izin menulis resource Ingress secara memadai. Penyerang dapat mengeksploitasi kerentanan ini untuk membuat permintaan serangan, menyuntikkan data tidak sah ke jalur pembuatan file konfigurasi.	Kerentanan traversal direktori dalam Kontainer mungkin dipicu. Kerentanan ini dapat menyebabkan denial of service (DoS), atau bila dikombinasikan dengan kerentanan lain, menyebabkan kebocoran beberapa instance Secrets di kluster.	#131005

Mitigasi sementara

Jika Anda tidak dapat segera melakukan upgrade, matikan admission webhook untuk memblokir vektor serangan paling kritis (CVE-2025-1974). Ini adalah langkah sementara—Anda tetap harus segera melakukan upgrade ke versi yang telah diperbaiki.

Untuk kluster dengan NGINX Ingress controller yang diinstal melalui halaman Add-ons

Di halaman Add-ons kluster target, temukan komponen Nginx Ingress Controller dan nonaktifkan fitur admission webhook secara manual. Untuk detailnya, lihat Kelola NGINX Ingress controller.

Untuk kluster dengan NGINX Ingress controller yang diinstal melalui Marketplace

Hapus admission webhook terkait secara manual untuk mengurangi risiko:

kubectl delete validatingwebhookconfigurations ingress-nginx-admission

Penting

Menonaktifkan atau menghapus admission webhook menghilangkan mekanisme pra-validasi untuk konfigurasi Ingress. Meskipun ini mengurangi kerentanan, konfigurasi Ingress yang tidak valid tidak akan lagi ditolak sebelum berlaku. Aktifkan kembali admission webhook setelah Anda melakukan upgrade ke versi yang telah diperbaiki.

Remediasi: Lakukan upgrade ke versi yang telah diperbaiki

Komunitas telah memperbaiki kelima kerentanan tersebut pada versi NGINX Ingress controller berikut:

v1.11.5
v1.12.1

Lakukan upgrade ke v1.11.5 atau versi yang lebih baru (untuk rilis 1.11.x) atau v1.12.1 atau versi yang lebih baru (untuk rilis 1.12.x) pada jam sepi.

Manajemen add-on

Jika belum dilakukan, nonaktifkan admission webhook seperti dijelaskan dalam Mitigasi sementara untuk mengurangi risiko saat Anda mempersiapkan upgrade.
Lakukan upgrade komponen NGINX Ingress controller ke v1.11.5 atau versi yang lebih baru. Lihat Catatan rilis NGINX Ingress controller untuk detail versi, dan ikuti petunjuk dalam Perbarui NGINX Ingress controller untuk melakukan upgrade.
Setelah upgrade selesai, aktifkan kembali admission webhook.

Penting

Setelah pembaruan selesai, pastikan untuk mengaktifkan kembali fitur admission webhook. Fitur ini berfungsi sebagai mekanisme pra-validasi untuk konfigurasi Ingress dan secara efektif dapat meningkatkan keandalan serta stabilitas layanan. Sebelum konfigurasi Ingress Anda dibuat atau diperbarui berlaku, admission webhook akan memberi peringatan tentang kesalahan dalam konfigurasi Ingress, sehingga Anda dapat mencegah terjadinya masalah.

Marketplace

Jika belum dilakukan, hapus admission webhook secara manual seperti dijelaskan dalam Mitigasi sementara untuk mengurangi risiko saat Anda mempersiapkan upgrade.
Periksa catatan rilis komponen di halaman Marketplace atau halaman Helm di konsol, dan perbarui ack-ingress-nginx di halaman Marketplace ke v1.11.5 atau versi yang lebih baru pada jam sepi.
Setelah upgrade selesai, verifikasi bahwa admission webhook telah dibuat ulang sebagai bagian dari penerapan Helm chart yang diperbarui. Jika belum, aktifkan kembali secara manual.

Referensi patch

Komunitas telah menangani setiap kerentanan dalam commit berikut (semuanya merupakan bagian dari PR #13068):

CVE	Commit
CVE-2025-1097	ingress-nginx main@06c992a
CVE-2025-1098	ingress-nginx main@2e9f373
CVE-2025-1974	ingress-nginx main@0ccf4ca
CVE-2025-24513	ingress-nginx main@cbc1590
CVE-2025-24514	ingress-nginx main@ab470eb

FAQ

T: Kluster saya tidak memiliki NGINX Ingress controller yang terinstal. Apakah saya terdampak?

Tidak. Kluster tanpa NGINX Ingress controller yang terinstal tidak terdampak oleh kerentanan ini. Tidak diperlukan tindakan.

T: Saya telah menonaktifkan admission webhook. Apakah saya masih berisiko?

Menonaktifkan admission webhook memblokir kerentanan paling kritis (CVE-2025-1974, CVSS 9,8). Namun, kerentanan injeksi berbasis anotasi (CVE-2025-1097, CVE-2025-1098, CVE-2025-24514, CVE-2025-24513) tetap dapat dieksploitasi oleh penyerang yang memiliki izin menulis resource Ingress, terlepas dari konfigurasi webhook. Anda tetap harus melakukan upgrade ke versi yang telah diperbaiki.

T: Haruskah saya mengaktifkan kembali admission webhook setelah melakukan upgrade?

Ya. Admission webhook berfungsi sebagai mekanisme pra-validasi untuk konfigurasi Ingress. Webhook ini mendeteksi dan menolak konfigurasi yang tidak valid sebelum berlaku, membantu Anda mencegah gangguan layanan. Selalu aktifkan kembali setelah melakukan upgrade ke versi yang telah diperbaiki.

T: Apa perbedaan antara jalur instalasi Add-ons dan Marketplace?

NGINX Ingress controller dapat diinstal di ACK melalui halaman Add-ons (dikelola oleh siklus hidup add-on ACK) atau melalui Marketplace sebagai Helm chart. Langkah remediasi sedikit berbeda: pengguna Add-ons menonaktifkan webhook melalui UI konsol, sedangkan pengguna Marketplace menghapus resource ValidatingWebhookConfiguration secara langsung. Kedua jalur memerlukan upgrade ke v1.11.5 atau versi yang lebih baru.