PrestaShop Debug Mode Açığı, Back-Office Hesaplarının Config Dosyalarına PHP Enjekte Etmesine İzin Veriyordu

CERT/CC, 9 Kasım 2026'da, PrestaShop'un Debug modundaki bir PHP kod enjeksiyonu açığı için VU#385711 numaralı güvenlik bültenini yayımladı; Debug modu, geliştiricilerin sorunları teşhis etmesine yardımcı olmak için tasarlanmış bir back-office kolaylığıdır. Danışmanlık hakkında dev.to'da yayımlanan bir yazıya göre, yönetim arayüzü üzerinden girilen değerler, uygulamanın sonraki isteklerde yüklediği çalıştırılabilir kaynak koda dönüşebiliyor. PrestaShop 9.2.1 sorunu gideriyor ve satıcı danışmanlığı açığı CVE-2026-124916 olarak takip ediyor.

Enjeksiyon nasıl çalışıyor

Back office'in Performance bölümündeki Debug mode ekranı altında bir yönetici, bir debug cookie adı ve değeri belirleyebiliyor. dev.to'nun açıkladığı gibi PrestaShop, her iki değeri bir PHP ifadesine gömüyor ve sonucu config/defines.inc.php ya da config/defines_custom.inc.php içinde bir define() ifadesi olarak kaydediyor.

Tasarım, iki girdinin hareketsiz dizgiler gibi davrandığını varsayıyor. Bülten, uygulamanın bunları PHP kaynağı olarak kaçış karakteriyle işlemekten kaçındığını ortaya koydu; bu yüzden özenle hazırlanmış bir değer, hedeflenen dizgi değişmezini sonlandırıp saldırganın seçtiği bir PHP ifadesini ekleyebiliyor. Değiştirilen yapılandırma dosyası başlatma sırasında okunduğu için, enjekte edilen ifade sonraki her isteğin normal yaşam döngüsüne yerleşiyor.

Bir saldırganın neye ihtiyacı var

Açık, anonim ziyaretçiler tarafından kullanılamaz. dev.to'da özetlenen bültene göre sömürü için şunlar gerekiyor:

• Debug mode ayarlarını değiştirme izni olan, kimliği doğrulanmış bir back-office hesabı.
• PHP sürecinin yapılandırma dosyasına yazma erişimi. Root erişimi gerekmiyor.
• CSRF koruması burada bir savunma sağlamıyor: başka bir yöneticinin tarayıcısı üzerinden sahteştirilen istekleri engeller, gerekli izne sahip bir hesabı zaten elinde tutan saldırganı değil.

Enjekte edilen kod nelerden faydalanabilir

Bir kez yazıldığında, eklenen ifade PHP sürecinin ayrıcalıklarıyla çalışır; bu ayrıcalıklar tipik olarak veritabanı kimlik bilgilerine, uygulama sırlarına, müşteri kayıtlarına, yüklenen dosyalara ve yazılabilir uygulama koduna uzanır. Bir saldırgan ayrıca ödeme akışını ya da diğer mağaza işlemlerini de aksatabilir.

Bülten PHP kod çalıştırmayı root erişimiyle eşdeğer görmüyor ve yöneticiler de öyle varsaymamalı. İşletim sistemi komutlarının çalıştırılıp çalıştırılamayacağı PHP yapılandırmasına ve etkinleştirilmiş fonksiyonlara bağlıdır; anındaki sınır web uygulaması hesabı olarak kalır.

dev.to, bunun sıradan bir ayar hatasından fazlası olduğuna dair iki neden vurguluyor. Yalnızca mağaza işlemleri için tasarlanmış bir hesap, kazayla yapılandırma yapabilen izinleri devralabilir ve mağazalar sorun gidermeden sonra Debug modunu açık bırakmayı yaygın biçimde sürdürür; bu da bir geliştirme kolaylığını üretim ortamındaki back office içinde kalıcı olarak açığa çıkarır.

Giderim

PrestaShop 9.2.1 açığı gideriyor. Yöneticiler, çalışan sürümlerinin envanterini çıkarmalı ve etkilenen kurulumları 9.2.1 veya sonrasına yükseltmelidir.

Hemen yükseltmenin mümkün olmadığı durumlarda dev.to, Performance ve Debug mode ayarlarını değiştirebilecekleri güvenilen az sayıda yöneticiden oluşan küçük bir grupla sınırlandırmayı, mümkünse back-office erişimini ağ politikasıyla kısıtlamayı ve —meşru yapılandırma değişikliklerini engelleyebileceği için önce dikkatle test edilerek— PHP sürecinin config/defines.inc.php ve config/defines_custom.inc.php dosyalarına yazma erişimini kaldırmayı öneriyor.

Yöneticiler ayrıca bu dosyaları, debug cookie tanımlarının yakınındaki yabancı PHP ifadeleri açısından incelemeli ve bilinen iyi bir dağıtımla karşılaştırmalı (diff). Yapılandırma haklarına sahip herhangi bir hesap ele geçirilmiş olabilecekse, uygulama sırları yenilenmelidir; çünkü enjekte edilmiş kod ortam değerlerini ve uygulama dosyalarını okumuş olabilir. dev.to ayrıca yüklü sürümün, açıkta olan yönetim adreslerinin ve Performance ayarlarını değiştirebilen hesaplar kümesinin kaydedilmesini öneriyor.

Neden önemli

Açık, hiçbir bellek bozulması sömürüsü olmadan, bir back-office ayarlar ekranı ile keyfi PHP çalıştırma arasındaki mesafeyi sıfıra indiriyor — gereken yalnızca mağazaların rastgele dağıtabileceği bir izin ve uygulamanın sonradan dahil ettiği bir dosyaya yazılan filtrelenmemiş bir dizgi. Bu aynı zamanda yinelenen bir anti-pattern'in ders kitabı örneği: nihayetinde kod olarak yazılan yapılandırma değerlerine veri gibi davranmak. Sömürü PHP süreci sınırında dursa bile, o sınır mağazanın veritabanı kimlik bilgilerini, müşteri verilerini ve kaynak kodu barındırıyor. Eski sürümleri çalıştıran mağazalar, 9.2.1 yükseltmesini ve Debug modu izin denetimini tek bir görev olarak görmelidir.