PHP'de "internet düzeyinde" yüksek riskli bir güvenlik açığı ortaya çıktı; Web3'ün "zincir dışı zayıf noktası" nasıl kapatılmalı?

Bu makaleyi okumak için 26 Dakika

PHP, 5.4 ile 8.5.11 sürümleri arasını etkileyen ve CVSS 9.2 puanlı iki uzaktan kod yürütme açığını acil olarak düzeltti; ayrıntılar erken sızdırıldı ve açıklar zaten istismar ediliyor. Kripto sektöründeki alan adlarının yaklaşık %53'ü PHP kullanıyor, Web3 platformlarının bir an önce yükseltme yapması gerekiyor.

Orijinal başlık: "PHP'de 'internet düzeyinde' kritik güvenlik açığı ortaya çıktı, Web3'ün 'zincir dışı zayıf noktası' nasıl kapatılmalı?"
Orijinal yazar: SlowMist Güvenlik Ekibi

Ne oldu

21 Ekim'de PHP projesi, kimlik doğrulaması gerektirmeyen uzaktan kod yürütmeye (RCE) yol açabilen CVE-2026-109618 ve CVE-2026-109619 olmak üzere iki kritik güvenlik açığını düzelten acil bir güvenlik güncellemesi yayınladı; her ikisi de CVSS v4.0 üzerinden 9.2 puan aldı. PHP resmi makamları, düzeltme öncesinde dışarıya web hizmeti sunan tüm PHP kurulumlarının etkilenebileceğini açıkça belirtti.

20 Ekim'de güvenlik açığı detayları resmi açıklamadan önce sızdırıldı ve yama henüz yayınlanmamıştı. PHP güvenlik ekibi acil sürümü planlanan 22 Ekim yerine 21 Ekim 14:00 (UTC)'de yayınlamak zorunda kaldı.

Daha da endişe verici olan, saldırıların açıklamadan daha erken gerçekleşmiş olabileceği. Amazon tehdit istihbaratı ekibi, 17 Ekim'de kendi MadPot bal küpü ağında php2shell'e yönelik istismar girişimleri gözlemlediklerini bildirdi; bu, kamuya açıklamadan dört gün önceydi.

SlowMist de PHP resmi duyurusunun ardından ilk anda güvenlik uyarısı ve önerilerini yayınladı.

İki güvenlik açığı nedir

CVE-2026-109618 (OOM bellek bozulması): PHP belleği tükendiğinde işlem akışı kesintiye uğrar ve o anda eldeki veriler yalnızca yarı hazırdır. Temizlik aşamasında PHP bu yarım kalmış verileri tam veri gibi kullanır ve sonuçta bellek düzeni bozulur.

CVE-2026-109619 (bayat küresel durum): Bir istek işlendikten sonra bellek serbest bırakılmıştır, ancak ilgili durum "yerinde kalmıştır". Aynı çalışan süreç bir sonraki isteği devraldığında, normal başlatmadan önce bu süresi dolmuş durumu kullanabilir. Resmi makamlar, bunun aracılığıyla PHP-FPM'e saldırılabileceğini ve uzaktan kod yürütülebileceğini doğruladı.

Saldırı yolundan bakıldığında, bu tür güvenlik açıklarının tehlikeli yanı, saldırganın önce site hesabını ele geçirmesine veya iş katmanındaki oturum açma, yetkilendirme ya da API Key doğrulamasını aşmasına gerek olmamasıdır. İnternete açık bir PHP uygulamasına hazırlanmış bir istek göndermek, Web hizmeti sürecinin yetkileriyle rastgele kod çalıştırmak için yeterli olabilir.

Etki alanı: PHP 5.4 ile 8.5.11 arasındaki sürümler etkilenmektedir. Düzeltme sürümleri 8.5.12, 8.4.27, 8.3.36 ve 8.2.35'tir. PHP 8.1 ve daha eski sürümler için üst kaynak tarafından normal destek sonlandırılmıştır; normal kanallardan yama çıkması beklenmemelidir, hâlâ desteklenen sürümlere geçilmelidir.

Neden tüm dünya tedirgin?

Çünkü PHP gerçekten çok yaygın. W3Techs istatistiklerine göre, sunucu dilini tanımlayabilen web sitelerinin %69,3'ü PHP kullanıyor. WordPress, WooCommerce, Magento gibi herkesin bildiği sistemlerin altında o var.

Ülkelerin tepkileri de durumu gösteriyor — Hollanda Ulusal Siber Güvenlik Merkezi önleyici olarak web sitelerini kapatmıştı; Güney Kore Cumhurbaşkanlığı Ofisi acil siber güvenlik toplantısı düzenledi, hükümet siber güvenlik alarm seviyesini yükseltti.

Ayrıca bildirildiğine göre, Kuzey Kore'nin resmi medya ve hükümet portal siteleri dahil neredeyse tüm resmi web siteleri 24 saatten uzun süredir çevrimdışı; bunun bu güvenlik açığı olayıyla ilgili olup olmadığı henüz bilinmiyor.

Web3 üzerindeki etkisi

Bu yalnızca geleneksel web sitesi operasyonlarıyla ilgili bir sorun değil. Web3 açısından, zincir üstü sözleşmelerde güvenlik açığı olmasa bile, sözleşmelerin etrafında çalışan çok sayıda "zincir dışı halka" — ön yüz sayfaları, API'ler, saklama cüzdanları, imzalama hizmetleri, airdrop talep sayfaları, operasyon arka uçları ve veri hizmetleri — çoğunlukla PHP ile kurulmuştur (WordPress, WooCommerce, Magento vb.). Sözleşmenin kendisinde güvenlik açığı olmaması, bu halkaların güvenli olduğu anlamına gelmez.

SlowMist'in tehdit istihbarat sistemi MistEye istatistiklerine göre, taradığı kripto sektörüyle ilgili 1488 alan adından 793'ünde doğrudan PHP parmak izi bulundu; bu yaklaşık %53,3'e denk geliyor. Vurgulamak gerekir ki bu yalnızca PHP kullanıldığını gösterir; bu sitelerin güvenlik açığı içerdiği veya ele geçirildiği anlamına gelmez.

1. Platform tarafı: birkaç tipik risk yolu

Ön yüzde tahrifat, kullanıcıların imzaya yönlendirilmesi.

DeFi, cüzdan türü sitelerin veya airdrop sayfalarının sunucuları ele geçirilirse, saldırganlar sayfadaki RPC adresini, yetkilendirme nesnesini, sözleşme adresini veya imza istemini değiştirerek normal bir işlemi kötü niyetli yetkilendirmeye, kötü niyetli sözleşme etkileşimine veya sahte yükleme sürecine dönüştürebilir. Saldırganların sözleşmeyi kırmasına gerek yoktur; kullanıcının kendi eliyle kötü niyetli bir yetkilendirme imzalamasını sağlamaları yeterlidir.

Anahtar ve kimlik bilgilerinin sızması.

Sunucu ele geçirildikten sonra saldırganlar yapılandırma dosyalarını, veritabanı parolalarını, API Token'larını, ortam değişkenlerini vb. okuyabilir. Arka uç, düğüm RPC'sine veya sıcak cüzdan hizmetine bağlanmak için PHP kullanıyorsa, API Key ve oturum belirteçleri sızdığında bu durum sıcak cüzdan varlıklarının transfer edilmesine veya imza yetkilerinin kötüye kullanılmasına dönüşebilir.

Arka uç ve API'nin devralınması.

İşlem platformları, NFT pazaryerleri, zincirler arası köprüler, ödeme geçitleri ve düğüm hizmet sağlayıcıları genellikle operasyonel arka uçlara, ayrıca KYC/risk kontrol arayüzlerine, yükleme adresi tahsisine, çekim onayına, talep sistemlerine vb. sahiptir. Saldırganlar yetkiyi aldıktan sonra yapılandırmayı tahrif edebilir, kullanıcı verilerini çalabilir, yüksek yetkili hesaplar oluşturabilir veya iş süreçlerini atlayabilir.

Tedarik zincirinde yatay hareket.

PHP sürecinin yetkisi genellikle sunucunun en yüksek yetkisine eşit değildir, ancak CI/CD anahtarlarını, konteyner çalışma zamanı socket'ini, veritabanı kimlik bilgilerini veya bulut erişim belirteçlerini okuyabiliyorsa, saldırı kapsamı tek bir Web düğümünden veritabanına, derleme sistemine, hatta tüm üretim hesabına genişleyebilir.

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

Bilindiği üzere Binance Pay, Crypto.com Pay, BitPay, CoinGate, CoinPayments gibi kripto ödeme çözümlerinin WooCommerce entegrasyonları vardır; sunucu yamalanmazsa ciddi maruz kalma riski bulunur. RPC, blok gezgini, veri analizi platformları gibi üçüncü taraf hizmetlerin arka ucu veya operasyon sistemleri etkilenen PHP ortamında çalışıyorsa, bunlar da giriş noktası haline gelebilir. Elbette RPC düğümleri, akıllı sözleşmeler, blok gezginleri ve cüzdanlar doğası gereği PHP'ye bağımlı değildir; bu, ürünün teknoloji yığınına bağlıdır.

Ancak dikkat edilmesi gereken nokta, sunucunun ele geçirilmiş olmasının zincir üstü varlıkların kesinlikle çalınacağı anlamına gelmediğidir. Web hizmetinin ihlal edilmesinden gerçek fon kaybına kadar, saldırganın hassas kimlik bilgilerine, imzalama süreçlerine, yönetim yetkilerine veya kullanıcı etkileşim noktalarına erişip erişemeyeceğine bakmak gerekir. Sıcak cüzdanların Web katmanından izole edilip edilmediği, anahtarların HSM/KMS'de tutulup tutulmadığı, yetkilerin minimum düzeyde olup olmadığı, kayıp üst sınırını doğrudan belirler.

2. Normal kullanıcılar: Coin'leri çekmeli mi?

Gerek yok.

Nedeni basit:

Bu güvenlik açığı, belirli koşulları sağlayan sunucu ortamlarını etkiliyor; tüm kullanıcıların cüzdanlarının risk altında olduğu anlamına gelmiyor.

Web sitesini ziyaret etmek, cüzdan bağlamak ile özel anahtarın sızması aynı şey değildir. Güvenlik açığının kendisi, kullanıcının cüzdanını veya imzasını doğrudan kıramaz.

Bir projenin PHP kullanması, onun zaten sorun yaşadığı anlamına gelmez. Her işlem platformunun ihlal edildiğini varsaymak için bir neden yok; bu yüzden tüm varlıkları çekmeye de gerek yok. Kullanıcıların gerçekten dikkat etmesi gereken şey, ziyaret ettikleri sitenin ele geçirilip geçirilmediğidir. Kullanıcılar bir sitenin yama alıp almadığını bilemez, bu yüzden bu olay bir hatırlatmadır: web sitesi arayüzüne körü körüne güvenmeyin. Saldırganlar ayrıca kamuoyu ilgisinden yararlanarak sahte giriş sayfaları, sahte tazminat giriş noktaları ve kötü niyetli cüzdan bağlantı istekleri yayabilir.

Proje resmi olarak web sitesinin veya arka ucun ihlal edildiğini doğrularsa, duyuruda açıklanan gerçek etkiye göre etkileşimi duraklatıp duraklatmayacağınıza, anormal işlemleri kontrol edip etmeyeceğinize ve şüpheli yetkilendirmeleri iptal edip etmeyeceğinize karar verin. İmzalama özel anahtarının veya kurtarma ifadesinin sızdığı doğrulanırsa, bu bir anahtar sızıntısı olayı olarak ele alınmalıdır; yalnızca şifre değiştirmek veya web sitesi bağlantısını kesmek yeterli değildir. İşlem botları, otomatik yürütme araçları veya bulut dağıtım hizmetleri kullanan kullanıcılar, ilgili hizmetlerin etkilenen sürümler veya kimlik bilgisi rotasyonu bildirimleri yayımlayıp yayımlamadığına da dikkat etmelidir.

Nasıl karşılık verilir

1. Platformlar ve proje ekipleri:

İlk adım: Envanteri çıkarın, mümkün olan en kısa sürede yükseltin

Tüm genel ve iç ağ PHP varlıklarını envanterleyin: sunucular, konteyner imajları, Kubernetes iş yükleri, eski CMS'ler, yönetim arka uçları, iş ortağı barındırma ortamları, üçüncü taraf eklentiler ve barındırma hizmetleri. Teknik parmak izleri yalnızca ipucu olarak kullanılmalı, doğrudan "güvenlik açığı doğrulandı" sonucu olarak değerlendirilmemelidir.

8.2.35 / 8.3.36 / 8.4.27 / 8.5.12 sürümlerine yükseltin veya dağıtım, bulut sağlayıcı ya da barındırma hizmeti sağlayıcısının sunduğu eşdeğer yamayı uygulayın. 8.1 ve daha eski sürümleri kullananlar tedarikçiden backport talep etmeli veya mümkün olan en kısa sürede taşınmalıdır. «Eski ortam kararlı» veya «uygulama sık güncellenmiyor» gibi gerekçeler bu güvenlik açığının riskini azaltmaz.

Yükseltmeden sonra konteyner imajlarını yeniden oluşturun, tüm PHP çalışan süreçlerini kademeli olarak yeniden başlatın veya değiştirin ve yalnızca derleme makinesindeki ya da komut satırındaki sürümü değil, canlı ortamda istekleri fiilen işleyen çalışma zamanı sürümünü doğrulayın.

İkinci adım: Şimdilik yükseltme yapamıyorsanız ne yapmalı

Önce saldırı yüzeyini daraltın ve zaman kazanın; ancak bu, yamayı ikame etmez:

İnternete açık PHP uygulamalarını izole edin veya giriş katmanında ağ kimlik doğrulaması ve erişim kontrolü ekleyin.

Gereksiz dosya yüklemeyi kapatın; WAF veya web sunucusu katmanında gereksiz multipart/form-data isteklerini reddedin.

Bazı güvenlik önerileri ayrıca şunları içerir: memory_limit=-1 ayarlayın, session.upload_progress.enabled seçeneğini kapatın ve PHP 8.5 üzerinde fatal_error_backtraces seçeneğini de kapatın. Bu yapılandırmaların iş süreçleri ve kullanılabilirlik üzerinde yan etkileri vardır; önce test edin ve her değişiklikten sonra tüm PHP çalışan süreçlerini yeniden başlatın.

Üçüncü adım: İhlal olup olmadığını kontrol edin ve kimlik bilgilerini temizleyin

Daha önce internete açık olan etkilenen hizmetlerde günlükleri, uç nokta izlemeyi ve anormal ağ bağlantılarını inceleyin; örneğin PHP süreçlerinin aniden sistem komutları başlatması gibi durumları araştırın. Şüpheli bir ihlal tespit ederseniz önce kanıtları koruyun, ardından olay müdahale sürecine göre hareket edin.

En kötü senaryoyu varsayın: Zamanında yamalanmamış sunucularda API anahtarlarını, oturum anahtarlarını, TLS sertifikalarını, veritabanı parolalarını, bulut erişim belirteçlerini, CI/CD kimlik bilgilerini, RPC/API Key'leri, Webhook anahtarlarını ve üçüncü taraf Token'ları döndürün ve anormal kullanım kayıtları olup olmadığını kontrol edin.

Ortamda kirli olduğu doğrulanmış yazılım sürümleri kurulmuş veya çalıştırılmışsa yalnızca yükseltme veya yeniden kurulum riskin ortadan kalktığını göstermez; kimlik bilgisi sızıntısı ve kalıcı arka kapılar da araştırılmalı, gerekirse temiz bir ortam yeniden oluşturulmalıdır.

Dördüncü adım: Varlık kontrol yüzeyini koruyun

PHP yaması tek eylem olmamalıdır. Daha da önemlisi, "bir Web sunucusunun ele geçirilmesinin fon sistemini etkilememesi" sağlanmalıdır:

Sıcak cüzdanların, toplama cüzdanlarının ve kritik imzalama hizmetlerinin özel anahtarlarını Web düğümlerinden tamamen izole edin. HSM, MPC, özel imzalama ağı veya en az yetkili KMS politikaları kullanın.

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

Olay süresince para çekme, adres beyaz listesi değişiklikleri, yönetici yetki yükseltme, API Key oluşturma, risk kontrol kuralları değişikliği gibi yüksek riskli işlemleri geçici olarak sıkılaştırın; gerekirse manuel onay veya gecikmeli yürürlük devreye alın.

Zincir üzerinde otomatik yürütülen hizmetler için işleyişe göre bağımsız imzalama, çoklu imza onayı, işlem limiti kısıtlaması ve acil durdurma mekanizması kullanılabilir.

Web sitesi statik kaynaklarını, JavaScript paketlerini, ters proxy yapılandırmasını, DNS/CDN kurallarını ve işlem oluşturma hizmetlerini kontrol edin; kötü amaçlı betik eklenmediğinden veya değiştirilmediğinden emin olun.

2. Normal kullanıcılar:

Resmi girişi kullanın: Son dönemde platforma mümkün olduğunca yer imleri veya resmi kanallar üzerinden erişin; "güvenlik olayı" adı altında gönderilen bağlantılara karşı dikkatli olun.

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

İmzalamadan önce her kalemi kontrol edin: Alıcı adresi, bulunduğu zincir, yetkilendirme limiti, çağrılan sözleşme ve işlem simülasyon sonucu. Özellikle approve ve setApprovalForAll işlemlerine dikkat edin; sınırsız limit yetkilendirmelerinde daha da temkinli olun.

"Tazminat", "taşıma", "yeniden doğrulama" konusunda dikkatli olun: Olay süresince "yeniden giriş yapın", "cüzdanı yeniden doğrulayın", "varlıkları taşıyın", "tazminat alın" gibi istemler ortaya çıkabilir. Yalnızca site içi açılır pencerelere dayanarak işlem yapmayın; projenin resmi kanallarının birden fazlasından çapraz doğrulama yapın.

Varlıkları katmanlara ayırın: Büyük tutarlı varlıkları donanım cüzdanında saklayın, günlük etkileşimler için ayrı ve limitli bir cüzdan kullanın ve yetkilendirmeleri düzenli olarak temizleyin. Böylece bir ön yüz veya platform sorun yaşasa bile tek seferlik kayıp sınırlı kalır.

Anormallik varsa önce durun: Olağandışı imza talepleri, beklenmeyen yetkilendirme istemleri veya web sitesinin davranışında tuhaflık fark ederseniz önce duraklayın, ardından resmi kanallar üzerinden doğrulayın.

Son olarak söylemek istediğimiz

PHP2Shell gibi oturum açma gerektirmeyen uzaktan kod yürütme açıkları, Web katmanını aştığında geleneksel sunucu ihlali; ön yüz zehirleme, kimlik taklidi, imza yetkilerinin kötüye kullanımı, sıcak cüzdan riski ve hatta tedarik zinciri düzeyinde yatay yayılmaya dönüşebilir.

Platformlar için en öncelikli üç şey şudur: düzeltilmiş sürüme yükseltmek, geçici olarak yamalanamayan eski ortamları izole etmek, anahtarları ve varlık kontrol düzlemini denetlemek. Yükseltmeden sonra ihlal belirtilerinin araştırılması da olay müdahalesinin bir parçası olarak ele alınmalıdır. Kullanıcılar için bu dönemde sayfa arayüzüne körü körüne güvenmek yerine her imzadan önce bir kez daha dikkatli bakmak gerekir. Ancak aşırı panik yapmayın: Açığın var olması varlıkların mutlaka tehdit altında olduğu anlamına gelmez; sunucunun ele geçirilmesi de zincir üstü fon kaybına kesin olarak yol açmaz. Riskin büyüklüğünü gerçekte belirleyen şey, saldırganın hangi kimlik bilgilerini ele geçirebildiği, bu bilgilerin ne kadar yetkiye sahip olduğu ve projenin bu yetkileri ne kadar hızlı izole edip iptal edebildiğidir. Web3 projeleri için güvenlik inşası yalnızca saldırıları engellemenin yollarını düşünmekle kalmamalı; bir bileşen gerçekten ele geçirildiğinde etkinin yerel kalıp kalmayacağını, riskin çekirdek iş ve varlık süreçlerine yayılmasının önlenip önlenemeyeceğini de hesaba katmalıdır.