Magento BlockStrap (CVE-2026-103849): tespit, yama kontrolü ve müdahale

Kod çalıştırmaya giden kimlik doğrulamasız bir yol

dev.to'da yayımlanan bir yazı, CVE-2026-103849 olarak takip edilen Magento'daki kimlik doğrulaması gerektirmeyen uzaktan kod çalıştırma açığı BlockStrap'ın istismarının nasıl tespit edileceğini ve buna nasıl yanıt verileceğini adım adım anlatıyor. Hata, anonim bir saldırganın Magento bir e-postayı oluştururken bir {{block}} direktifinin çözülmesini sağlamasına imkân veriyor; kullanılabilir bir block ve method eşleştiğinde bu çözümleme, web sunucusunun izinleriyle PHP çalıştırıyor.

Saldırı zinciri

Yazıya göre payload, sıradan misafir GraphQL işlemleriyle taşınıyor: boş bir sepet oluşturuluyor, misafir bir e-posta adresi ekleniyor, biçimlendirme alanları payload içeren bir fatura adresi gönderiliyor ve ardından Magento'nun ödeme hatası e-postası üretmesi için reddedilmiş bir Payflow Pro yanıtı tetikleniyor. İç içe geçmiş adres biçimlendirmesi direktifi etkisiz tutuyor ve gönderim anında imzalıyor; direktifi çözen ve kodu çalıştıran ise sonraki e-posta geçişi oluyor.

Kanıt nerede aranmalı

Fatura adresi belirleyen ve ardından reddedilmiş bir ödemeyle devam eden misafir GraphQL oturumları checkout sırasında normaldir; bu nedenle yalnızca varlıkları tek başına bir şey kanıtlamaz. Belirleyici işaret, bir adres biçimlendirme alanına, bir ad alanına ya da e-posta oluşturmaya yönelik başka herhangi bir diziye gömülü bir block veya template direktifidir.

Payload, hata e-postası oluşturulduğu anda çalıştığından, giden postalar güvenlik ihlalini ortaya çıkarabilir. Yazarın en net kanıtı, teslim edilmiş bir e-postadaki, hiçbir istemci isteğinde hiç bulunmayan bir değerdir — bunu gönderen değil, oluşturma motoru üretmiştir.

Günlük analistleri ayrıca aldatmacalara hazır olmalıdır. registerUndefinedFilterCallback çağıran Twig payload'ları ve bxss.me'ye yapılan callback'ler, Magento'nun içinde sunmadığı bir template motorunu yoklayan tarayıcılardan gelir; yazı bunların BlockStrap olmadığını ve gerçek sinyalin görünür kalması için filtrelenmesi gerektiğini vurguluyor.

Dosya ve süreç göstergeleri

Makalede alıntılanan herkese açık doğrulama laboratuvarı, bir exploit aracına ihtiyaç duymayan bir yan etkiyi belgeliyor: stok Magento\Backend\Block\Widget\Grid\Extended block'unu dispatch etmek ve getCsvFile() metodunu çağırmak, koleksiyon eksikliğinden dolayı başarısız olmadan önce var/export/ dizinine rastgele adlandırılmış, 32 onaltılık karakterli bir .csv dosyası bırakıyor; dosyanın içeriği EF BB BF 0A olmak üzere dört bayt. Bu nedenle izleme, o dizinde hiçbir yönetici dışa aktarımıyla eşleşmeyen, açıklanamayan küçük yeni dosyaları işaretlemelidir.

Tam komut çalıştırmanın belirtileri daha geniştir: PHP-FPM pool kullanıcısı olarak çalışan beklenmedik alt süreçler, web katmanından giden bağlantılar, pub/media veya var/ altındaki yeni dosyalar, app/etc/env.php üzerindeki değişiklikler ve kimsenin planlamadığı cron kayıtları. Yöneticilerin ayrıca SSH erişimi olduğu durumlarda yazı, süreç başlangıç zamanlarının ödeme hatası e-postalarının zaman damgalarıyla karşılaştırılmasını öneriyor.

Düzeltmenin gerçekten uygulandığını doğrulamak

Ekim yaması, vendor/magento/framework/Filter/Template.php dosyasına resolveDeferredDirectives metodunu ekliyor — Mage-OS'ta aynı kontrol vendor/mage-os/framework/Filter/Template.php için geçerli — bu yüzden o dosyaya karşı grep -c resolveDeferredDirectives komutu yalnızca düzeltme kuruluyssa sıfır olmayan bir değer döndürür.

İki ek kontrol daha gerekiyor. Eylül'deki StyleSmuggler acil düzeltmesi Ekim yamasına dahil edilmedi ve Adobe'un yama kayıt defterinde ön koşul olarak listelenmiyor; bu nedenle vendor/bin/magento-patches -n status ile ayrıca doğrulanmalı. Ayrıca Magento Open Source 2.4.8-p5 sürümünde, ilk zip dosyası CVE-2026-91013 için gereken bir EmailAddress.php değişikliğini atladı; Adobe dosyayı 14 Ekim 2026'da değiştirdi ve eksik değişikliği 248p5-2026-10-002-CE olarak yayımladı. vendor/magento/framework/Validator/EmailAddress.php dosyasında grep -c QUOTED_LOCAL_PART_PATTERN sıfır döndürüyorsa, o ikinci dosya hâlâ gereklidir.

Olay müdahale ekipleri zararsız bir tuhaflığa da hazır olmalı: Ekim yaması, lock dosyalarını lock adının SHA-256 hash'iyle adlandırıyor; bu yüzden /var/.regenerate.lock, Magento kök dizininde 976bc24c08055e67a58cf491401c8b2f3d48ff55b8092f1ede196bac4756a228 olarak görünüyor. Yamanmış her mağazada bu boş dosya vardır ve güvenlik ihlali göstergesi değildir.

İzolasyon ve yama sırası

Kod çalıştırma doğrulandığında izolasyon adli incelemeden önce gelir: veritabanı kimlik bilgilerini, ödeme ağ geçidi anahtarlarını ve yönetici parolalarını mağazanın dışındaki bir makineden değiştirin ve web katmanı günlüklerini yeniden oluşturmadan önce saklayın. Sansec, eksik yamayı işaretlemek ve arka kapıları aramak için eComscan aracını öneriyor.

Yama tamamlanana kadar trafik kapalı kalmalıdır. Satıcının öncelik 2 derecelendirmesi nominal olarak 30 gün tanıyor; ancak yazıda Adobe'un APSB26-153 bülteni ve BleepingComputer'ın haberleriyle birlikte alıntılanan Sansec, bu sürenin gerçeği küçümsediğini savunuyor: firma, yamanın yayımlanmasından sonraki bir gün içinde dört çalışan saldırı rotasını yeniden üretti; buna karşılık yayım anında canlı mağazalarda istismar gözlemlenmemişti.

Neden önemli

BlockStrap kimlik bilgisi gerektirmiyor, sıradan checkout trafiğinin içinde saklanıyor ve her mağazanın çalıştırdığı bir alt sistemden — işlem e-postalarından — tetikleniyor. İzleri olağandışı yerlerde duruyor: mesaj gövdelerinde, var/export/ dizininde ve bariz webshell dosyaları yerine süreç tablolarında. Giderilmesi de tek bir zip dosyası değil; çünkü Ekim yaması, Eylül'deki StyleSmuggler acil düzeltmesi ve yeniden yayımlanan 2.4.8-p5 dosyasının her biri bağımsız doğrulama gerektiriyor. Satıcılar için satıcının 30 günlük süresi bir plan değil, üst sınır olarak ele alınmalıdır.