Magento Open Source ve Adobe Commerce kullanan çevrimiçi mağazalar, kimlik doğrulama gerektirmeden sunucuda kod çalıştırmaya izin veren bir sıfırıncı gün açığı üzerinden hedef alındı. Hollandalı e-ticaret güvenlik şirketi Sansec, 5 Eylül’de yayımladığı notta açığın saldırganlara mağaza sunucusuna kalıcı arka kapı yerleştirme imkânı verdiğini, saldırıların ise 4 Eylül’de başladığını bildirdi.
Sansec, açığı StyleSmuggler olarak adlandırdı ve uyarıyı erken yayımladığını, çünkü mağazaların o sırada aktif olarak ele geçirildiğini belirtti. Şirketin açıklamasına göre saldırı başarılı olduğunda saldırgan mağaza sunucusunda kod çalıştırabiliyor ve kalıcı bir backdoor kurabiliyor.
Adobe tarafında ise 6 Eylül itibarıyla herhangi bir güvenlik duyurusu, CVE kaydı, yama ya da geçici çözüm yayımlanmamıştı. Adobe Commerce güvenlik bülteni dizininde de 11 Ağustos güncellemesinden sonra yeni bir kayıt yer almıyordu.
Sansec, mevcut sürümlerin tamamının etkilendiğini; buna 2.4.9 sürümünün de dahil olduğunu söyledi. Araştırmacılar, temiz Magento Open Source kurulumlarında 2.4.7, 2.4.8 ve 2.4.9 için kimlik doğrulama olmadan çalışan tam saldırı zincirini yeniden ürettiklerini de açıkladı. Şirkete göre ilk kurban, Adobe’nin Temmuz ve Ağustos 2026 güvenlik güncellemeleri uygulanmış 2.4.6-p15 sürümünü kullanıyordu. Adobe’nin Ağustos bülteninde bu hatıra 2.4.6-2026-aug etiketiyle atıf yapılıyor.
Sansec, Adobe Commerce ve Adobe Commerce on Cloud tarafında bir yeniden üretim yayımlamadı; Adobe de hangi sürümlerin etkilendiğini doğrulamadı. Etkilenen mağaza sayısı da paylaşılmadı. Buna karşın Sansec, GraphQL’i geçici olarak kapatmayı, kendi Shield ürünü dışındaki mağazalar için ilk önlem olarak önerdi.
Magento barındırma ve geliştirme şirketi Disrex Group’un bulguları ise saldırının dışarıdan bağımsız kanıtı olarak öne çıktı. Şirket, 5 Eylül’de yayımladığı olay müdahale deposunda iki ele geçirilmiş mağaza ve bir de saldırıya uğrayıp ihlal edilmeyen üçüncü mağaza üzerinde çalıştığını duyurdu. Disrex, web sunucusu kurallarını da bu mağazalardan birinde yakalanan trafik üzerinden hazırladığını söyledi.
Şirketin aktardığına göre, incelenen iki mağaza da Magento Open Source çalıştırıyordu ve Disrex’in barındırma markası RexHosting üzerinden kendi altyapısında tutuluyordu. Birinci mağaza olan Store A, Magento Open Source 2.4.8 kullanıyordu ve Sansec Shield müşterisiydi; modül kurulu, etkin ve lisanslıydı. Saldırı 4 Eylül’de UTC saatiyle 23.10’da gerçekleşti. Bu zamanlama, Sansec’in ilk engelleme kurallarını devreye almasının saatler öncesine denk geldi. Disrex, o anda Shield’ın aktif olduğunu ve mağazaya yönelen başka kötü niyetli trafiği engellediğini de ekledi.
İkinci mağaza Store B ise Shield müşterisi değildi ve Magento 2.4.7-p2 sürümünü çalıştırıyordu. Adobe’nin sürüm geçmişine göre bu seviye Ağustos 2024’e karşılık geliyor ve güncel 2.4.7-p10’un sekiz kademe gerisinde bulunuyor. Disrex’e göre bu mağaza ilk kez 5 Eylül’de UTC 00.55’te hedef alındı ve şirketin hazırladığı web sunucusu kuralları ile zafiyet okuması da buradan alındı.
Disrex, iki mağazanın da Sansec’in ilk istismar gözlemi ile herhangi bir savunmanın devreye girdiği an arasındaki yaklaşık sekiz saatlik pencerede ihlal edildiğini söyledi. Şirket, The Hacker News’e verdiği yanıtta “Yama durumu burada önemsizdi, satıcıların en çok duyması gereken kısım bu” ifadesini kullandı.
Olayın saldırı tarafında kullanılan teknik, Sansec’e göre iki aşamalı işliyor. İlk aşamada saldırgan, Magento’nun kendisinin yazdığı bir dosyaya PHP kodu ekliyor; örnek olarak hata raporu üretildiğinde oluşturulan dosyalar gösteriliyor. İkinci aşamada ise platformun standart “Payment Transaction Failed Reminder” e-postası tetiklenerek bu dosya çalıştırılıyor. Kod, Magento mesajı işlerken yürütüldüğü için e-postanın açılmasına da gerek kalmıyor; e-posta teslimi başarısız olsa bile saldırı tamamlanabiliyor.
Sansec, tam istismar zincirini henüz yayımlamadı ve zincirin ayrıntılarını, dropper’ı ve implant’ı daha sonraki bir güncellemede açıklayacağını bildirdi. Disrex’in kendi mekanizma okumasına göre ise enjekte edilen metin içindeki bir yönerge, Magento’nun komut satırı bağımlılık enjeksiyon derleyicisi için kullanılan sınıflarına bir dizi çağrı yaptırıyor. Zincir, saldırganın seçtiği bir dosya yolunu içeri alarak sona eriyor; bu dosya da bir an önce zehirlenmiş olan log oluyor. Çalıştırılan PHP dropper’ı, süreci başlatmak için altı farklı PHP fonksiyonunu sırayla deniyor, ardından implant’ı indirip çalıştırıyor.
İmplantın izi, log zehirlenmesi ve cron ile yeniden doğması
Sansec’in yayımladığı göstergelere göre implant, bir Linux çekirdek iş parçacığını andıran [kworker/u:8:0] adını kullanarak arka planda saklanıyor. Dosya, site kullanıcısının home dizini altında ~/.local/share/.gvfsd/gvfsd-user yoluna yerleştiriliyor; web kök dizininde değil. Ayrıca her beş dakikada bir yeniden başlatan bir cron girdisi kuruyor.
Disrex, ikili dosyayı yaklaşık 1,9 MB boyutunda, x86-64 ve arm64 için derlenmiş, küçültülmüş ve statik bağlı bir Rust programı olarak tanımladı. Şirketin bulgularına göre cron girdisi doğrudan /var/spool/cron/crontabs/ altındaki spool dosyasına yazılıyor; bu yüzden sistem günlüklerinde crontab değişimi görünmüyor. Bir mağazada aynı satır 1.728 kez bulunurken, implant silinmesinin ardından bir saniye içinde satırı yeniden ekledi.
İki mağazadan birinde implant dışarıya hiç bağlantı kurmadı. Disrex, implantın mağazanın kendi Redis örneğine 6379 numaralı port üzerinden 28 bağlantı açtığını ve Magento’nun oturum verilerini buradan okuduğunu söyledi. Şirketin, implant canlı durumdayken aldığı iki ayrı ağ yakalamasının her biri 200 MB’nin üzerindeydi ve ikisinde de Sansec’in paylaştığı indirme hedefine ya da komuta-kontrol adresine tek bir paket bile gitmedi.
Disrex’e göre her mağaza tek bir site sahibine atanmış izole hesapta çalışıyordu, sudo yetkisi yoktu ve başka bir müşteriye giden yol bulunmuyordu. İmplant, ayrıcalıksız site kullanıcısı olarak çalıştı ve o mağazanın dışına çıkamadı. Şirket, yanal hareket tespit etmediğini ve platformunda başka etkilenen site bulunmadığını da bildirdi.
Her iki mağaza da ilk temastan yaklaşık on bir ve on dört saat sonra aynı gün içinde kontrol altına alındı. Disrex, veri sızıntısına dair kanıt, sahte yönetici hesabı, enjekte edilmiş ödeme skimmer’ı ya da veritabanı backdoor’u bulmadığını söyledi. Tüm oturumlar iptal edildi ve ihtiyaten kimlik bilgisi rotasyonu başlatıldı.
Barındırdığı Magento mağazalarını kendi platformunda tuttuğu ve ilk ihlali hızlı yakaladığı için Disrex, tüm ortamını bir saat içinde taradığını ve ikinci mağazayı aynı öğleden sonra bulduğunu aktardı. Şirket ayrıca olayla ilgili ayrı bir inceleme yazısı da yayımladı.
Sansec, Shield müşterileri için kuralları devreye girmeden önce saldırıya uğrayan mağazalarda backdoor’un gerçekten kullanıldığına dair bir işaret görmediklerini, buna rağmen süreç tespit edilen her yerde Magento kimlik bilgisi rotasyonu yapılmasını önerdiklerini belirtti.
Disrex’in bulgularında log zehirlenmesi iki farklı yerde ortaya çıkıyor. Sansec’in yayımladığı kontrol, var/report/ dizininde X_TRACE_ işaretini arıyor. Disrex ise iki enfeksiyonun da var/log/system.log üzerinden zehirlendiğini, bu nedenle yalnızca rapor dizinini tarayan kontrolün ikisini de kaçıracağını söyledi. Şirket, hem var/report/ hem de var/log/system.log dizinlerinin aranması gerektiğini vurguladı.
İmzalardaki desen de saldırı boyunca değişmiş görünüyor. Disrex, 5 Eylül sabahı X-TRACE- ile başlayan ve ardından on hex karakter gelen bir tetik başlığı gördüğünü, öğleden sonra ise aynı başlığın TRACE kelimesi olmadan kullanıldığını yazdı. Bu yüzden aramanın tam dizeye değil, biçime göre yapılması gerektiğini belirtti.
Bir include işleminin hemen ardından system.log içinde integer argümanla gelen array_merge() TypeError’ı, istismarın başarılı olduğuna dair işaretlerden biri olarak gösterildi. Ancak Disrex, daha sessiz bir varyantın boş dizi döndürdüğünü ve günlükte hiçbir iz bırakmadığını da ekledi.
Süreç denetiminde de görünüm yanıltıcı olabiliyor. Disrex’e göre gerçek bir kernel thread root tarafından sahiplenilir ve resident belleği olmaz; buna karşılık site kullanıcısına ait, köşeli parantezli bir adla çalışan ve gerçek bellek tüketen süreç implanttır. İmplant, komut satırını doğrudan bu köşeli ifadeye ayarlıyor; bu yüzden comm alanına göre yazılmış bir kontrol hiçbir şeyi yakalamıyor.
Şirket, mağazalardan birinde bellek içindeki ikilinin disk üzerindeki dosyadan farklı bir derleme olduğunu da tespit etti. Bu nedenle hem dosyanın kendisini hem de /proc/<pid>/exe üzerinden çalışan sürecin hash’inin alınmasını önerdi. Ayrıca “Payment Transaction Failed Reminder” e-postalarında ani artışların da inceleme nedeni olması gerektiğini, ancak meşru reddedilen ödemelerin de aynı bildirimi üretebileceğini kaydetti.
Disrex’in iki vakasından biri tam da bu e-posta sayesinde görünür oldu. Şirketin kurucu ortağı Rick Bouma, mağazanın kendi sahibine gönderdiği başarısız işlem bildiriminde şablon değişkenlerinin çözülmediğini, gövdenin ham {{var …}} etiketleriyle dolu olduğunu, müşteri adresinin .invalid alan adı taşıdığını ve toplam tutarın sıfır göründüğünü anlattı. Bouma’ya göre bu, bozuk bir sipariş gibi görünüyordu; gerçekte ise Magento’nun şablon filtresinden geçen istismar girişiminin çıktısıydı. Mağaza sahibinin bu e-postayı iletmesi, implantı bir saat içinde ortaya çıkaran incelemeyi başlattı.
Disrex, aynı e-postanın anonimleştirilmiş bir kopyasını erken uyarı notunda paylaştı. Notta, Magento’nun “an error occurred generating this content” yedek metninin adres bloğu içinde görünmesi üçüncü belirti olarak da işaretleniyor. Şirket, bu e-postayı tüccarlar için en yararlı erken uyarı işareti olarak tanımlıyor; çünkü fark edilmesi herhangi bir araç gerektirmiyor.
Sansec ile Disrex’in paylaştığı göstergeler arasında [kworker/u:8:0] süreci, root olmayan kullanıcıya ait olma durumu, ~/.local/share/.gvfsd/gvfsd-user dosyası, ~/.local/share/.gvfsd/.gvfsd_<8hex>.lock, /tmp/.gvfsd_<8hex>.lock, /tmp/.kw_<random><random> dosyası, */5 * * * * exec <home>/.local/share/.gvfsd/gvfsd-user cron satırı ve /tmp/.kw_ ile başlayan varyant yer alıyor.
Sansec ayrıca eComscan tarayıcısını implantı yakalamak için önerdi ve 1.9.7 sürümünün Shield müşterilerinde süreci sonlandıracağını söyledi. Ancak Disrex, Store A üzerinde temiz sonuç aldığını bildirdi. eComscan, 5 Eylül UTC 10.00’da, implantın ilk kez çalışmasından yaklaşık on bir saat sonra ve 1.728 cron satırı hâlâ sistemdeyken tarama yaptı; yine de mağazayı temiz olarak raporladı. Disrex’e göre sorun tarayıcıda değil, tarama kapsamındaydı: planlı tarama mağazanın document root’una yöneltilmişti, oysa implant hesap ana dizininin bir klasör üstüne, home dizini altına yerleşmişti. Şirket tarama yolunu genişlettiğini ve eComscan derleme numarasını ayrıca doğrulayacağını söyledi.
Sansec’in listelediği teknik göstergeler arasında e315687a1dfe61ef4a5a5642214db6d3b2b05d81391285eebc2af664641a26a7 SHA-256 değerli örnek, Disrex mağazalarında diskte görülen 8334b434fa3fe9f59cebe9609b11e0b1fd19d10212c45c705adec1902a1d06ef hash’i ve mağazalardan birinde bellekte çalışan 251fabd50d7b18a8b5e1b3ef5d64e7198c17244778f6461fb1ab07f6169bf220 hash’i de bulunuyor. Sansec’in işaret ettiği indirme alanı 247.cdnflare[.]xyz, komuta-kontrol adresi ise 99.84.67[.]186:443. Şirket, saldırgan kaynak IP’leri olarak 88.216.72[.]181 adresini verdi. Disrex ise toplu trafik gönderen 5.181.86[.]133 adresini ayrıca kayda geçirdi.
Adobe tarafından bir yama yayımlanana kadar resmi seçenekler sınırlı kalıyor. Disrex, nginx ve Apache için URL sorgu dizgesindeki istismar parametrelerini engelleyen kurallar paylaştı; ancak aynı parametrelerin POST gövdesi ya da JSON gövdesi içinde sunucuya ulaşabildiğini, çünkü bu iki sunucunun yalnızca query string’i incelediğini de test etti. Şirket, bu kuralların zafiyetin kendisini değil, kampanyanın o anki yürütülme biçimini durdurduğunu söylüyor.
Disrex’in ana azaltma yöntemi, Magento’nun bağımlılık enjeksiyon kod tarayıcılarındaki üç metoda bir kontrol ekliyor ve bu metodların komut satırı dışında çalışmasını engelliyor. Ancak elle yapılan bu düzenleme her composer install işlemiyle geri döndüğü için şirket, aynı değişikliği composer-patches kaynak yaması olarak da yayımladı. Disrex’e göre bu yama 2.4.6’dan 2.4.9’a kadar değişmeden uygulanıyor.
Üç dosyadan biri olan ClassesScanner.php, en az bir üçüncü taraf modül tarafından HTTP üzerinden çağrılıyor. Disrex, mageplaza/module-admin-permissions modülünün bu dosyayı kullandığını ve burayı korumanın modülün yönetim ekranını bozduğunu belirtti. Bu nedenle yöneticilere, dosyaya dokunmadan önce vendor dizininde kontrol yapmaları tavsiye edildi.
Koruma, çalışan bir mağaza yerine test düzeneğinde sınandı ve Disrex bunun tek başına tam bir düzeltme olmadığını söylüyor. GitHub kullanıcısı ProxiBlue da 5 Eylül’de aynı üçleme için üç resmi olmayan yama yayımladı. Bouma, ProxiBlue’nun, yani Magento geliştiricisi Lucas van Staden olarak tanımladığı kişinin, aynı üç scanner metodunda, aynı PHP_SAPI !== ‘cli’ kontrolüyle ve aynı istisna mesajıyla bağımsız biçimde aynı korumaya ulaştığını aktardı.
Disrex, ProxiBlue’nun üç yamasını kendi deposunda kredi vererek yeniden yayımladı ve iki çözümün üst üste uygulanmaması gerektiği uyarısını ekledi. Şirket, iki ayrı tarafın bağımsız biçimde aynı düzeltmeye ulaşmasını, seçilen yolun doğruluğuna güçlü bir teyit olarak görüyor. Sansec de Adobe de bu tarayıcıların saldırı zincirinin son noktası olduğunu henüz doğrulamadı.
Graycore, LLC de 5 Eylül’de GitHub ve Packagist üzerinde bir Magento modülü yayımladı. Şirketin aktardığına göre mevcut kod, zincirdeki üç noktayı sertleştiriyor: e-posta şablonu blok direktifi backend bloklarını reddediyor, grid satırı URL üreticisi oluşturma öncesi sınıf denetimi yapıyor ve Web API fatal error raporlarındaki PHP açılış etiketleri bozuluyor. Ancak Packagist’te o sırada bulunan sürüm daha eskiydi ve yalnızca kaldırılmış bir PayPal GraphQL resolver’ına yönelik bir önlem içeriyordu. README dosyası bunun bir sertleştirme olduğunu, düzeltme olmadığını açıkça yazıyor ve başka yolların hâlâ açık olabileceği ile mağazanın zaten ele geçirilmiş olabileceği uyarısını yapıyordu.
Disrex’e göre yamayı bilmeden de uygulanabilecek iki sunucu ayarı var. Şirketin iki mağazasından birinde dropper’ın denediği altı PHP fonksiyonunun ilk dördü devre dışıydı; proc_open ise açık bırakılmıştı ve dropper implantı başlatmak için onu kullandı. open_basedir ayarının da çocuk süreci sınırlamadığı görüldü. Bu nedenle şirket, proc_open fonksiyonunun disable_functions listesine eklenmesini ve /tmp, /var/tmp ile /dev/shm dizinlerinin noexec ile bağlanmasını, indirilmiş bir ikilinin çalışmasını engelleyen katmanlar olarak öne çıkarıyor.
Zaten enfekte olmuş bir mağaza için hazırlanan temizleme rehberinde Disrex, önce kanıtı korumayı, cron girdisini süreci öldürmeden kaldırmayı, sistemi yeniden başlatmamayı ve composer install çalıştırmamayı öneriyor. Rehbere göre yeniden başlatma, /proc altında kalan kopyanın tek kalan ikili olmasına yol açabiliyor; composer install ise dokunulan dosyaların zaman damgalarını üzerine yazabiliyor. Ardından oturum depolaması boşaltılıyor, app/etc/env.php içindeki crypt/key ile birlikte tüm yönetici parolaları, ödeme sağlayıcı API anahtarları ve dosyada yer alan diğer entegrasyon kimlikleri değiştiriliyor.
Nexcess ve Liquid Web de 5 Eylül’de benzer içerikte olay bildirimleri yayımlayarak sunucu ortamlarını gözden geçirdiklerini ve ihtiyati tedbirler uyguladıklarını açıkladı. Şirketlerden hiçbiri doğrulanmış müşteri ihlali ya da açığın kendi sistemlerinde yeniden üretildiğini iddia etmedi. Disrex, kendi mağazalarındaki nginx erişim günlüklerinden ayıklanmış toplam 26 farklı kaynak adresi kaydettiğini söyledi; bunların ikisi toplu trafik gönderen barındırma altyapısı, kalanı ise her biri iki ile altı istek arasında değişen bir residential proxy havuzu oldu. Şirket, Sansec’in bildirisinde adı geçen tek saldırgan adresin engellenmesinin gördüğü trafiğin dörtte birinden azını durduracağını da belirtti. Daha önceki 28 sayısı, müdahale sırasında doğrulama amaçlı istek gönderen Disrex’e ait iki sunucuyu da içeriyordu. Kaynaklardan hiçbiri saldırganların kimliğini açıklamadı.
Adobe, Sansec ve Graycore’dan yorum istendiği, yanıt gelirse haberin güncelleneceği bilgisi de paylaşıldı. Yayın sonrası yapılan güncellemeye göre Disrex Group’tan Rick Bouma, mağazaların sürüm bilgilerini, Shield durumunu ve ilk temas saatlerini düzeltti; eComscan’in neden kaçırdığını açıkladı; vakalardan birini ortaya çıkaran erken uyarı e-postasını tarif etti; ProxiBlue’nun yamalarının da Disrex deposuna sonradan eklendiğini ve bunun bağımsız biçimde bulunduğunu doğruladı.