PHP Kritik Güvenlik Açığı: Etkilenip Etkilenmediğinizi Nasıl Kontrol Edersiniz?

21 Ekim 2026 PHP güvenlik duyurusu (CVE-2026-109618, CVE-2026-109619): etkilenen sürümler, yamalı sürümler ve yama sonrası doğrulama için neye bakılır.

22 Ekim 2026 · Güncellendi: 30 Ekim 2026

21 Ekim 2026’da PHP projesi, iki kritik güvenlik açığını kapatan acil güncellemeler yayımladı. Bazı güvenlik yayınlarında “PHP2Shell” adıyla anılan bu açıklar (adı PHP’nin kendi duyurusunda geçmiyor), kimlik doğrulaması gerektirmeden uzaktan kod çalıştırmaya yol açabiliyor. Dünyanın çeşitli yerlerinde kamu kurumları, önlem olarak bazı hizmetlerini geçici olarak kapattı. Bu yazıda olayı PHP’nin resmî duyurusuna, GitHub’daki teknik kayıtlara ve basın kaynaklarına dayanarak özetliyor, etkilenip etkilenmediğinizi nasıl kontrol edeceğinizi ve zafiyet taraması ile sızma testinin bu tür küresel açıklarda gerçekte ne işe yaradığını, neyi yapamayacağıyla birlikte anlatıyoruz.

Ne oldu?

PHP projesi iki açığı duyurdu: CVE-2026-109618 ve CVE-2026-109619. İkisi de CVSS v4 ölçeğinde 9.2 ile “kritik” puanlandı ve saldırının kimlik doğrulaması gerektirmediği belirtiliyor.
Web isteklerine yanıt veren PHP kurulumları etkileniyor: PHP-FPM, Apache mod_php, php-cgi, FrankenPHP ve LiteSpeed. PHP’nin duyurusuna göre en yüksek risk mod_php’de; orada kimlik doğrulaması olmayan bir isteğin, uygulama kodu çalışmadan önce saldırıyı tetikleyebildiğini gösteren bir istismar yöntemi var. Teknik kayıtlar saldırı karmaşıklığını “yüksek” olarak değerlendiriyor.
Etkilenen sürümler 8.2.35, 8.3.36, 8.4.27 ve 8.5.12 öncesidir. PHP 8.1 ve öncesi artık düzenli güvenlik güncellemesi almıyor; 7.4, 8.0 ve 8.1 için yalnızca minimal kaynak yamaları yayımlandı.
TRT Haber’in aktardığına göre Japonya’da Sağlık, Çalışma ve Refah Bakanlığı, uzun süreli bakım hizmeti sağlayıcılarının iletişim bilgilerini içeren bir bilgi paylaşım sistemi sitesini geçici olarak askıya aldı. Norveç’te Feide ve Dijitalleşme Müdürlüğü siteleri devre dışı kaldı, Finlandiya’da bazı devlet siteleri önlem olarak kapatıldı, Hollanda DigiD ve MijnOverheid hizmetlerini geçici olarak erişime kapattı. Danimarka’nın siber güvenlik kurumu sistem sahiplerini güncellemeye çağırdı. ABD’de FBI, hemen güncelleme yapamayan kuruluşların sitelerini çevrimdışı almasını önerdi.

Sahada istismar: PHP’nin duyurusu ve GitHub kayıtları sahadaki istismar hakkında bilgi vermiyordu; Malwarebytes ise Cloudflare’in teknoloji yöneticisinin ilk saldırıların ortaya çıktığı uyarısını aktarmıştı ve güvenlik duvarı önlemlerinin yalnızca geçici bir çözüm olduğunu belirtmişti. 26 Ekim’de CISA, iki açığı da bilinen sömürülen açıklar kataloğuna ekledi. CISA’nın uyarısı, hemen yamalanamayan ya da PHP 8.1 ve öncesi gibi desteği bitmiş sürümleri kullanan sistemlerin yama yapılana kadar çevrimdışı alınmasını öneriyor; bir web uygulama güvenlik duvarının (WAF) yalnızca bir miktar koruma sağlayabileceğini ve PHP işçi süreçlerinin kabuk başlatması ya da araç indirmesi gibi şüpheli davranışların izlenmesi gerektiğini belirtiyor. İnternete açık ve yamasız her PHP kurulumunu risk altında kabul etmek gerekir. Durum hızla değişebilir.

CISA ayrıca 28 Ekim’de bir Linux çekirdeği açığını (CVE-2026-46300) kataloğa ekledi ve bu açığın yukarıdaki PHP açıklarıyla zincirlenerek PHP web kabuğu yerleştirmek ve root olarak komut çalıştırmak için kullanılabildiğini belirtiyor. Bu hatanın düzeltmeleri aylardır dağıtımlarda yayımlanıyor (örneğin kararlı çekirdek dallarında 6.1.174 ve 6.12.91); PHP çalıştıran sunucuların çekirdeğinin bu düzeltmeyi içerdiğini dağıtımınızın CVE-2026-46300 sayfasından doğrulayın.

İki açık kısaca nasıl işliyor?

CVE-2026-109618: Bellek tükenmesi (OOM) anında PHP işlemi, istek verisi kısmen başlatılmışken kesilebiliyor; sonraki temizlik adımı bu geçersiz veriyi geçerliymiş gibi işleyebiliyor. Teknik kayıt, uzaktan kod çalıştırmanın HTTP üzerinden mod_php’ye karşı doğrulandığını belirtiyor.
CVE-2026-109619: Bir isteğe ait iç durum, ilgili bellek serbest bırakıldıktan sonra da kalabiliyor. Aynı işçi sürecine (worker) gelen sonraki istek bu bayat durumu kullanınca bellek bozulması oluşabiliyor. Teknik kayıt, tetikleyici yollardan birinin mod_php ve FPM’de doğrulandığını belirtiyor.

Yama ve geçici önlemler

Kalıcı çözüm PHP’yi yamalı sürüme yükseltmektir. Linux dağıtımları ve LTS sağlayıcıları yamaları önceden aldı; paket güncellemesi için sağlayıcınızı kontrol edin. Güncelleme hemen yapılamıyorsa PHP’nin duyurusu iki açık için ayrı ayrı kısmi önlemler listeliyor. Bu ayarların nerede uygulandığı önemli (örneğin ini_set() ya da .user.ini yeterli değil) ve PHP, hiçbirinin kurulumu güvenli hâle getirmediğini, yalnızca belirli saldırı yollarına maruziyeti azalttığını belirtiyor. Güncelleme yapamıyorsanız duyurunun tamamını okuyun ve ayarları sistem yöneticinizle birlikte uygulayın. PHP, 23 Ekim’de ek bir bilgilendirme duyurusu yayımladı: nadir bir yapılandırma ve uygulama kodu birleşiminde ortaya çıkabilen, pratikte olası görülmeyen bir uzaktan kod çalıştırma yolu için (CVE-2026-115560) bir sonraki düzenli sürüme kadar session.upload_progress.enabled=0 ayarını öneriyor; bu ayar CVE-2026-109619 duyurusunda da geçici önlem olarak listelenmişti. Windows için PHP derlemeleri 26 Ekim’de Brotli 1.2.1 ile yenilendi.

Etkilenip etkilenmediğinizi nasıl kontrol edersiniz?

Bu tür bir duyuruda ilk soru “yama var mı” değil, “bizde PHP nerede çalışıyor ve hangisi internetten erişilebilir?” sorusudur. Kurumsal web sitesi, yönetim panelleri, intranet ve portal uygulamaları, eski kampanya siteleri, test ortamları, hosting sağlayıcısında duran siteler ve PHP üzerinde çalışan hazır sistemler (CMS, e-ticaret yazılımları) bu envanterin parçasıdır. Envanteri tam çıkarılamayan bir kurum, yamayı hangi sistemde uygulaması gerektiğini de bilemez.

İnternete açık tüm sistemleri ve her birinde çalışan PHP sürümünü listeleyin. Komut satırındaki php -v çıktısı, web sunucusunun kullandığı PHP ile aynı olmayabilir; Apache ya da FPM’in gerçekte hangi sürümü ve hangi çalışma biçimini (mod_php, FPM vb.) kullandığını ayrıca doğrulayın.
Dağıtım paketlerinde yama, sürüm numarasına yansımadan uygulanmış olabilir; bu durumda numaraya değil paketin değişiklik kaydına bakın.
Barındırma, e-ticaret ya da CMS sağlayıcılarından yama durumunu yazılı olarak isteyin.
Yamalı sürüme geçin; geçemiyorsanız PHP’nin geçici önlemlerini uygulayın ve gerekirse hizmeti geçici olarak erişime kapatmayı değerlendirin.
Yama sonrasında dışarıdan görünen sürüm ve servis bilgisini yeniden kontrol edin; ayarlar ve dağıtım yamaları ise sistem tarafında ayrıca doğrulanmalıdır.
Web sunucularında olağan dışı süreç ve ağ davranışlarını izleyin. Yama, daha önce gerçekleşmiş olabilecek bir ele geçirmeyi ortadan kaldırmaz; bu ihtimali kendi güvenlik ekibinizle ya da sağlayıcınızla ayrıca değerlendirin (bu yazının kapsamı dışındadır).

Sızma testi ve zafiyet taraması bu tür olaylarda ne işe yarar?

Önce sınırı koyalım: Zafiyet taraması ve sızma testi, henüz kamuya açıklanmamış bir açığı önceden bulmak için tasarlanmış araçlar değildir ve hiçbir test bu konuda garanti vermez. Değerleri, böyle bir olayda nelerin etkilendiğini ve etkinin nerede durduğunu görünür kılmalarındadır.

Envanter ve maruz kalma: Dış ağ zafiyet taraması, internete açık IP adreslerinizi, alan adlarınızı ve yayındaki servisleri çıkarır ve servis sürümlerini bilinen zafiyetlerle (CVE) eşler. Böylece “hangi sistemlerimiz dışarıdan görünüyor ve yamasız olma ihtimali taşıyor?” sorusuna dışarıdan bir cevap alırsınız. Sürüm bilgisi her zaman dışarıdan görünmez; kurum içindeki sistemlerde iç ağ zafiyet taraması, mümkün olduğunda kimlik doğrulamalı yapılarak eksik yamaları daha ayrıntılı gösterir. Farkı zafiyet taraması ile sızma testi yazımızda anlattık.
Etkinin sınırlanması: Bir web sunucusu ele geçirilirse saldırgan oradan nereye ulaşabilir? Dış ağ sızma testi ve iç ağ sızma testi bu soruyu, ağ bölümlendirmesi, yetkiler ve sunucudaki gizli bilgiler açısından kontrollü biçimde sınar. Yamadan önce de sonra da önemli olan, tek bir açığın tüm ağa yayılmasını engelleyen katmanların gerçekten çalışıp çalışmadığıdır.
Yeniden test: Düzeltmeler uygulandıktan sonra yapılan yeniden test ve doğrulama raporu, dışarıdan görünen sürüm ve servis bilgisinin düzeldiğini gösterir. Dışarıdan yapılan bir tarama php.ini ayarlarını ya da dağıtım yamalarını göremez; bunların sistem tarafında ayrıca doğrulanması gerekir.

Seemarter Security ile

Dış ağınızın mevcut durumunu görmek için dış ağ zafiyet taraması ve dış ağ sızma testi hizmetlerimizi inceleyebilir ya da bizimle iletişime geçebilirsiniz. Tüm çalışmalar, sistem sahibinin yazılı yetkisiyle ve önceden belirlenen kapsamda yapılır.

Kaynaklar

Bu yazı 22 Ekim 2026’da yayımlandı; 30 Ekim 2026’da CISA’nın katalog kaydı ve uyarısı ile PHP’nin 23 ve 26 Ekim duyurularına göre güncellendi. Gelişmelere göre güncellenir.

Bir sonraki adım

Kapsamı Birlikte Belirleyelim.

İlk görüşmede varlıklarınızı, zaman pencerelerini ve çalışma kurallarını birlikte netleştiriyoruz. Hiçbir tarama ya da test, yazılı onayınız olmadan başlamaz.

Güvenlik Testi Talep Edin