Joomla'nın JCE Editor ve SP Page Builder eklentilerindeki kimlik doğrulamasız dosya yükleme açıkları aktif olarak sömürülüyor

Joomla'nın iki eklentisi, saldırganlara barındırma sunucusunda uzaktan kod çalıştırma imkanı veren kimlik doğrulamasız rastgele dosya yükleme açıkları taşıyor ve bunlardan en az biri sahada sömürülüyor. dev.to'da yayımlanan bir yazıya göre açıklar JCE Editor'da CVE-2026-48907, SP Page Builder'da ise CVE-2026-48908 olarak takip ediliyor ve her ikisi de yüksek önem derecesine sahip. Yazı, FortiGuard Labs'ın SP Page Builder sorununun kamuya açık olarak duyurulmasından sonra da aktif sömürmeyi gözlemlemeye devam ettiğini bildiriyor.

Açıklar nasıl çalışıyor

Sorunlar iki belirli uç noktada yer alıyor: JCE Editor'daki profiles.import ve SP Page Builder'daki asset.uploadCustomIcon. dev.to analizinde anlatıldığı gibi her iki uç nokta da yüklenen dosyayı, çağıranın kim olduğunu doğrulamadan ve dosyanın tür ya da içerik bakımından ne olduğunu kontrol etmeden kabul ediyor. Kimlik bilgisi veya geçerli bir oturum gerekmiyor; açıkları ayrıcalık yükseltme değil de kimlik doğrulamasız sınıfına sokan da tam olarak bu. Sunucunun çalıştırılabilir PHP olarak değerlendirdiği bir dosya yüklemek, açığı CMS'i çalıştıran makinede tam bir uzaktan kod çalıştırmaya dönüştürüyor.

Yazının belirttiğine göre altta yatan örüntü tanıdık: yöneticiler için tasarlanmış işlevler — örneğin bir yapılandırma profilini içe aktarmak veya özel bir simge ayarlamak — yönetimsel bağlamı hiç doğrulamayan bir rotadan erişilebilir durumda. Sıradan bir editör kolaylığı, internetteki herkese açık bir yazma yeteneğine dönüşüyor.

Joomla eklentileri neden tekrarlayan bir zayıf nokta

Yazıya göre Joomla'nın çekirdek kod tabanı, eklenti ekosistemine kıyasla görece küçük. Gerçek hayattaki siteler, CMS'i kullanılabilir kılmak için sayfa oluşturucular, editörler, form bileşenleri ve şablon çerçeveleri üst üste yığıyor ve her biri, site sahibinin takip etmesi gereken ayrı ayrı bakımı yapılan bir bağımlılık. Bunun pratik sonucu şu: bir Joomla kurulumu çekirdek düzeyinde tamamen güncel olabilir ama yine de savunmasız bir eklenti çalıştırıyor olabilir; dolayısıyla tek bir erişilebilir uç nokta dosya kabul edeceği sürece saldırganın karmaşık bir sömürü zincirine ihtiyacı kalmıyor.

Operatörler neleri kontrol etmeli

dev.to yazısı bir müdahale kontrol listesi sunıyor. Yöneticiler kurulu JCE Editor ve SP Page Builder sürümlerini doğrulamalı ve bu tanımlayıcıları yamayan sürümlere geçmelidir. Web sunucusu erişim günlükleri, profiles.import ve asset.uploadCustomIcon uç noktalarına yönelik POST istekleri açısından incelenmeli; dış kaynak adreslerinden gelen trafik, döndürülen yanıt koduna bakılmaksızın şüpheli kabul edilmelidir. Dosya sistemi taramalarında upload, media, cache ve template dizinlerinde yeni oluşturulan PHP dosyaları aranmalı ve bilinen iyi bir envanterle karşılaştırılmalıdır. Veritabanı kontrolleri, normal değişiklik yönetimi dışında oluşturulmuş hesaplar veya bileşenler için kullanıcı ve eklenti tablolarını kapsamalıdır. Bir web shell doğrulanırsa, o ana makineden erişilebilen tüm kimlik bilgilerinin ifşa edilmiş kabul edilmesi ve shell kaldırıldıktan sonra rotasyonlanması gerekir. Yazı ayrıca operatörleri sürekli takip için FortiGuard'un salgın uyarılarına ve Joomla güvenlik merkezine yönlendiriyor.

Neden önemli

Bunlar teorik bulgular değil. Açıklardan biri duyurulmasının ardından halihazırda sömürülüyor, ikisini tetiklemek için bir HTTP isteğinden fazlası gerekmiyor ve ikisi de saldırganın kendi kodunu sunucuda çalıştırmasıyla sonuçlanıyor. Joomla çalıştıran herkes için ders şu: yamalanmış bir çekirdek, yamalanmış bir site anlamına gelmez; eklenti envanterleri de CMS'in kendisi kadar sürüm disiplini gerektirir ve yönetimsel araçların içindeki dosya yükleme uç noktaları bir tespit sinyali olarak sürekli ilgiyi hak eder.