PHP, 'internet düzeyinde' yüksek riskli bir güvenlik açığını ortaya çıkardı; Web3'ün 'off-chain zayıf noktası' nasıl ele alınmalı?

Orijinal başlık: «PHP, 'İnternet Düzeyinde' Kritik Güvenlik Açığını Ortaya Çıkardı: Web3'ün 'Off-Chain Yumuşak Noktası' Nasıl Düzeltilecek?» Orijinal yazar: SlowMist Güvenlik Ekibi

Ne Oldu?

21 Ekim'de PHP projesi, kimlik doğrulaması olmayan uzaktan kod yürütmesine (RCE) yol açabilen iki kritik güvenlik açığını düzeltmek için acil bir güvenlik güncellemesi yayınladı: CVE-2026-109618 ve CVE-2026-109619; her ikisi de CVSS v4.0 puanıyla 9,2 olarak derecelendirildi. PHP resmi açıklamasında, düzeltme öncesi dış web hizmetleri sağlayan tüm PHP kurulumlarının etkilenebileceğini belirtti.

20 Ekim'de güvenlik açığı ayrıntıları resmi duyuru öncesinde sızdırıldı ve düzeltme henüz yayınlanmamıştı. PHP güvenlik ekibi, acil sürümü orijinal planlanan 22 Ekim yerine 21 Ekim saat 14:00 (UTC)’ye kaydırmak zorunda kaldı.

Daha da alarm verici olan, saldırıların duyurudan önce başlamış olabileceği yönünde raporlar. Amazon’un tehdit istihbarat ekibi, kamuya duyurulmadan dört gün önce, yani 17 Ekim’de php2shell hedef alan saldırı denemelerini kendi MadPot balıkçılık ağılarında gözlemlediğini bildirdi.

SlowMist ayrıca PHP’in resmi erken uyarı sonrası derhal güvenlik hatırlatmaları ve öneriler yayınladı.

Bu İki Güvenlik Açığı Nedir?

CVE-2026-109618 (OOM Bellek Bozulması): PHP bellek tükenince işlem akışı kesilir ve eldeki veri yalnızca yarı hazırlanmış olur. Temizleme sırasında PHP, bu yarı bitmiş veriyi tamamlanmış gibi değerlendirir ve böylece bellek bozulmasına neden olur.

CVE-2026-109619 (Eski Küresel Durum): Bir istek işlendikten sonra bellek serbest bırakılır ancak ilgili durum 'yerinde kalır'. Aynı işçi süreci bir sonraki isteği aldığında, normal başlatmadan önce bu süresi geçmiş durumu kullanabilir. Yetkililer, bunun PHP-FPM’ye saldırılarda ve uzaktan kod yürütmesinde kullanılabilmesini doğruladı.

Saldırı yoluna göre bu tür güvenlik açıklarının tehlikesi, saldırganların öncelikle bir site hesabı edinmesine, iş katmanı girişine, izinlerine veya API Anahtarı doğrulamasına gerek duymamasıdır. Genel internete açık bir PHP uygulamasına özel bir istek gönderilmesi, web sunucusu işleminin yetkileriyle keyfi kod yürütmesine yol açabilir.

Etkilenen kapsam: PHP 5.4–8.5.11 sürümleri tamamı etkilenmiştir. Düzeltme yapılan sürümler: 8.5.12, 8.4.27, 8.3.36 ve 8.2.35’tir. PHP 8.1 ve önceki sürümler artık düzenli üst akım desteği almamaktadır; bu nedenle normal kanallarla düzeltme beklenmemeli, desteklenen sürümlere geçiş yapılmalıdır.

Neden Tüm Dünya Endişeli?

Çünkü PHP çok yaygın. W3Techs istatistiklerine göre, sunucu tarafı dilini belirleyebilen siteler arasında %69,3’ü PHP kullanıyor. WordPress, WooCommerce ve Magento gibi tanıdık sistemlerin hepsi altta PHP üzerinde çalışıyor.

Ayrıca çeşitli ülkelerin tepkileri sorunu yansıtmaktadır: Hollanda Ulusal Siber Güvenlik Merkezi önlem amaçlı siteleri kapattı; Güney Kore Cumhurbaşkanlığı Ofisi acil siber güvenlik toplantısı düzenledi ve hükümet siber güvenlik uyarı seviyesini yükseltti.

Ayrıca raporlara göre, Kuzey Kore’nin resmi medyası ve devlet portal siteleri dahil olmak üzere neredeyse tüm resmi siteleri 24 saatten fazla süreyle çevrimdışı kaldı; bunun bu güvenlik açığıyla ilişkili olup olmadığı henüz bilinmiyor.

Web3 Üzerindeki Etkisi

Bu, yalnızca geleneksel web sitesi işletimi ve bakımıyla ilgili bir sorun değildir. Web3 için sözleşmeler zincirüstü olarak güvenli olsa bile, sözleşmelerin çevresinde yer alan çok sayıda 'zincir dışı bileşen' — örneğin ön uç sayfaları, API'ler, muhasebe cüzdanları, imzalama hizmetleri, airdrop talep sayfaları, operasyon arka uçları ve veri hizmetleri — genellikle PHP ile (WordPress, WooCommerce, Magento vb.) geliştirilir. Sözleşmelerde güvenlik açığı olmaması, bu bileşenlerin güvenli olduğu anlamına gelmez.

SlowMist’in tehdit istihbarat sistemi MistEye’in yaptığı istatistiklere göre, taradığı 1.488 kripto endüstrisiyle ilgili etki alanında 793’ü doğrudan PHP izi vermiştir; bu oran yaklaşık %53,3’tür. Bunun yalnızca PHP kullanıldığını gösterdiğini, ancak bu sitelerin zaten güvenlik açığı içerdiği ya da saldırıya uğradığı anlamına gelmediği vurgulanmalıdır.

1. Platform tarafı: Yaygın risk yolları

Kullanıcıların imza vermeye ikna edilmesini amaçlayan ön uç değişiklikleri.

DeFi, cüzdan türü web siteleri veya airdrop sayfalarının sunucuları ele geçirildiğinde saldırganlar, sayfadaki RPC adreslerini, yetkilendirme hedeflerini, sözleşme adreslerini veya imzalama uyarılarını değiştirebilir; böylece normal bir işlem zararlı bir yetkilendirme, zararlı sözleşme etkileşimi ya da sahte mevduat sürecine dönüşebilir. Saldırganların sözleşmeyi ihlal etmesine gerek yoktur; kullanıcıların kendilerinin zararlı bir yetkilendirme imzasını vermesini sağlamak yeterlidir.

Anahtar ve kimlik bilgilerinin sızdırılması.

Sunucu ele geçirildikten sonra saldırganlar yapılandırma dosyalarını, veritabanı şifrelerini, API belirteçlerini, ortam değişkenlerini vb. okuyabilir. Arka uç, düğüm RPC’sine veya sıcak cüzdan hizmetlerine PHP ile bağlanıyorsa, API anahtarlarının veya oturum belirteçlerinin sızması sıcak cüzdan varlıklarının aktarılmasına ya da imzalama izinlerinin kötüye kullanılmasına yol açabilir.

Arka uç ve API ele geçirmesi.

Takas platformları, NFT pazarları, çapraz zincir köprüleri, ödeme ağ geçitleri ve düğüm hizmet sağlayıcıları genellikle operasyonel arka uçlara sahiptir; ayrıca KYC/riske karşı kontrol arayüzleri, mevduat adresi tahsisi, çekim incelemesi, bilet sistemleri gibi özelliklere de sahiptir. Yetkiler elde edildikten sonra saldırganlar yapılandırmaları değiştirebilir, kullanıcı verilerini çalabilir, yüksek ayrıcalıklı hesaplar oluşturabilir ya da iş süreçlerini atlayabilir.

Tedariğe dayalı yanlamasına hareket.

PHP işleminin ayrıcalıkları sunucudaki en yüksek ayrıcalıklara eşit olmayabilir; ancak CI/CD anahtarlarını, kapsayıcı çalışma zamanı soketlerini, veritabanı kimlik bilgilerini veya bulut erişim belirteçlerini okuyabiliyorsa, saldırı kapsamı tek bir web düğümünden veritabanlarına, derleme sistemlerine hatta tüm üretim hesabı düzeyine kadar genişleyebilir.

Ödeme eklentileri ve üçüncü taraf hizmetler.

Binance Pay, Crypto.com Pay, BitPay, CoinGate ve CoinPayments gibi kripto ödeme çözümlerinin hepsinin WooCommerce entegrasyonları olduğu bilinmektedir; yama uygulanmamış sunucular ise ciddi maruziyet riski taşır. RPC, blok gezginleri ve veri analizi platformları gibi üçüncü taraf hizmetlerin arka uçları veya operasyon sistemleri etkilenen PHP ortamlarında çalışıyorsa bunlar da giriş noktaları haline gelebilir. Tabii ki RPC düğümleri, akıllı sözleşmeler, blok gezginleri ve cüzdanlar PHP’ye bağımlı değildir; bu durum ürünün teknik yığınına göre değişir.

Ancak bir sunucunun ele geçirilmesinin doğrudan zincirüstü varlıkların çalınması anlamına gelmediğini unutmamak önemlidir. Web hizmetindeki bir veri ihlali ile gerçek mali kayıp arasında, saldırganların hassas kimlik bilgilerine, imzalama süreçlerine, yönetici ayrıcalıklarına veya kullanıcı etkileşim noktalarına erişip erişememesi belirleyicidir. Sıcak cüzdanların web katmanından ayrılması, anahtarların HSM/KMS içinde saklanması ve ayrıcalıkların sınırlandırılması potansiyel kaybın üst sınırını doğrudan belirler.

2. Düzenli kullanıcılar: Varlıklarınızı çekmelisiniz mi?

Gerek yoktur.

Nedeni basittir:

Bu güvenlik açığı, belirli koşulları karşılayan sunucu ortamlarını etkiler; bu, tüm kullanıcıların cüzdanlarının riske girdiği anlamına gelmez.

Bir web sitesini ziyaret etmek ve bir cüzdan bağlamak, özel anahtarların açığa çıkmasıyla aynı şey değildir. Güvenlik açığı kullanıcı cüzdanlarını ya da imzalarını doğrudan kırmaya yetmez.

Bir projenin PHP kullandığının bilinmesi, zaten ele geçirildiği anlamına gelmez. Her takas platformunun ihlal edildiğini varsaymak için hiçbir neden yoktur; dolayısıyla bu nedenle tüm varlıkları çekmek mantıksızdır. Kullanıcıların gerçekten dikkat etmesi gereken şey, ziyaret ettikleri sitelerin ele geçirilip geçirilmediğidir. Kullanıcılar bir sitenin yamalanıp yamalanmadığını belirleyemez; bu olay, web arayüzlerine körlükle güvenmemek gerektiğini hatırlatır. Saldırganlar aynı zamanda kamu ilgisinden yararlanarak sahte giriş sayfaları, sahte tazminat portalları ve zararlı cüzdan bağlantı istekleri yayabilir.

Bir proje, resmi olarak web sitesinin veya arka ucunun tehlikeye girdiğini doğruladığında, kullanıcılar açıklanan gerçek etkiyi dikkate alarak etkileşimleri geçici olarak durdurup, anormal işlemler kontrol edip şüpheli yetkilendirmeleri iptal edip etmemeye karar vermelidir. İmzalama özel anahtarlarının veya tohum ifadelerinin sızdırıldığı doğrulanırsa, bu durum bir anahtar ihlali olayı olarak ele alınmalıdır; yalnızca şifreleri değiştirmek ya da web sitesinden bağlantıyı kesmek yeterli değildir. İşlem botları, otomatik yürütme araçları veya bulut dağıtım hizmetleri kullanan kullanıcılar ayrıca ilgili hizmetlerin etkilenen sürümler veya kimlik bilgisi döndürme duyuruları yayınlamış olup olmadığını da takip etmelidir.

Nasıl yanıt verilmeli?

1. Platformlar ve proje ekipleri:

Adım bir: Varlıklarınızı envanterini çıkarın ve en kısa sürede güncelleyin

Tüm genel ve dahili ağ PHP varlıklarını envanter altına alın: sunucular, kapsayıcı görüntüleri, Kubernetes iş yükleri, eski CMS sistemleri, yönetim arka uçları, ortaklar tarafından barındırılan ortamlar, üçüncü taraf eklentileri ve yönetilen hizmetler. Teknik parmak izleri yalnızca ipuçları olarak kullanılabilir; bunlar doğrudan 'onaylanmış güvenlik açığı' sonucu olarak kabul edilemez.

8.2.35 / 8.3.36 / 8.4.27 / 8.5.12 sürümlerine güncelleyin ya da dağıtımcılar, bulut sağlayıcılar veya yönetilen hizmet sağlayıcılar tarafından sağlanan eşdeğer yamaları uygulayın. 8.1 ve önceki sürümleri kullananlar için üreticiye geriye dönük yama (backport) talep edin ya da mümkün olan en kısa sürede geçiş yapın. 'Eski ortam kararlıdır' ya da 'uygulama nadiren güncellenir' gibi gerekçeler bu güvenlik açığının riskini azaltmaz.

Güncellemeden sonra kapsayıcı görüntülerini yeniden oluşturun, kademeli yeniden başlatma yapın ya da tüm PHP çalışan süreçlerini değiştirin ve üretim ortamında istekleri gerçekçi olarak işleyen çalışma zamanı sürümünü doğrulayın—yalnızca derleme makinesindeki ya da komut satırındaki sürüm değil.

Adım iki: Şu anda güncelleyemiyorsanız ne yapmalısınız?

Öncelikle maruziyet yüzeyini azaltarak zaman kazanın; ancak bu, yama uygulamanın yerini tutmaz:

Genel internete açık PHP uygulamalarını izole edin ya da giriş katmanında ağ kimlik doğrulaması ve erişim denetimi ekleyin.

Gereksiz dosya yüklemelerini devre dışı bırakın ve WAF veya web sunucusu katmanında gerekmeyen multipart/form-data isteklerini reddedin.

Bazı güvenlik önerileri ayrıca memory_limit=-1 ayarlamasını, session.upload_progress.enabled özelliğinin devre dışı bırakılmasını ve PHP 8.5'te fatal_error_backtraces özelliğinin ek olarak devre dışı bırakılmasını içerir. Bu yapılandırmaların işletme ve kullanılabilirlik üzerinde yan etkileri olabilir; her değişiklikten önce test edin ve tüm PHP çalışan süreçlerini yeniden başlatın.

Adım üç: İhlal olup olmadığını kontrol edin ve kimlik bilgilerini yenileyin

Genel internete maruz kalmış etkilenen hizmetler için günlükleri, uç nokta izleme verilerini ve anormal ağ bağlantılarını inceleyin—örneğin PHP süreçlerinin aniden sistem komutları başlatması gibi. Şüpheli bir ihlal tespit edilirse öncelikle kanıtları koruyun, ardından olay müdahale sürecine göre hareket edin.

En kötü senaryoyu varsayın: Zamanında yamalanmamış sunucular için API anahtarlarını, oturum anahtarlarını, TLS sertifikalarını, veritabanı şifrelerini, bulut erişim belirteçlerini, CI/CD kimlik bilgilerini, RPC/API anahtarlarını, webhook gizli anahtarlarını ve üçüncü taraf belirteçlerini yenileyin; ayrıca herhangi bir anormal kullanım kaydını kontrol edin.

Doğrulanmış şekilde ihlal edilmiş bir yazılım sürümü ortamda kurulmuş veya çalıştırılmışsa, yalnızca güncellemek ya da yeniden yüklemek riskin ortadan kalktığını kanıtlamaz; aynı zamanda kimlik bilgisi sızıntısı ve kalıcı arka kapıların araştırılması gerekir ve gerektiğinde temiz bir ortam yeniden oluşturulmalıdır.

Adım dört: Varlık yönetim düzlemini güvenli hale getirin

PHP'yı yamalamak tek başına yeterli değildir. Daha önemlisi, 'kompromize olmuş bir web makinesinin fon sistemiyle beraber çökmesini engellemek' gerekir:

Sıcak cüzdanlar, toplama cüzdanları ve kritik imzalama hizmetlerinin özel anahtarlarını web düğümlerinden tamamen izole edin. HSM'ler, MPC, özel imzalama ağları ya da en az ayrıcalıklı KMS ilkelerini kullanın.

Web hizmetlerini, imzalama hizmetlerini, zincir içi düğümleri, veritabanlarını ve derleme sistemlerini farklı ağ segmentlerine ve kimlik sınırlarına yerleştirin.

Olaylar sırasında para çekme, adres beyaz listesi değişiklikleri, yönetici yetkisi yükseltmeleri, API anahtarı oluşturma ve risk kontrolü kurallarında yapılan değişiklikler gibi yüksek riskli işlemler geçici olarak sıkılaştırılmalıdır; bu işlemler gerekli olduğunda elle inceleme veya gecikmeli etkinleştirme ile gerçekleştirilmelidir.

Zincir üzerinde otomatik olarak yürütülen hizmetler için iş gereksinimlerine göre bağımsız imzalama, çoklu imza onayı, işlem tutar sınırları ve acil durdurma mekanizmaları uygulanmalıdır.

Web sitesinin statik kaynakları, JavaScript paketleri, ters proxy yapılandırmaları, DNS/CDN kuralları ve işlem oluşturma hizmetleri kontrol edilerek kötü amaçlı betiklerin eklenip eklenmediği veya değiştirilip değiştirilmediği doğrulanmalıdır.

2. Sıradan kullanıcılar:

Resmi giriş noktalarını kullanın: Son zamanlarda platformlara yerimlerden veya resmi kanallardan erişmeye çalışın ve bir «güvenlik olayı» bahanesiyle gönderilen bağlantılarla ilgili dikkatli olun.

Sadece alan adı ve arayüze bakmayın: Tanıdık dApp alan adları bile olsa, sayfa betikleri, işlem parametreleri ve RPC yapılandırmaları sunucu tarafında saldırganlar tarafından değiştirilmiş olabilir.

İmzalamadan önce her öğeyi tek tek doğrulayın: Alıcı adresi, zincir, onaylanacak miktar, çağrılan sözleşme ve işlem simülasyon sonuçları. Özellikle approve ve setApprovalForAll işlemlerinde dikkatli olun; sınırsız onay miktarlarına ise daha da fazla dikkat edin.

«Tazminat», «geçiş» ve «yeniden doğrulama» uyarısına dikkat edin: Olaylar sırasında «yeniden oturum aç», «cüzdanınızı yeniden doğrulayın», «varlıkları taşıyın» ve «tazminat talep edin» gibi mesajlar görülebilir. Sadece site içi bildirimlere dayanarak hareket etmeyin; bunları projenin birden fazla resmi kanalıyla çapraz doğrulayın.

Varlıklarınızı katmanlandırın: Büyük tutarları donanım cüzdanlarında saklayın, günlük işlemler için sınırlı kapasiteli ayrı cüzdanlar kullanın ve onayları düzenli olarak temizleyin. Böylece ön uç veya bir platform tehlikeye uğrasa bile tek bir kayıp sınırlandırılmış olur.

Şüpheli bir şey görürseniz hemen durun: Tuğla imza istekleri, beklenmedik onay uyarıları veya şüpheli web sitesi davranışları ile karşılaşırsanız ilk olarak durun ve resmi kanallarla doğrulama yapın.

Son düşünceler

PHP2Shell gibi oturum açmadan uzaktan kod yürütme açıkları Web katmanını aşınca geleneksel sunucu ihlallerini ön uç zehirlenmesine, kimlik taklidine, imzalama izinlerinin kötüye kullanılmasına, sıcak cüzdan risklerine ve hatta tedarik zinciri düzeyinde yan harekete dönüştürebilir.

Platformlar için üç şey önceliklidir: Yama sürümlerine geçiş, şimdilik yamalanamayan eski ortamların izole edilmesi ve anahtarlar ile varlık kontrol düzlemlerinin denetimi. Güncelleme sonrası, intrüzyon belirtilerini aramak olay yanıtı sürecinin bir parçası haline gelmelidir. Kullanıcılar için bu süreçte arayüzün güvenilirliğine fazla körü körüne güvenmemek ve her işlemi imzalamadan önce ekstra bir kontrol yapmak önemlidir. Ancak aşırı paniklemeyin: Bir açığın varlığı varlıkların kesinlikle tehdit altında olduğu anlamına gelmez; bir sunucu ihlali mutlaka zincirüstü fon kaybına yol açmaz. Risk ölçeğini gerçekten belirleyen şey, saldırganların hangi kimlik bilgilerini ele geçirdiği, bu kimlik bilgilerinin ne kadar yetkiye sahip olduğu ve projenin bu yetkileri ne kadar hızlı izole edip iptal ettiğiyle ilgilidir. Web3 projeleri için güvenlik yalnızca saldırıların gerçekleşmesini önlemek değil, aynı zamanda bir bileşen gerçekten ihlal edildiğinde zararın yerel olarak sınırlandırılmasını ve riskin temel iş süreçleri ile varlık işlemlerine yayılmasının engellenmesini de içerir.

Orijinal bağlantı