3 poin oleh GN⁺ 2026-02-20 | 2 komentar | Bagikan ke WhatsApp
  • Google merilis pembaruan Stable Channel untuk Chrome versi desktop yang mencakup kerentanan zero-day terkait CSS yang diidentifikasi sebagai CVE-2026-2441
  • Google telah mengonfirmasi bahwa kerentanan ini sedang dieksploitasi dalam serangan nyata (in the wild), dan pengguna harus segera memperbarui ke versi terbaru untuk meminimalkan risiko keamanan
  • Pembaruan sedang digulirkan secara bertahap untuk Chrome di Windows, macOS, dan Linux

Ringkasan pembaruan Chrome Stable Channel

  • Google mengumumkan pembaruan Stable Channel untuk Chrome desktop
    • Windows/macOS: 145.0.7632.75/76, Linux: 144.0.7559.75
    • Pembaruan didistribusikan untuk platform Windows, macOS, dan Linux
    • Akan diterapkan secara bertahap melalui pembaruan otomatis

Kerentanan keamanan CVE-2026-2441

  • Versi ini mencakup kerentanan keamanan yang ditetapkan sebagai CVE-2026-2441
    • Dikonfirmasi sebagai kerentanan zero-day yang terjadi dalam proses pemrosesan CSS
    • Google menyatakan bahwa kerentanan ini sedang dieksploitasi dalam serangan nyata

Tindakan yang disarankan untuk pengguna

  • Google merekomendasikan semua pengguna untuk segera memperbarui Chrome ke versi terbaru
    • Jika pembaruan otomatis belum selesai, pembaruan dapat dilakukan secara manual
    • Dengan menggunakan versi terbaru, pengguna dapat terlindungi dari kerentanan ini

Distribusi dan dukungan

  • Pembaruan digulirkan secara bertahap melalui Stable Channel
    • Sebagian pengguna mungkin memerlukan waktu sebelum pembaruan diterapkan
  • Tim Chrome terus melakukan peningkatan keamanan tambahan dan peningkatan stabilitas

2 komentar

 
xguru 2026-02-20

Saya sudah update, ternyata di Mac versinya sudah naik sampai 145.0.7632.110.

Ini adalah celah Use-After-Free yang terjadi saat menangani font di dalam CSS dan terus menggunakan alamat yang sudah tidak valid, sehingga bisa sampai mengambil alih sistem; jadi cukup dengan membuka situs web saja pun bisa kena. Bahkan kabarnya sudah ada pihak yang mengeksploitasi celah ini.

 
GN⁺ 2026-02-20
Komentar Hacker News
  • Ditemukan kerentanan use-after-free di CSS pada Google Chromium
    Masalah ini memungkinkan penyerang jarak jauh memicu kerusakan heap melalui halaman HTML berbahaya, dan dapat memengaruhi bukan hanya Chrome tetapi juga browser berbasis Chromium seperti Edge dan Opera
    Ini tampak seperti masalah yang cukup serius, dan jadi penasaran berapa besar bug bounty yang diterima penelitinya

    • Sepertinya tidak akan lebih dari 20 ribu dolar
      Mengingat upaya yang dibutuhkan untuk menemukan kerentanan serius dan membuat eksploit yang bisa direproduksi, rasanya nilai hadiahnya terlalu rendah
    • Firefox tampaknya tidak terdampak
    • Aplikasi Electron juga kemungkinan bisa terdampak
      Karena kebanyakan mengunci versi Chrome tertentu (pinning)
    • Agar menjadi serangan yang benar-benar bermakna, dibutuhkan sandbox escape
      Namun frasa “ditemukan di wild” bisa juga berarti sudah ada rantai serangan yang mencakup sandbox escape
    • Menurut saya, masalahnya adalah masih ada kecenderungan meremehkan use-after-free
      Gagal menghilangkan bug seperti ini dari bahasa sistem di abad ke-21 adalah hal yang memalukan
  • Sepertinya bug seperti ini masih bersembunyi di sudut gelap codebase Chromium/Blink
    Untuk proyek inti seperti ini, seharusnya ada tim khusus yang terus-menerus memverifikasi seluruh kode
    Menurut saya, investasi pada penguatan keamanan seperti ini jauh lebih bernilai daripada fitur seperti integrasi kulkas pintar

    • Chromium sebenarnya sudah menjalankan fuzzing yang agresif
      Dengan fuzzer yang cukup kuat, hampir tidak ada area yang benar-benar tidak terjangkau
  • Ungkapan “Use after free in CSS” terdengar agak lucu

    • Mungkin yang dimaksud adalah bagian parser CSS atau CSSOM
    • Jadi penasaran kenapa memakai ungkapan seperti itu
  • Saya kurang paham apa dampak nyata dari kerentanan ini
    Tanpa sandbox escape atau XSS, ini tampak hampir tidak berbahaya, tetapi jika melihat kode PoC, disebutkan bahwa
    eksekusi kode arbitrer di dalam proses renderer, kebocoran informasi, pencurian cookie·sesi, manipulasi DOM, keylogging, dan berbagai serangan lain dimungkinkan

    • Serangan browser biasanya terdiri dari dua tahap
      Pertama mendapatkan eksekusi kode arbitrer di dalam sandbox melalui bug renderer, lalu mendapatkan hak sistem penuh lewat sandbox escape
      Kerentanan ini termasuk tahap pertama, dan jika memang sudah dipakai dalam serangan nyata, kemungkinan besar tahap kedua juga ada
  • Masih mengejutkan bahwa kerentanan memori seperti ini tetap muncul
    Rasanya seharusnya ada alat untuk membuat binary yang terverifikasi seperti pada bahasa yang memory-safe
    CSS sekarang juga makin kompleks dengan bertambahnya variabel, scope, dan fitur preprocessor, jadi mungkin suatu hari akan dibutuhkan ekstensi “no-style” seperti “no-script”
    Jadi penasaran apakah laporan kali ini hanya kesalahan sederhana atau bagian dari rantai serangan multistage

    • Bukan berarti alat seperti itu tidak ada, tetapi Chromium memang sudah menggunakan semua sanitizer dan fuzzing yang memungkinkan
      Masalahnya adalah cakupan pengujian. Codebase-nya sangat besar sehingga sulit mendapatkan coverage yang lengkap, dan celah itulah yang memungkinkan kerentanan seperti ini muncul
    • “no-style” secara realistis tidak mungkin
      CSS adalah inti web, jadi jika dihapus hampir semua situs akan rusak
      Sebagai gantinya, pendekatan isolation bisa menjadi alternatif
      Jika sesi browser di-stream dari server jarak jauh, maka bahkan ketika zero-day dieksploitasi, yang terdampak hanya instance jarak jauh, bukan mesin lokal
      Ini memang tidak sempurna, tetapi merupakan strategi defense in depth untuk memperkecil attack surface
  • Dalam daftar alat keamanan yang digunakan tim Chromium disebutkan AddressSanitizer, MemorySanitizer, libFuzzer, dan lainnya, tetapi menarik bahwa OSS-Fuzz tidak disebut

    • OSS-Fuzz bukan fuzzer tersendiri, melainkan platform yang mengintegrasikan sanitizer dan engine fuzzing yang disebutkan di atas
  • Saya ingin melihat kode PoC setelah patch dirilis

  • Muncul candaan bahwa Chromium harus ditulis ulang dengan Rust

    • Faktanya, sebagian engine Blink pernah ditulis ulang dengan GC-based C++ untuk mengejar efek yang mirip
    • Ada juga pendapat bahwa akan lebih baik berinvestasi pada engine Servo milik Mozilla
  • Saat mencari CVE, ditemukan halaman issue, tetapi
    tertulis “Access is denied”
    Tampaknya masih privat dan hanya bisa diakses setelah login