PHP2Shell Nedir? Yapay Zekânın Bulduğu Kritik PHP Açığı, Etkileri ve Önlemler

21 Ekim 2026'da PHP projesi, iki kritik güvenlik açığını kapatan acil bir güncelleme yayımladı. PHP2Shell adı verilen bu açıklar, internetin en yaygın sunucu tarafı dillerinden birini etkiledi; bazı kurumlar önlem olarak sitelerini geçici şekilde kapattı. Olayı özel kılan bir başka şey de bulunma biçimiydi: araştırmacılar açıkları yapay zekâ modellerinin desteğiyle ortaya çıkardı.

Bu yazıda neler olduğunu, yapay zekânın gerçek rolünü, olayın sonuçlarını ve sunucunuzda atmanız gereken adımları birincil kaynaklara dayanarak anlatıyoruz. Bilgiler 8 Kasım 2026 itibarıyla günceldir.

Kısaca

• Açıklar: CVE-2026-109618 ve CVE-2026-109619, ikisi de CVSS v4 ile 9,2 (kritik).
• Risk: Belirli koşullarda, oturum açmadan uzaktan kod çalıştırma.
• Tam çözüm: PHP 8.5.12, 8.4.27, 8.3.36 veya 8.2.35'e (ya da dağıtımınızın yamalı paketine) geçmek ve PHP süreçlerini yeniden başlatmak.
• İstismar: ABD siber güvenlik kurumu CISA, 26 Ekim'de iki açığı aktif istismar edilenler kataloğuna ekledi.

PHP2Shell Nedir?

PHP2Shell, tek bir hata değil, PHP çekirdeğinin ölümcül hataları ve özellikle bellek yetersizliğini ele alış biçiminden doğan bir açık grubudur. PHP'nin resmî duyurusuna göre tüm web kurulumları etkileniyor. Calif, Wiz ve Cloudflare, etkilenen sürümlerin PHP 5.4'e kadar uzandığını belirtiyor; PHP projesi ise en eski etkilenen sürüm için ayrı bir numara vermedi.

Açık Nasıl Çalışıyor?

CVE-2026-109618: Yarıda kalan işlem

PHP, bellek sınırına ulaşıldığında bulunduğu işlemi aniden terk ediyordu. Bu an istek verisinin henüz tam hazırlanmadığı bir ana denk gelirse, kapanış adımı geçersiz veriyi geçerli sanarak işleyebiliyordu. Advisory'ye göre çok parçalı (multipart) form verisinin işlenme şekli, küçük görünen isteklerle belleği tüketmeye imkân veriyordu.

CVE-2026-109619: Bayat durum

PHP işçi süreçleri (worker) birden fazla isteğe hizmet eder. Ölümcül bir hata temizliği yarıda bırakırsa, global bir değişken artık serbest bırakılmış belleği göstermeye devam edebiliyordu. Aynı işçiye gelen sonraki bir istek, sıfırlama yapılmadan önce bu değeri kullandığında bellek sızıntısı ve kod çalıştırma mümkün olabiliyordu.

Hangi kurulum ne kadar riskli?

Açık uygulama katmanının altında olduğu için WordPress, Drupal veya Joomla'nın güncel olması tek başına koruma sağlamaz. Wiz, bu üç platformda da oturum açmadan kod çalıştırmayı gösterdiğini aktarıyor. Araştırmacılara göre bellek sızıntısı parola, token ve API anahtarlarını da açığa çıkarabilir.

Yapay Zekâ Bu Açığı Nasıl Buldu?

Calif: OpenAI'ın "Patch the Planet" girişimi kapsamında PHP'yi denetleyen Calif'ten Ryan Austin, işe PHP'nin eski bellek sınırı hatalarını inceleyerek başladı. Büyük dil modeli; belleği tüketme yollarını ve kapanış kodunda hatanın tehlikeli olacağı noktaları bulmaya yardım etti. Calif ilk bulguyu 1 Ağustos'ta yaptı, 11 Ağustos'ta PHP'ye bildirdi. Haberlere göre kullanılan model OpenAI'ın GPT-5.6 Sol'üydü.

Wiz: Google bünyesindeki Wiz, kendi Wiz Atlas ajanı ile Gemini 4 Argon ve GPT-5.6 Sol modellerini kullanarak aynı soruna bağımsız olarak ulaştı ve 24 Ağustos'ta bildirdi. Wiz'e göre modeller, istismarı farklı sürüm ve yapılandırmalara uyarlamada da belirleyici oldu.

İnsanın rolü: Bu olay "yapay zekâ tek başına açık buldu" diye özetlenemez. Calif, hedefi seçenin ve modeli eski tekniklere yönlendirenin insan olduğunu, basit komutlarla her hatanın bulunamayacağını vurguluyor. Calif'in anlatımına göre özel bir araç veya kısıtlı erişimli model de kullanılmadı.

Sorun aslında yeni değildi: PHP Vakfı'na göre sorunun ilk izleri, 2024'teki dış güvenlik denetimi sonrasında görüldü. Somut bir saldırı yolu bulunamadı, üzerinde anlaşılan tek bir düzeltme de çıkmadı ve çalışma aylarca tıkandı. Vakıf bu gecikmeyi, karar süreci ve kaynak eksikliğinden doğan yapısal bir başarısızlık olarak tanımladı. Yapay zekânın katkısı, teorik görünen bir riskin gerçek bir saldırı olduğunu göstermek oldu.

Olayın Zaman Çizelgesi

Planlı süreç son anda bozuldu. 20 Ekim'de CVE numaraları sızdı, Calif yanlışlıkla bir kavram kanıtı videosu yayımladı. PHP yayını 22 Ekim'den 21 Ekim 14:00 UTC'ye çekti. 21 Ekim sabahı Chainguard'ın yamalı imajları koordineli yayından saatler önce çıktı ve yamanın incelenmesine imkân verdi. PHP güvenlik ekibi, yayın anında çalışan bir istismar tespit edilmediğini bildirdi.

Sonuçları Ne Oldu?

• Kapatılan siteler: Hollanda'nın Overheid.nl portalı, Fransa İçişleri Bakanlığı siteleri ve Finlandiya'daki bazı kamu hizmetleri çevrim dışı alındı. Wikimedia destek servislerinin bir bölümünü kapattı, Internet Archive kısa süre durdu. Bu kapatmaların önemli bölümü saldırı sonucu değil, önlem amaçlıydı.
• Resmî uyarılar: ABD'de NSA, hemen güncelleyemeyen sitelere çevrim dışı kalmayı önerdi. CERT-EU ve Birleşik Krallık NCSC de benzer uyarılarda bulundu.
• Aktif istismar: CISA, 26 Ekim'de iki açığı KEV kataloğuna ekledi. Perplexity'nin tuzak sistemleri, mod_php üzerinde kod çalıştırma girişimleri kaydetti. Amazon ise girişimlerin yamadan dört gün önce başladığını bildirdi; açıklama öncesi birçok girişim başarısız olarak etiketlendi.
• Türkiye: Siber Güvenlik Başkanlığı, başta kamu kurumları olmak üzere ulusal ölçekte tarama başlattı, kurumlara SOME İletişim Platformu üzerinden acil duyuru gönderdi.

Rakamlara dikkat: Sık geçen "internetin %70'i" ifadesi, ölçülmüş bir mağdur sayısı değil, PHP'nin sunucu dili bilinen sitelerdeki kullanım payıdır. Maruziyet tahminleri de yönteme göre değişiyor: VirusTotal internete açık 5,1 milyondan fazla PHP sunucusu, Censys ise 32,5 milyon hizmet sayıyor. Recorded Future, başarılı saldırıların toplam boyutunun mevcut verilerle ortaya konamadığını belirtiyor.

Hangi Önlemler Alındı?

• PHP projesi: Yamalı sürümleri yayımladı, destek dışı 7.4, 8.0 ve 8.1 için kaynak kod yamaları paylaştı. Yeni yaklaşım, bellek sınırında anlık çıkış yerine güvenli bir noktada hatayı işlemeye dayanıyor.
• Altyapı sağlayıcıları: Cloudflare, açıklamadan saatler önce tüm müşterileri için güvenlik duvarı kurallarını devreye aldı. Laravel, Cloud dağıtımlarını yamalı imajlara geçmek için durdurdu; cPanel ve CloudLinux eski sürümler için yama yayımladı.
• Yapısal değişiklikler: PHP Vakfı, güvenlik ekibini güçlendiriyor, tıkanan kararlar için oy çokluğuna geçiyor ve bildirimleri doğrulamada yapay zekâ araçlarını kullanıyor. Son karar ve yamalarda insan denetimi sürüyor.

Takip edilmesi gereken üçüncü açık: CVE-2026-115560, oturum yükleme ilerlemesiyle ilgili ayrı bir sorun. PHP bunu olasılığı düşük bulduğu için acil yayın yapmadı; tam duyuru ve düzeltmeyi bir sonraki düzenli sürüme bıraktı. Sorun yalnızca çalışma anında session.serialize_handler değiştiren uygulamaları ilgilendiriyor. session.upload_progress.enabled=0 ayarı önerilen önlemdir.

Sunucunuzda Ne Yapmalısınız?

1. Sürümü kontrol edin ve güncelleyin

php -v
apt-get changelog php-fpm | grep -E "CVE-2026-109618|CVE-2026-109619"
rpm -q --changelog php-fpm | grep -E "CVE-2026-109618|CVE-2026-109619"

Dağıtım paketlerinde sürüm numarası eski görünse de yama taşınmış olabilir; bu yüzden değişiklik kaydına bakın. Docker kullanıyorsanız imajı yamalı temel imajla yeniden derleyip dağıtın. Paylaşımlı hostingde sağlayıcınızdan yazılı teyit alın. PHP 8.1 veya öncesindeyseniz 8.2 ve üzerine geçişi planlayın. PHP 8.2'nin desteğinin 31 Aralık 2026'da bittiğini de unutmayın.

2. PHP süreçlerini yeniden başlatın

Paket güncellense bile çalışan işçiler eski kodu bellekte tutabilir. php8.x-fpm, apache2/httpd, frankenphp veya lsws servisini yeniden başlatın. Saldırı şüpheniz varsa önce bellek kaydı alın, çünkü yeniden başlatma kanıtları siler.

3. Hemen yamalayamıyorsanız riski azaltın

Aşağıdaki ayarlar riski düşürür ama kurulumu güvenli hâle getirmez. .user.ini veya ini_set() yerine ana yapılandırmaya yazıp tüm işçileri yeniden başlatın:

session.upload_progress.enabled = 0
fatal_error_backtraces = 0   ; yalnızca PHP 8.5
memory_limit = -1            ; geçici; cgroup/konteyner sınırı ile birlikte
post_max_size = 8M           ; yükleme gerekiyorsa 32M
upload_max_filesize = 4M     ; post_max_size değerinin altında kalmalı

memory_limit = -1 ayarını yalnızca konteyner veya cgroup bellek sınırıyla kullanın; ulimit -v veya RLIMIT_AS kullanmayın, çünkü bunlar açığın tetiklendiği yolu çalıştırabilir. Yama sonrası bu ayarı sınırlı bir değere geri alın. Dosya yükleme kullanılmayan yollarda multipart/form-data isteklerini proxy veya güvenlik duvarında engelleyin. Son çare olarak yamasız sunucuyu erişime kapatın.

4. Saldırı izlerini arayın

• Olağan dışı uzun veya bozuk PHPSESSID yanıt çerezleri (256 bayttan uzun)
• Çok parçalı istekleri izleyen bellek hataları ve tekrarlayan HTTP 500 yanıtları
• Açıklanamayan işçi yeniden başlamaları, segfault kayıtları veya core dump dosyaları
• PHP sürecinin başlattığı sh, bash, curl, wget gibi komutlar

Uygulama günlüklerinde iz görmemek rahatlatıcı değildir, çünkü sorun uygulama katmanının altında gerçekleşir ve bazı istismarlar normal HTTP 200 yanıtı döndürebilir.

5. İz varsa yamayla yetinmeyin

Yama açığı kapatır ama içeri sızmış bir saldırganı çıkarmaz. Yetkisiz dosya ve zamanlanmış görevleri arayın, veritabanı parolalarını, API anahtarlarını ve oturum sırlarını yenileyin, gerekiyorsa sunucuyu temiz bir yedekten kurun. Kişisel veri etkilendiyse hukuki bildirim yükümlülüklerinizi de değerlendirin.

İşletmeler İçin Dersler

• Yama süresi kısalıyor: Yapay zekâ hem savunmacıları hem saldırganları hızlandırıyor. Burada yamadan önce bile tarama görüldü; aylık bakım takvimi kritik açıklar için yeterli değil.
• Envanter şart: PHP yalnızca web sitenizde değil, yönetim panellerinde ve bazı güvenlik duvarı ürünlerinde de bulunabilir. Elinizde ne olduğunu bilmeden hızlı yama yapamazsınız.
• Destek dışı sürüm risktir: Eski sürümler için resmî paket gelmedi. Sürüm yükseltmeyi ertelemek, kriz anında maliyeti katlar.
• Katmanlı savunma işe yarar: Düşük yetkili işçi hesabı, salt okunur dosya sistemi ve kısıtlı dış erişim, bir açık istismar edilse bile zararı sınırlar.
• Açık kaynağa destek: Milyonlarca siteyi taşıyan yazılımın güvenliği sınırlı bir ekibe bağlı olabilir. Bağımlı olduğunuz projeleri izleyin ve mümkünse destekleyin.

Sunucu güncellemeleri, izleme ve güvenlik sıkılaştırması için sunucu altyapısı ve kurumsal IT yönetimi hizmetlerimize göz atabilirsiniz. Genel bir çerçeve için KOBİ'ler için siber güvenlik rehberimizi de okuyabilirsiniz.

Sık Sorulan Sorular

PHP2Shell nedir?

PHP çekirdeğindeki iki kritik bellek güvenliği açığına verilen addır: CVE-2026-109618 ve CVE-2026-109619. Belirli koşullarda oturum açmadan uzaktan kod çalıştırmaya imkân verir.

Hangi PHP sürümleri güvende?

Resmî yamalı sürümler 8.5.12, 8.4.27, 8.3.36 ve 8.2.35'tir. Linux dağıtımları yamayı farklı sürüm numaralı paketlere taşımış olabilir; paket değişiklik kaydını kontrol edin.

Açığı gerçekten yapay zekâ mı buldu?

Yapay zekâ önemli rol oynadı, ama hedefi seçen, aramayı yönlendiren ve bulguları doğrulayan araştırmacılardı. Sorunun ilk izleri 2024'te görülmüştü.

php.ini ayarlarını değiştirmek yeterli mi?

Hayır. Geçici ayarlar riski azaltır; tek tam çözüm yamalı sürüme geçip süreçleri yeniden başlatmaktır.

WordPress sitem etkilenir mi?

Açık PHP'nin kendisinde olduğu için güncel bir WordPress bile yamasız PHP üzerinde etkilenebilir. PHP sürümünüzü kontrol edin ve hosting sağlayıcınızdan teyit alın.

Kaynaklar

• PHP resmî duyuruları
• GHSA-w8hw-w9fx-j79w (CVE-2026-109618)
• GHSA-6wmf-4rv5-p3rp (CVE-2026-109619)
• PHP Vakfı: güvenlik yayını ve yapısal adımlar
• Wiz Research: PHP2Shell
• Calif: keşif süreci
• Google Cloud: müdahale ve tespit rehberi
• SANS ISC analizi
• BleepingComputer: CISA aktif istismarı doğruladı
• The Next Web: acil yama ve kurumların tepkisi
• Recorded Future: istismar analizi
• AA: Siber Güvenlik Başkanlığı açıklaması
• Wikipedia: PHP2Shell (kapatılan hizmetler)

Eres Yazılım olarak işletmenizin ihtiyacına özel çözümler tasarlıyoruz. Sürecinizi birlikte planlamak için bizimle iletişime geçin.