.png)
Satu pertanyaan pertama saat melihat LPE di AV engine: seberapa banyak kontrol yang punya attacker local atas apa yang discan?
Di Windows, Defender berjalan secara real-time. File apa pun yang di-write ke disk akan dipicu scan-nya secara otomatis. User standard (tanpa admin privilege) bisa write ke sejumlah lokasi: direktori temp user, direktori AppData, atau lokasi yang bisa diakses melalui hardlink dari file yang bisa di-write.
Race condition selalu terdengar sulit, tapi di Windows ada beberapa teknik untuk memperlambat atau mendelay operasi file untuk memperbesar potensi windows race. OpLock (opportunistic locks), event-based synchronization, bahkan teknik NtSetInformationFile tertentu yang bisa delay close handle. Untuk CVE-2026-41091 spesifik, detail teknis lengkap belum dirilis publik. Tapi mengingat lima peneliti berbeda melaporkan ini secara terpisah, kemungkinan ada lebih dari satu primitive atau lebih dari satu code path yang vulnerable.
mpengine.dll dan Antimalware Platform: Dua Komponen, Dua CVE
Penting untuk memisahkan dua komponen ini karena Microsoft mempatchnya di versi berbeda:
Microsoft Malware Protection Engine (mpengine.dll) bertanggung jawab untuk scanning, detection, dan cleaning. Ini adalah komponen yang terdampak CVE-2026-41091 (LPE) dan CVE-2026-45584 (RCE terpisah yang tidak masuk KEV tapi dipatch bersamaan). Fix ada di versi 1.1.26040.8.
Microsoft Defender Antimalware Platform koleksi user-mode binary dan kernel-mode driver yang menjadi "wadah" di mana engine berjalan. CVE-2026-45498 (DoS) ada di layer ini, bukan di engine parsing.
Pemisahan ini relevan secara teknis karena attack surface-nya berbeda. DoS di Platform layer bisa berarti attacker bisa membuat Defender berhenti berfungsi tanpa menyentuh engine sama sekali mematikan perlindungan sebagai precondition sebelum mengeksekusi payload yang seharusnya terdeteksi. Kalau kedua CVE ini dipakai bersama dalam satu chain: DoS dulu untuk mengganggu Defender, kemudian LPE untuk eskalasi. Belum ada konfirmasi publik bahwa keduanya dipakai bersamaan, tapi threat model-nya bisa kita susun seperti itu sebgai asumsi.
Konteks Historis dari KEV (Known Exploited Vulnerabilities Catalog)
CISA menambahkan dua CVE baru tadi bersamaan dengan empat CVE lama yang masuk KEV dan ini bagian yang perlu diperhatikan:
CVE-2008-4250 - buffer overflow di Windows Server Service (NetAPI32.dll) via crafted RPC request. vulnerability yang sama yang dieksploitasi oleh MS08-067, prekursor teknis Conficker worm.
CVE-2009-1537 - NULL byte overwrite di QuickTime Movie Parser (quartz.dll). Parser media di Windows yang menerima input dari file yang dibuat attacker, dengan bug overwrite yang cukup untuk corrupt memory structure.
CVE-2010-0806 dan CVE-2010-0249 — keduanya use-after-free di Internet Explorer. CVE-2010-0249 adalah "Aurora" atau dikenal sebagai operasi aurora exploit yang dipakai dalam serangan terhadap Google dan perusahaan teknologi besar lainnya pada 2010. Mekanismenya: objek di-free, pointer ke object tersebut tetap disimpan di suatu lokasi, kemudian pointer itu diakses kembali saat object sudah tidak valid. Allocator heap pada titik itu mungkin sudah re-use memori tersebut dengan data yang dikontrol attacker.
CVE-2009-3459 - heap-based buffer overflow di Adobe Reader saat parsing PDF. Ini adalah kategori yang berbeda: parser file yang menerima dokumen dari luar, dengan bug di path parsing yang memungkinkan overflow ke heap, corrupt adjacent allocation, dan eksekusi arbitrary code.
Semua ini masuk KEV sekarang bukan karena ditemukan baru-baru ini, tapi karena ada evidence aktif bahwa ada infrastruktur yang masih menjalankan software versi tersebut dan sedang dieksploitasi. Setiap kali infrastructure lama diekspos kembali ke internet karena migrasi, reuse image, atau konsolidasi sistem vulnerability 15 tahun yang lalu menjadi current threat.
Primitive Exploit: Kenapa "Link Following" Bisa Berkembang Jauh
Dari sudut pandang primitive: link following memberikan write-what-where yang tidak langsung. Engine membuka file tapi file itu sekarang adalah target yang dikontrol attacker. Tergantung operasi apa yang dilakukan engine setelah buka file:
- Kalau engine membaca file dan kemudian menulis output ke path lain, attacker mungkin bisa pengaruhi output path dengan cara serupa
- Kalau engine menulis ke file misalnya cleaning/quarantine yang memodifikasi konten maka write tersebut bisa diarahkan ke binary system atau file konfigurasi
- Kalau engine men-delete atau me-rename file sebagai bagian dari remediation, itu bisa menjadi primitive delete-arbitrary-file, yang di Windows sudah cukup untuk LPE di banyak skenario (lihat teknik PrintSpoofer/EfsPotato family yang bergantung pada delete primitif)
