Dirty Frag CVE-2026-43284: Linux Kernel ESP ve RxRPC Üzerinden Yerel Yetki Yükseltme

CVE-2026-43284 ve CVE-2026-43500 — birlikte Dirty Frag olarak adlandırılan bu iki zafiyet — Mayıs 2026'nın başında kamuoyuna duyurulan ve Microsoft Defender tarafından sınırlı düzeyde gerçek dünya saldırısında kullanıldığı doğrulanan, Linux kernel'daki zincirli yerel yetki yükseltme açıklarıdır. 14 Mayıs'ta ise üçüncü varyant Fragnesia (CVE-2026-46300) tespit edildi. Bu, iki haftalık süreçte aynı sınıftaki üçüncü kritik zafiyet anlamına geliyor.

Dirty Frag, 2026'da Linux'u vuran ikinci büyük page-cache manipülasyon açığıdır; ilki Copy Fail (CVE-2026-31431)'dı. Kritik fark şudur: Dirty Frag, algif_aead modülüne bağlı değildir. Copy Fail geçici önlemini (algif_aead blacklist) uygulamış sistemler hâlâ Dirty Frag'a karşı savunmasızdır. SUSE bu zafiyeti "Copy Fail 2" olarak nitelendiriyor.

Zafiyet, Wiz araştırmacıları Merav Bar ve Rami McCarthy tarafından keşfedildi. Araştırmacılar, bu açığın Copy Fail ve Dirty Pipe ile aynı sınıfta, yarış koşuluna gerek duymayan deterministik bir yetki yükseltme zinciri olduğunu belirtti. Tek komutla root elde etmeye yarayan çalışan bir PoC kamuoyuyla paylaşılmış durumda.

Zafiyet Zinciri Özeti

Dirty Frag, Linux kernel'ın iki farklı alt sistemindeki page-cache yazma primitifini birleştiriyor:

| CVE | Alt Sistem | Mainline Yama Commit'i | |-----|-----------|----------------------| | CVE-2026-43284 | xfrm-ESP (IPsec — esp4, esp6) | f4c50a4034e6 | | CVE-2026-43500 | RxRPC | aa54b1d27fe0 |

CVE-2026-46300 (Fragnesia) — XFRM ESP-in-TCP alt sistemindeki ayrı ama ilişkili bir açık. William Bowling (Zellic) ve V12 güvenlik ekibi tarafından 14 Mayıs 2026'da keşfedildi; yalnızca esp/xfrm yolunu kullanıyor, RxRPC vektörü içermiyor.

Her iki Dirty Frag CVE'si de kernel'a özel olarak sahip olmadığı page-cache destekli belleğin değiştirilmesine olanak tanıyor. Bu ilkel, bir setuid binary'nin üzerine yazarak root kabuğu elde etmek için kullanılıyor.

"Her iki açık da kernel'ın münhasır sahipliğinde olmayan page-cache destekli belleğin değiştirilmesine izin vererek hassas dosyaların bozulmasına ve nihayetinde yetki yükseltmeye yol açıyor. Yarış koşuluna dayalı exploitlerden farklı olarak bu açık sınıfı deterministik ve son derece güvenilirdir; Copy Fail ve Dirty Pipe ile benzerlik göstermektedir." — Merav Bar ve Rami McCarthy, Wiz

CVSS Puanları

CVE-2026-43284: CVSS 7.8 YÜKSEK — AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H
CVE-2026-43500: CVSS 7.8 YÜKSEK — AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H
CVE-2026-46300 (Fragnesia): CVSS 7.8 YÜKSEK — AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H

Teknik Analiz

Dirty Frag, Linux kernel'ın xfrm-ESP (IPsec) ve RxRPC ağ alt sistemlerindeki bellek parçası yeniden birleştirme mantığını kötüye kullanıyor. Exploit zinciri, splice() sistem çağrısını kullanarak page-cache destekli bir sayfayı yazılabilir bir kernel tamponuyla zincirliyor — Copy Fail ile aynı sınıf, fakat farklı saldırı yüzeyi: ağ yığını.

splice(), IPsec ve RxRPC parça birleştirme yollarına kernel page-cache sayfalarını kopyalama yapmadan köprüleyebildiği için, ayrıcalıksız yerel bir saldırgan salt okunur bir page-cache sayfasına yazı yazabilir. Sonuç, herhangi bir page-cache destekli dosyaya — /usr/bin/su gibi setuid binarylere dahil — uygulanabilen kontrollü bir bozma primitifi.

Copy Fail önlemi uygulayanlara kritik not: Dirty Frag, esp4, esp6 veya rxrpc üzerinden tetiklenir — algif_aead üzerinden değil. Yalnızca Copy Fail workaround'u uygulamış kuruluşlar Dirty Frag'a karşı tamamen savunmasız olmaya devam ediyor; her iki önlemin bağımsız olarak uygulanması gerekiyor.

Sertleştirilmiş bir container ortamında Dirty Frag exploit'i için saldırganın genellikle CAP_NET_ADMIN kapasitesine ihtiyacı var. Varsayılan seccomp profili kullanan ve yüksek kapasiteler içermeyen Kubernetes deployları bu nedenle container içinden sömürülmesi daha güç ortamlar oluşturuyor — ancak SSH, web shell veya container escape yoluyla host seviyesinde erişim bu gereksinimini devre dışı bırakıyor.

Gerçek Dünya Saldırıları

Microsoft Defender, Dirty Frag veya Copy Fail tekniklerini kullanan sınırlı gerçek dünya saldırısı tespit etti. Gözlemlenen kampanya şu sırayı takip ediyor:

1. Dışarıdan SSH erişimi sağlanarak etkileşimli kabuk açılıyor
2. su üzerinden yetki yükseltmeyi tetikleyen ELF binary (./update) çalıştırılıyor
3. GLPI LDAP kimlik doğrulama yapılandırma dosyası değiştiriliyor (vim'den kalan .swp artefaktı gözlemleniyor)
4. GLPI dizini ve sistem yapılandırması üzerinde keşif yapılıyor
5. Aktif oturumları bozmak amacıyla PHP oturum dosyaları siliniyor
6. Kalan oturum verisi okunarak kimlik bilgileri toplanıyor

Saldırı, gerçek hedefli bir zero-day kampanyasından ziyade fırsatçı post-compromise istismarını yansıtıyor: SSH ayak izi → LPE → BT yönetim aracı üzerinden yanal hareket.

Microsoft Defender Antivirus imzaları:

• Exploit:Linux/DirtyFrag.A
• Exploit:Linux/DirtyFrag.B
• Trojan:Linux/DirtyFrag.Z!MTB
• Trojan:Linux/DirtyFrag.ZA!MTB
• Trojan:Linux/DirtyFrag.ZC!MTB
• Trojan:Linux/DirtyFrag.DA!MTB

Trojan:Linux/DirtyFrag.Z!MTB ve Trojan:Linux/DirtyFrag.DA!MTB imzaları, Fragnesia'nın kamuya açık exploit artefaktlarını da kapsıyor.

Etkilenen Sistemler ve Vendor Advisory'leri

Dirty Frag, geniş bir Linux dağıtım yelpazesini etkiliyor:

| Dağıtım | Advisory / Durum | |---|---| | Ubuntu | ubuntu.com/blog/dirty-frag-linux-vulnerability-fixes-available | | Red Hat Enterprise Linux | RHSB-2026-003 | | Debian | security-tracker CVE-2026-43284 | | Amazon Linux | AWS Security Bulletin 2026-027 | | SUSE | addressing-copy-fail2-aka-dirtyfrag | | Fedora | FEDORA-2026-8cffa03dad | | Rocky Linux | forums.rockylinux.org | | Gentoo | bugs.gentoo.org/974307 | | AlmaLinux | Advisory yayımlandı | | CloudLinux | Advisory yayımlandı |

Acil aksiyon için öncelikli sistemler:

• Kubernetes node'ları ve container host'ları
• Self-hosted GitHub Actions, GitLab Runner, Jenkins agent'ları
• Çok kiracılı Linux sunucular ve build farm'ları
• Kullanıcı kodu çalıştıran sistemler (notebook, sandbox, SaaS)
• Harici SSH üzerinden erişilebilen GLPI, Zabbix, Nagios gibi BT yönetim sistemleri

Hızlı Envanter Komutları

# Kernel sürümünü kontrol et
uname -r
uname -a

# Etkilenen modüllerin yüklü olup olmadığını kontrol et
lsmod | grep -E "^(esp4|esp6|rxrpc)" || true

# Aktif bağlantıları kontrol et
ss -ntp | grep -v LISTEN || true

Kubernetes ve container host'ları için:

# Tüm pod'ları ve güvenlik bağlamlarını listele
kubectl get pods -A -o wide

# Seccomp profili olmayan pod'ları bul
kubectl get pods -A -o jsonpath='{range .items[*]}{.metadata.namespace}{" "}{.metadata.name}{" "}{.spec.securityContext.seccompProfile.type}{"\n"}{end}'

# NET_ADMIN kapasitesine sahip pod'ları bul
kubectl get pods -A -o jsonpath='{range .items[*]}{.metadata.namespace}{" "}{.metadata.name}{" "}{.spec.containers[*].securityContext.capabilities.add}{"\n"}{end}' | grep -i net_admin || true

Geçici Önlem

Vendor kernel patch'i hazır olana kadar etkilenen modülleri yüklenmekten engelleyin:

# esp4, esp6 ve rxrpc modüllerini kara listeye al
cat > /etc/modprobe.d/disable-dirtyfrag.conf << 'EOF'
install esp4 /bin/false
install esp6 /bin/false
install rxrpc /bin/false
EOF

# Aktif modülleri güvenli şekilde kaldır
rmmod rxrpc 2>/dev/null || true
rmmod esp6 2>/dev/null || true
rmmod esp4 2>/dev/null || true

Önlemi uygulamadan önce IPsec/VPN bağımlılığını kontrol edin:

# IPsec/VPN tünellerinin esp4/esp6 kullanıp kullanmadığını kontrol et
ip xfrm state list
ip xfrm policy list

# RxRPC kullanımını kontrol et (AFS dosya sistemi kullanıcıları)
lsmod | grep -E "rxrpc|kafs" || true

Bu geçici önlem, ESP taşıma kullanan IPsec VPN tünellerini kesecektir. IPsec'e bağımlı sistemlerde aşamalı yaklaşım öneririz: geliştirme/test ortamlarını hemen yamalayın, IPsec kullanmadığı doğrulanan host'lara modül kara listesini uygulayın, diğer sistemler için kernel patch'e öncelik verin.

Saldırı Sonrası Cache Temizleme

Önlem uygulanmadan önce sömürü gerçekleştiyse, modüller devre dışı bırakılsa bile page cache'de kötü amaçlı değişiklikler kalıcı hale gelmiş olabilir:

# Cache düşürmeden önce dosya sistemini senkronize et
sync

# Tüm page cache'leri temizle (uyarı: geçici I/O performans etkisi)
echo 3 | sudo tee /proc/sys/vm/drop_caches

Üretim ortamlarında cache temizlemeyi dikkatli değerlendirin — depolama üzerinde geçici bir okuma yükü artışına neden olabilir.

Container ve Kubernetes Sertleştirme

Dirty Frag, varsayılan seccomp profili kullanan ve NET_ADMIN kapasitesi içermeyen bir Kubernetes pod'unun içinden sömürülmek için CAP_NET_ADMIN gerektiriyor. Ancak bu, tek başına güvenilir bir koruma sınırı değil; çünkü:

• Pek çok deployment, meşru ağ özellikleri için NET_ADMIN kapasitesi veriyor
• Compromised SSH, web shell veya container escape yoluyla elde edilen host erişimi, container kapasite kısıtlamalarını tamamen devre dışı bırakıyor
• CAP_NET_ADMIN, yanlış yapılandırılmış admission politikaları nedeniyle örtük olarak verilebiliyor

Önerilen container sertleştirme adımları:

• NET_ADMIN kapasitesi alan pod'ları denetleyin; gereksiz olduğu yerlerde kaldırın
• Ham soket çağrılarını engelleyen kısıtlayıcı seccomp profili uygulayın
• Hassas namespace'lerde PodSecurity restricted zorunlu kılma seviyesini etkinleştirin
• Untrusted workload'ları (PR job'ları, kullanıcı notebook'ları) production kimlik bilgilerinden izole edin

# PodSecurity admission örneği - namespace seviyesi kısıtlama
apiVersion: v1
kind: Namespace
metadata:
  name: guvensiz-is-yuklemeleri
  labels:
    pod-security.kubernetes.io/enforce: restricted
    pod-security.kubernetes.io/audit: restricted
    pod-security.kubernetes.io/warn: restricted

Fragnesia (CVE-2026-46300) — Üçüncü Varyant

14 Mayıs 2026'da Fragnesia adlı yeni bir varyant kamuoyuyla paylaşıldı. CVE-2026-46300 olarak takip edilen bu açık (CVSS 7.8), XFRM ESP-in-TCP alt sistemindeki farklı bir hatayı kullanıyor. William Bowling (Zellic) ve V12 güvenlik ekibi tarafından keşfedilen Fragnesia, yalnızca esp/xfrm modül yolunu kullanıyor; RxRPC vektörü içermiyor.

Dirty Frag ile temel farklar:

• Fragnesia, RxRPC saldırı yolunu kullanmıyor
• Yama, Dirty Frag yamalarından bağımsız
• Microsoft Defender imzaları Trojan:Linux/DirtyFrag.Z!MTB ve Trojan:Linux/DirtyFrag.DA!MTB Fragnesia kamuya açık exploit artefaktlarını da kapsıyor
• Advisory yayımlayan dağıtımlar: AlmaLinux, Amazon Linux, CloudLinux, Debian, Gentoo, RHEL, SUSE, Ubuntu

Dirty Frag geçici önlemi (esp4, esp6, rxrpc kara listesi), her iki saldırı yolu da esp/xfrm alt sistemine dayandığından Fragnesia saldırı yolunu da engelliyor.

Açıklama Zaman Çizelgesi

| Tarih | Olay | |-------|------| | 2026-05-08 | Linux Kernel Organization, CVE-2026-43284 için yama yayımlıyor (f4c50a4034e6) | | 2026-05-08 | Microsoft Security Blog, Dirty Frag analizini ve sınırlı gerçek dünya saldırısını duyuruyor | | 2026-05-08 | NVD, CVE-2026-43284'ü yayımlıyor; CVE-2026-43500 rezerve ediliyor (henüz yayımlanmadı) | | 2026-05-08 | CVE-2026-43500 (RxRPC) mainline'da yamalanıyor (aa54b1d27fe0) | | 2026-05-08 | Wiz, tam teknik analizi içeren advisory'sini yayımlıyor | | 2026-05-14 | Fragnesia (CVE-2026-46300), William Bowling (Zellic) / V12 ekibi tarafından keşfediliyor | | 2026-05-14 | Microsoft, Fragnesia varyantını kapsayacak şekilde blog yazısını güncelliyor | | 2026-05-14 | Fragnesia için yeni yama yayımlıyor; dağıtım advisory'leri güncelleniyor |

Patch Stratejisi

Dağıtımınız güncellenmiş kernel paketini yayımladığında:

1. Vendor advisory'sinin CVE-2026-43284, CVE-2026-43500 ve CVE-2026-46300'ün tamamını kapsadığını doğrulayın
2. Kernel güncellemesini önce test ortamında kurun
3. IPsec ve RxRPC'ye bağımlı workload'ların patch sonrası düzgün çalıştığını doğrulayın
4. Reboot gereksinimine yönelik bakım penceresi planlayın
5. Kubernetes node havuzları ve CI runner'larını dalga dalga güncelleyin
6. Modül kara listesini yalnızca patch doğrulandıktan sonra kaldırın
7. NET_ADMIN kapasite izinlerinin hâlâ gerekli olup olmadığını yeniden değerlendirin

Eresus Bakış Açısı

Dirty Frag, iki haftalık süreçte üçüncü deterministik page-cache LPE'dir. Copy Fail, Dirty Frag, Fragnesia sıralaması — splice tabanlı page-cache yazma primitiflerinin kernel ağ ve kripto alt sistemleri üzerinden sömürülmesi sınıfının aktif araştırma ilgisi gördüğünü gösteriyor.

Savunma tarafı için doğru sorular şunlar:

• Hangi host'larda şu an esp4, esp6 veya rxrpc modülleri yüklü?
• Hangi sistemlere Copy Fail önlemi uygulandı ama Dirty Frag önlemi henüz uygulanmadı?
• Hangi Kubernetes pod'larının NET_ADMIN kapasitesi var ve daha düşük güven düzeyli workload'larla aynı node'u paylaşıyor?
• GLPI, Zabbix, Nagios gibi BT yönetim sistemleri harici SSH'dan erişilebilir mi?
• Üretim node'ları için patch penceresi nedir ve bu pencerede hangi telafi edici kontroller uygulanıyor?

Bunlar operasyonel sorular. Yanıtlar yoksa CVE puanlarını takip etmek risk yönetimi değildir.

SSS

Dirty Frag uzaktan sömürülebilen bir açık mı?

Açıklanan senaryo yerel yetki yükseltmedir. LPE primitifine erişmeden önce SSH, web shell veya container escape yoluyla ilk erişim gerekiyor. Microsoft tarafından gözlemlenen gerçek dünya saldırısı tam olarak bu modeli takip etti: SSH ayak izi → su üzerinden LPE → yanal hareket.

Copy Fail önlemi Dirty Frag'a karşı koruma sağlıyor mu?

Hayır. Copy Fail, algif_aead devre dışı bırakılarak engellenir. Dirty Frag ise esp4, esp6 ve rxrpc modüllerini kullanıyor — tamamen ayrı bir saldırı yüzeyi. Her iki önlemin bağımsız olarak uygulanması gerekiyor.

Dirty Frag container ortamlarını etkiliyor mu?

Varsayılan Kubernetes yapılandırmalarında standart seccomp profilleri ve NET_ADMIN olmadan engel daha yüksek. Ancak bu güvenilir bir koruma sınırı değil — yanlış yapılandırılmış pod'lar, host seviyesi erişim veya container escape bunu aşabilir.

Fragnesia nedir, Dirty Frag'dan farkı ne?

Fragnesia (CVE-2026-46300), XFRM ESP-in-TCP alt sistemindeki üçüncü bağımsız bir açık. Aynı sömürü sınıfını (deterministik page-cache bozma) kullanıyor ama farklı bir kod yolu üzerinden. esp4 ve esp6 engellenmesi Fragnesia'yı da hafifletiyor.

Kontrol Listesi

• [ ] CVE-2026-43284, CVE-2026-43500 ve CVE-2026-46300 için kernel sürümü ve dağıtım advisory'si kontrol edildi mi?
• [ ] Her host'ta esp4, esp6, rxrpc modül yükleme durumu doğrulandı mı?
• [ ] Modül kara listesi uygulanmadan önce IPsec/VPN workload'ları envantere alındı mı?
• [ ] IPsec kullanılmayan host'lara modül kara listesi uygulandı mı?
• [ ] Kubernetes pod NET_ADMIN izinleri denetlendi mi?
• [ ] Container seccomp profilleri incelendi mi?
• [ ] Untrusted workload'lar production kimlik bilgisi namespace'lerinden izole edildi mi?
• [ ] GLPI, Zabbix ve benzeri BT yönetim sistemleri harici SSH'a karşı sertleştirildi mi?
• [ ] Vendor kernel patch takibi ve reboot planı açıldı mı?
• [ ] Önceki istismar ihtimali olan host'larda page-cache bütünlük değerlendirmesi yapıldı mı?
• [ ] Patch sonrası doğrulama tamamlandı ve modül kara listesi kaldırıldı mı?