Magento ve Adobe Commerce'te 10 üzerinden 10 puanlık açık: Gerçekte ne oldu

Önce doğrudan cevap: 4 Eylül 2026'da saldırganlar Magento Open Source ve Adobe Commerce'te yaması olmayan bir açığı istismar etmeye başladı. Açık, CVE-2026-75650 olarak kayıtlı ve 10.0 önem puanına sahip; yani mümkün olan en yüksek puan. Açık, mağazanın sunucusunda hiç oturum açmadan ve hiçbir yetki olmadan komut çalıştırmaya imkân veriyor ve Adobe düzeltmesini 7 Eylül akşamı yayımladı. Bu da mağazaların hiçbir koruma olmadan açıkta kaldığı tam üç gün demek. Yamayı kurmanın yetmemesinin sebebi de tam olarak bu: Mağazanız bu platformda çalışıyorsa, güvenli varsayım düzeltme ortaya çıkmadan önce ele geçirilmiş olabileceğinizdir; doğru tepki de güncellemeyi kurup gününüze devam etmek değil, izinsiz giriş belirtilerini aramak ve şifreleme anahtarlarınızla tüm kimlik bilgilerinizi değiştirmektir.

Tam olarak kimler etkileniyor

Liste alışılmadık derecede geniş, çünkü keşif anında mevcut olan en yeni sürümü de kapsıyor:

  • Magento Open Source ve Adobe Commerce: Ağustos 2026'ya kadarki tüm yama güncellemeleri dahil 2.4.4 ile 2.4.9 arası sürümler.
  • Adobe Commerce B2B: Ağustos 2026 güncellemesine kadar 1.3.3 ile 1.5.3 arası sürümler.
  • 2.4.4'ten eski her şey: zaten destek dışı ve resmi hotfix kapsamadığı için en tehlikeli kategori.

Açıkça söylemek gerekirse: 1 Eylül itibarıyla tamamen güncel bir Magento çalıştırıyorduysanız, açıktaydınız. Bu, genellikle uyardığımız tanıdık ihmal senaryosu değil; kimsenin önüne geçme imkânı olmayan gerçek bir zero-day.

Saldırı parola olmadan nasıl işliyor

Saldırı iki aşamada ilerliyor ve Magento'nun e-posta şablonu oluşturma özelliğini kötüye kullanıyor. İlk aşamada saldırgan, bir ödeme yanıtı yoluna özel hazırlanmış bir istek gönderiyor ve bu isteğin tüm içeriği sunucudaki bir hata raporu dosyasına yazılıyor. İkinci aşamada GraphQL uç noktasına gönderilen bir istek bu zehirlenmiş dosyayı işaret ediyor ve dosyanın içeriği, bir ödeme hatası hatırlatma e-postası hazırlanırken çalışıyor.

Bir işletme sahibinin dikkat etmesi gereken kısım teknik ayrıntı değil, onun ortaya koyduğu şey: Tamamen masum görünen genel erişimli yollar (bir ödeme altyapısı yanıtı, vitrin için bir sorgu uç noktası, otomatik bir e-posta) bir araya gelerek sunucuya giden eksiksiz bir yol oluşturdu. Ciddi güvenlik açıkları nadiren ardına kadar açık tek bir kapıdır; çok daha sık, her biri tek başına son derece makul görünen küçük kapılardan oluşan bir zincirdir.

Saldırganlar içeri girdikten sonra ne yerleştirdi

Bir vandal ile organize bir operasyon arasındaki fark burada ortaya çıkıyor. Gözlemlenen zararlı yükler gürültülü fidye yazılımı notları değil, sessiz kalıcılık araçlarıydı:

  • Rust ile yazılmış bir arka kapı; işletim sisteminin çekirdek süreçlerinden biri kılığına giriyor, böylece süreç listesine göz gezdiren kimsenin dikkatini çekmiyor.
  • Kamufle edilmiş komuta ve kontrol trafiği; zaman senkronizasyonu portu üzerinden akıyor, böylece etkinlik ağ kayıtlarında rutin saat ayarı gibi görünüyor.
  • PHP web shell'leri; ürün görseli önbellek klasörlerinin içine yazılmış. Buralar geçici dosyalarla dolu olduğu için normalde kimsenin incelemediği yerler.
  • Ek uzaktan erişim araçları; ilgisiz araçlar kullanan ikinci bir saldırgana ait. Yani açık aynı anda birden fazla grup tarafından istismar ediliyordu.

Bilinen bir çevrimiçi mağazadaki bu tür yüklerin amacı siteyi çökertmek değil, uzun süre kalmak ve sipariş ile ödeme verilerini geçerken okumaktır. Enfekte bir mağaza tamamen normal şekilde çalışmaya devam eder; işin tedirgin edici yanı da budur.

Güncellemeyi kurmak neden yeterli değil

Çünkü bir saldırgan 7 Eylül'den önce içeri girdiyse, artık şifreleme anahtarlarınızın ve kayıtlı kimlik bilgilerinizin bir kopyası onda. Yama, onun girdiği kapıyı kapatır; onu içeriden çıkarmaz. Adobe'nin kendi rehberi bu konuda açıktı: düzeltmeyi uygulayın ve ardından şifreleme anahtarlarını, yönetim paneli parolalarını, API token'larını, ödeme altyapısı kimlik bilgilerini, veritabanı parolalarını ve sunucu erişim anahtarlarını değiştirin.

Yama kanamayı durdurur. Davetsiz misafiri evden çıkaran şey anahtarları değiştirmektir.

Mağaza sahibi için pratik bir eylem planı

  • Birinci: düzeltmenin gerçekten kurulduğunu doğrulayın; birinin kurulduğunu söylemesiyle yetinmeyin. Ekibinizden güven verici bir mesaj değil, doğrudan sunucudaki yama kaydından kanıt isteyin.
  • İkinci: izinsiz giriş izlerini arayın: adları sistem süreçlerini taklit eden şüpheli çalışan süreçler, medya ve görsel klasörlerindeki PHP dosyaları ve olağandışı hata raporu dosyaları.
  • Üçüncü: giden e-posta kaydını inceleyin. Ödeme hatası hatırlatma e-postalarındaki ani bir artış, istismar girişimlerinin doğrudan göstergesidir ve her operasyon sorumlusu bunu derin güvenlik uzmanlığı olmadan okuyabilir.
  • Dördüncü: istisnasız her anahtarı değiştirin, en başta ödeme altyapısı kimlik bilgilerini. Bunun için yoğun saatlerde doğaçlama bir karar değil, planlanmış bir bakım penceresi gerekir.
  • Beşinci: sürümünüz 2.4.4'ten eskiyse, gelmeyecek resmi bir yamayı beklemeyi bırakın. Gerçek bir tarihe bağlı bir yükseltme planı belirleyin ve bu arada mağazayı bir web uygulaması güvenlik duvarının arkasına alın.
  • Altıncı: yaptıklarınızı belgeleyin. Müşteri verilerinin sızdığı ortaya çıkarsa, neyi ne zaman yaptığınızı gösteren bir zaman çizelgesine ihtiyacınız olacak.

Suudi Arabistan'daki düzenleyici boyut: Müşteri verileri yalnızca teknik bir mesele değil

Müşterilerin adlarını, adreslerini, cep telefonu numaralarını ve sipariş geçmişini tutan bir çevrimiçi mağaza, Kişisel Verilerin Korunması Kanunu kapsamındaki kişisel verileri işliyor demektir. Bir ihlal, mağaza ile barındırma sağlayıcısı arasında iç mesele olarak kalmaz; yetkili makama ve veri sahiplerinin kendilerine karşı yükümlülükler doğurur. Bu yüzden bir mağaza sahibinin bugün sorması gereken soru yalnızca "sunucuya yama yapıldı mı" değil, "müşterilerimin verilerine dokunulmadığını kanıtlayabilir miyim" sorusudur.

Mağazanız Salla veya Zid gibi yönetilen bir bulut platformunda çalışıyorsa, bu belirli açığın kapsamı dışındasınız; çünkü platforma yama yapmak sizin sorumluluğunuz değil. Ancak aynı ders, mağazanıza bağladığınız her eklenti veya üçüncü taraf entegrasyonu için de geçerli: Yama sorumluluğu, sunucunun sahibi kimse ona aittir.

Origami'de bu tür olayları nasıl ele alıyoruz

Müşteri sistemlerini üzerine kurduğumuz ilke şudur: Bir güvenlik olayı uzak bir ihtimal değil, ertelenmiş bir olaydır. Pratikte bu üç anlama gelir: kimlik bilgilerinin kod tabanının dışında, ayrı bir kasada tutulması, böylece onları değiştirmek bir haftalık bir proje değil dakikalık bir iş olur; operasyon kayıtlarının sunucunun kendisi dışında saklanması, böylece bir saldırgan kendi izlerini silemez; ve yalnızca planlanmış değil, geri yüklenerek gerçekten test edilmiş yedekler.

Özel bir teknik ekibi olmayan bir Magento mağazası işletiyorsanız, bugün atılacak doğru adım basit: Barındırma sağlayıcınızdan veya teknik ortağınızdan yalnızca üç soruyu yanıtlayan yazılı bir rapor isteyin: Düzeltme tam olarak ne zaman kuruldu, ele geçirilme taraması ne buldu ve anahtarlar değiştirildi mi. Bu üç soru, bir teknik ortağın hazırlığı hakkında herhangi bir sunumdan daha fazlasını ortaya koyar.

Kaynaklar

  • Adobe Commerce'in APSB26-146 güvenlik güncellemesi ve acil hotfix hakkındaki resmi duyurusu: experienceleague.adobe.com
  • Sansec'in CVE-2026-75650 ve ele geçirilme göstergeleri hakkındaki teknik analizi: sansec.io/research/stylesmuggler-0day
  • CISA Bilinen İstismar Edilmiş Güvenlik Açıkları kataloğu: cisa.gov
  • Kişisel Verilerin Korunması Kanunu (PDPL) — Suudi Veri ve Yapay Zekâ Otoritesi (SDAIA): sdaia.gov.sa