Ana sayfa→Siber Güvenlik & Gizlilik
Siber Güvenlik & Gizlilik

PHP2Shell Sıfır-Gün Açıkları İçin Kritik Acil Yama: Sömürü Denemeleri Ortaya Çıktı.

PHP, dilin kendisinde iki kritik açığı kapatan acil güncellemeler yayımladı; bu açıklar, hesap sahibi olmayan bir saldırganın bir web sunucusunda kod…

User Avatar
Alper DemirEditör
7 dk okuma

Vulnerability / Web Security

PHP, dilin kendisinde iki kritik açığı kapatan acil güncellemeler yayımladı; bu açıklar, hesap sahibi olmayan bir saldırganın bir web sunucusunda kod çalıştırabilmesine olanak tanıyor. Düzeltmeler PHP 8.5.12, 8.4.27, 8.3.36 ve 8.2.35 sürümlerinde bulunuyor ve PHP ekibi, bir sunucunun yalnızca güncellenmesiyle tamamen korunduğunu belirtiyor.

PHP2Shell olarak adlandırılan açıklar, PHP çalışma zamanında yer alıyor, herhangi bir uygulamada değil; bu nedenle sitenin kendi kodu güvenli olsa bile site açık hale geliyor. Risk, çalışan bir açığı sömüren saldırının, herhangi bir uygulama kodu çalışmadan önce tetiklendiği Apache mod_php kullanan sunucularda en yüksek düzeyde.

SayarBilgi sitesini Google’da tercih edilen kaynak olarak seç

Her iki açık da CVSS v4.0 ölçeğinde 9.2 puanıyla derecelendiriliyor ve CVE-2026-109618 ile CVE-2026-109619 tanımlayıcılarını taşıyor. PHP, açıklamaları 21 Ekim’de saat 14:00 UTC’de planlanan sürüm yayımlama zamanının etrafında duyurdu; bu da 22 Ekim’de planlanan açıklamadan önce ayrıntıların sızdırılmasından bir gün sonra gerçekleşti.

⚡ UYARI — PHP, Yamalanmamış Bir RCE Açığı CVE-2026-115560 için Uyarıyor

Califonya merkezli Wiz ve OpenAI araştırmacıları, PHP 5.4’e kadar neredeyse her PHP sürümünü etkileyen açıkları bulup raporladı.

Kimler Etkileniyor

PHP güvenlik uyarısına göre, web isteklerini sunan her PHP kurulumu risk altında; bunlara PHP-FPM, Apache mod_php, php-cgi, FrankenPHP ve LiteSpeed dahil.

Açıklar motorda, herhangi bir sitenin kodunda olmadığı için, hassas bir PHP sürümündeki basit bir “Hello World” sayfası bile saldırıya uğrayabilir.

Uyarı, en yüksek riski mod_php olarak öne çıkarıyor; tek bir kimlik doğrulaması gerektirmeyen bir isteğin, herhangi bir uygulama kodu çalışmadan önce saldırıyı tetiklediği kanıtlanmış bir açığı sömürmeyi içeriyor. PHP-FPM farklı davranıyor, çünkü kurulumun erken aşamalarında bir istek başarısız olduğunda çalışanı kapatıyor.

İki açından biri için PHP’nin kendi analizi, FPM’in zayıf olduğunu destekliyor ancak tam bir FPM açığı sömürmesinin gösterilmediğini belirtiyor; ikinci açık ise hem mod_php’de hem de PHP-FPM’de kod çalıştırma sağlayabildiği kanıtlandı, ancak FPM yolundaki durum çalışan uygulamanın içindeki bir işleme bağlı.

Bir salırgan, ayrıca kod yürütmesini kazanmadan önce, diğer isteklere ait şifreler, kimlik doğrulama belirteçleri, API anahtarları ve sertifikaları içerebilecek PHP worker sürecinden belleği okuyabilir.

Araştırmacılar, bu canlı worker belleği okumayı, kontrol etmedikleri uygulamalar üzerinde göstererek, PHP’nin üzerinde çalıştığı uygulamanın bağımsız olduğunu ortaya koydu.

Ne Kurulmalı

Web isteklerini sunan PHP çalışma zamanını güncelleyin, ardından Apache, PHP-FPM ve uzun süre çalışan tüm PHP worker’ları yeniden başlatın. WordPress veya Laravel gibi bir uygulamanın güncellenmesi, altında yatan PHP çalışma zamanını güncellemez; bu, sunucu paketinden, hosttan veya konteyner imajından gelir.

İlk düzeltilmiş sürüm
8.5 8.5.12’den düşük 8.5.12
8.4 8.4.27’den düşük 8.4.27
8.3 8.3.36’den düşük 8.3.36
8.2 8.2.35’den düşük 8.2.35

PHP 8.1 ve daha eskileri artık PHP projesinden güncellemeler almıyor ve PHP 8.2, 31 Aralık 2026’da kullanım ömrünü tamamlıyor. Daha eski dallar için PHP güvenlik ekibi, kaynaktan derleyen veya bir tedarikçi bekleyenlere yardımcı olmak amacıyla PHP 7.4, 8.0 ve 8.1 için kaynak backport’larını yayımladı.

Linux dağıtımları ve uzun süreli destek tedarikçileri yamaları önceden aldı, bu nedenle bir dağıtım paketi, eski görünen bir sürüm numarası altında düzeltmeyi taşıyabilir; Debian’ın tavsiye ettiği gibi sürüm dizisine değil, CVE için paket güncelleme günlüğüne bakın.

Henüz Güncelleyemiyorsanız

Sadece güncelleme, tam bir düzeltmedir. Aşağıdaki önlemler, danışmanlığa göre, belirli salırganlık yollarına maruz kalmayı azaltır ancak bir sunucuyu güvenli hale getirmez.

CVE-2026-109618 için memory_limit=-1 ayarlanarak uygulamaların bunu geçersiz kılmasının önüne geçilmeli, post_max_size düşük tutulmalı ve web sunucusunda veya vekil sunucuda istek boyutu sınırları zorunlu kılınmalıdır. RLIMIT_AS veya RLIMIT_DATA yerine bunların kullanılmaması gerekir, çünkü PHP bunların aynı hassas yolu tetikleyebileceği konusunda uyarır.

CVE-2026-109619 için session.upload_progress.enabled=0 ayarlanıp tüm işçilerin (worker) yeniden başlatılması gerekir; PHP 8.5’te ayrıca fatal_error_backtraces=0 da ayarlanmalıdır. Oturum ilerleme özelliğinin kapatılması onaylanan oturum yollarını durdurur ancak diğer varyantları değil ve bu açığı yamalamadan başka bir şekilde tamamen gideren bir yapılandırma değişikliği yoktur.

Bu ayar, yamadan önce çözüm önerisi olarak dolaşımda olan ayardır ve sürüm bunun eksiksiz bir düzeltme olmadığını onaylar. Oturum ilerleme özelliği varsayılan olarak açıdır ve PHP bir istek kurmayı bitirmeden önce oturum işlemine ulaşabilir; bu yüzden CVE-2026-109619 için onaylanan bir saldırı yolunda yer alır ve kapatılması CVE-2026-109618 için hiçbir şey yapmaz.

“Sayabileceğim tek şey, tek gidermenin PHP’yi yalamak/güncellemek olduğu. Ne yazık ki çok şey biliyorum,” PHP çekirdek geliştiricisi Gina Peter Banyard, sürümden önce ayarın yeterli olabileceğini öne süren birine yanıt verirken yazdı.

Güncelledikten sonra bellek ayarlarınızı gözden geçirin. Düzeltme yeni bir sert bellek sınırı ekler ve bu sınıra ulaşmak süreci sonlandırır ve kapanış işlemlerinin çalışmasını durdurur; bu yüzden memory_limit ve post_max_size’yi uygulamanızın ihtiyaçlarına göre kontrol edin.

Zaten yamaladıysanız ancak daha önce bir izinsiz giriş şüphediyse, araştırmacılar alışıştıışı çok parçalı (multipart) isteklerin ardından bellek sınırı hatalarını veya tekrarlayan HTTP 500 yanıtlarını, olağandışı derecede büyük PHPSESSID yanıt çerezlerini ve açıklanamayan PHP işçi yeniden başlatmalarını izlemeyi önerir.

Saldırıda mı Oluyor

Yama yayımlanmadan önce Cloudflare, açıkların erken sömürü girişimlerini gördüğünü söyledi. “Erken saldırıların ortaya çıktığını ve yeni vektörler belirirken gidermeleri güncellediğimizi görüyoruz,” Cloudflare CTO’su Dane Knecht, Cloudflare’in dağıttığı güvenlik duvarı kurallarını geçici bir çözüm olarak nitelendirerek yöneticilere yamayı çağırdı.

Başarılı bir sızma girişiminin doğrulandığına dair hiçbir kaynak yok. CVE-2026-109618’i yeniden üreten watchTowr, 21 Ekim saat 11:26 UTC itibarıyla canlı ortamda bir sömürü bildirmedi ve her iki açık da o anda CISA’nın Bilinen Sömürülen Açıklar kataloğunda yer almadı.

Bazı kuruluşlar, herhangi bir sızma girişimine yanıt olarak değil, önlem olarak hizmetlerini çevrimdışı aldı. BambooHR, ABD, Kanada ve İrlanda genelinde hizmetini çevrimdışı alarak maaş ödemelerinin kesileceğini uyardı ve henüz bir geri yükleme süresi olmadığını belirtti.

Hollanda’da MijnOverheid, DigiD, meclisin alt kanadının sitesi, ulusal siber güvenlik merkezi ve birkaç eğitim sistemi çevrimdışı oldu; yayıncı NOS merkez, açığın kötüye kullanıldığını görmediğini ancak herkesi yama yapmaya çağırdığını bildirdi.

Nasıl Ortaya Çıktı

Sızıntı, sürümün öne alınmasına neden oldu. 20 Ekim’de The Hacker News’ın aktardığı gibi, Hacker News’daki bir gönderide, iki CVE kimliğine sahip iki PHP uzak kod yürütme açığının, yalnızca güvenilir bir ipucuna dayanarak 22 Ekim’de açıklanacağının belirtildiği kaydedildi.

PHP, akşam bir ön uyarı yayımladı ve sürümü 21 Ekim’e aldı. Sızıntının iddia ettiği 10.0 CVSS puanı PHP’nin değildi; PHP her iki açığı da 9.2 olarak derecelendiriyor.

Açıklar, Kaliforniya merkezli Wiz Research ile OpenAI’nin Codex Security ekibi tarafından, PHP güvenlik ekibi ve Google’ın Gemini ekibiyle birlikte düzeltme üzerinde çalışılarak bulundu. Alt yapı kodu on yıldan fazla süredir PHP içinde bulunuyordu.

Araştırmacılar, yapay zeka modellerinin bu uzun süredir var olan açıkları çalışan açıklara dönüştürmede yardımcı olduğunu; bir araştırmacının, aksi halde bir ekibin aylarını alacağını söylediği bir işi yaklaşık bir haftada tamamlayabildiğini söylüyor.

Açığın kökenini 2004 yılındaki PHP araştırmalarına izleyen Calif, hedefin tarihinin bilinmesinin hâlâ önemli olduğunu ve güncel modellerin yalnız başlarına belirsiz, yirmi yıllık ilkel yapılardan güvenilir bir şekilde başlayamadığını belirtiyor.

Güncelleme: watchTowr, Sömürü Girişimleri Bildiriyor, Yine Doğrulanan Bir Sızma Yok

watchTowr, gün içinde daha önce hiçbir saldırı gözlemediğini bildirmişken, 21 Ekim 2026 saat 14:19 UTC’de yayımladığı yeni bir uyarıda CVE-2026-109618 ve CVE-2026-109619 açıklarının “aktif sömürü girişimlerini” gözlemekte olduğunu belirtti. Cloudflare, müşterilerine yönelik saldırı trafiği gördüğünü ve saldırganların güvenlik duvarı kurallarını atlatmak için yüklerini değiştirdiğini söyledi; güvenlik duvarını yama yayınlanmadan önce 03:02 UTC’de varsayılan olarak açmıştı. Bu güncelleme itibarıyla belirli bir sunucuda doğrulanmış bir ihlal bildirilen kaynak bulunmuyor.

PHP Foundation, koordineli açıklamanın yayımlamadan önce gerçekleştiğini belirtti. 20 Ekim 2026 saat 20:00 UTC’de araştırma firması Calif, çalışan kanıt-önekinin (proof of concept) videosunu yanlışlıkla yayımladı ve 21 Ekim 2026 saat 07:41 UTC’de, yamanın gönderilmesinden yaklaşık altı saat önce Chainguard, yamayı içeren derlenmiş görüntüleri yayımlayarak herkesin yamayı incelemesini sağladı, diğer kullanıcılar güncellemeyi beklerken.

Güncelleme: PHP Foundation, 2024 Denetiminin Açığın İlk Belirtilerini Tespit Ettiğini Söyledi

Aynı paylaşımda PHP Foundation, bellek aşımı açığının (CVE-2026-109618) ardındaki izlerin, PHP’nin 2024 dış denetimi sırasında bir çekirdek geliştirici tarafından ilk kez tespit edildiğini, ancak çalışan bir saldırının yalnızca kuramsal düzeyde öngörüldüğünü ve o dönemde kod yürütme için somut bir yol bulunmadığını belirtti.

Rakip düzeltmelerin uyumluluğu bozma, hizmet reddi (denial-of-service) yollarını açma veya üçüncü taraf eklentilerinde değişiklik zorunluluğu getirme riski taşıması ve küçük bir ekibin uzlaşmada zorlanması üzerine, yama çalışmalarının aylarca takılı kaldığını belirtti. Foundation, bu gecikmeyi karar verme sürecinin ve kaynaklarının “yapısal bir başarısızlığı” olarak nitelendirdi.

AI araçlarını kullanan Calif, OpenAI ve Wiz’den gelen 2026 raporları, açığın tam etkisini açıkça ortaya koyan çalışan bir sömürüyü ortaya çıkararak yamayı öncelik listesinin en üstüne taşıdı. Foundation, buna ardından güvenlik kararları verme biçimini değiştirdiğini ve benzer sorunları daha erken yakalamak için personel ve araç eklediğini söyledi.

(Haber, 21 Ekim 2026’da yayımlandıktan sonra, sömürü girişimlerine dair sonraki raporlar ve PHP Foundation’un açığın tarihçesine dair hesabı eklemek amacıyla güncellenmiştir.)

İlginizi Çekebilir: Otonom AI Ajanlarıyla 1.200’den Fazla Siteye Sızan Hackerlar Şirket Web Sitelerini Hedefledi →
Kaynak: Thehackernews ↗Kaynak yazarı: The Hacker News
🛡️ SayarBilgi Topluluğu

Bu Gelişmeyi Toplulukta Değerlendirin

Haber hakkındaki düşüncelerinizi, donanım deneyimlerinizi ve teknik sorularınızı topluluk üyeleriyle anlık olarak tartışın.

🛡️ Siber Güvenlik & Gizlilik Odası →
💬 Topluluk Masası & Tartışma

Bu gelişme hakkında düşüncelerinizi, donanım deneyimlerinizi veya sorularınızı Topluluk Forumumuzda paylaşın.

Foruma Katıl & Yanıtla ➔
Forumda sor / tartış
TOPLULUĞUN SESİ

Söz sizde.

1 yorum

Deneyiminizi, sorularınızı ve katkılarınızı paylaşın. E-posta adresiniz yayımlanmaz.

Sohbete katıl

E-posta adresiniz yayınlanmayacak. Gerekli alanlar * ile işaretlenmişlerdir

Yorumunuz yayımlanmadan önce onay bekleyebilir.

BİR SONRAKİ OKUMA

Merak etmeye devam

Tümünü gör ↗

Neyi merak ediyorsun?

En az 3 karakter yazın.

Keşfet