Temmuz 2026’da PHP için iki ayrı güvenlik güncellemesi dalgası yayımlandı. Üstelik PHP 8.1 artık hiç yama almıyor, PHP 8.2 ise 31 Aralık 2026’da destek dışı kalıyor. Bu rehberde sitenizin risk altında olup olmadığını nasıl anlayacağınızı ve PHP sürümünü güvenle nasıl güncelleyeceğinizi adım adım anlatıyoruz.
Kısa cevap: Siteniz PHP 8.1 veya daha eski bir sürümde çalışıyorsa ya da 8.2.33, 8.3.33, 8.4.24 ve 8.5.9’dan eski bir yamada kalmışsa, 2026’da duyurulan PHP güvenlik açığı kayıtlarından etkilenebilir. Çözüm, önce yedek alıp test etmek, ardından PHP 8.3 veya 8.4’e geçmek ve PHP-FPM’i yeniden başlatmaktır.
2026’da PHP’de hangi güvenlik açıkları ortaya çıktı?
2026 yazında PHP ekibi iki dalga hâlinde güvenlik sürümü yayımladı. İlk dalga 2–3 Temmuz’da geldi ve özellikle PHP-FPM süreçlerini çökertebilen bir hatayı kapattı. İkinci dalga 30 Temmuz’da PHP 8.5.9, 8.4.24, 8.3.33 ve 8.2.33 sürümleriyle yayımlandı. Fransız siber güvenlik merkezi CERT-FR de 7 Temmuz 2026 tarihli CERTFR-2026-AVI-0843 bülteniyle ilk dalgadaki açıklara dikkat çekti.
Şunu baştan belirtelim: elimizdeki kaynakların hiçbiri bu açıkların sahada aktif olarak istismar edildiğini söylemiyor. Yani panik gerektiren bir durum yok; ama ertelemek için de geçerli bir neden yok.
| CVE | Önem | Ne yapıyor? | Etkilenen / düzeltilen sürümler |
|---|---|---|---|
| CVE-2026-12184 | Yüksek (CVSS v4 8.2) | HTTP stream wrapper’da TLS kurulumu başarısız olduğunda oluşan hata. Uzaktaki bir saldırgan PHP-FPM sürecini tüm worker’larıyla birlikte çökertebilir; FPM yeniden başlayana kadar site kapalı kalır. | 8.3.0–8.3.31, 8.4.0–8.4.20, 8.5.0–8.5.5 etkileniyor. Düzeltme: 8.3.32, 8.4.21, 8.5.6 |
| CVE-2026-14355 | Orta (CVSS 3.1 5.6) | OpenSSL eklentisindeki AES-WRAP-PAD, çıktı arabelleğini yanlış boyutlandırıyor; heap bozulması ve hizmet kesintisi (DoS) yaşanabiliyor. | 8.2.32, 8.3.32, 8.4.23 ve 8.5.8 öncesi. 7.x ve 8.1 de etkileniyor ama resmî yama yok |
| CVE-2026-17543 | Yüksek | ext-pgsql fonksiyonlarında (pg_insert, pg_update, pg_select, pg_delete) ters eğik çizginin hatalı kaçışlanmasından doğan SQL enjeksiyonu. | Yalnızca ext-pgsql ile PostgreSQL kullanan siteler. Düzeltme: 30 Temmuz sürümleri |
| CVE-2026-7260 | — | Phar eklentisinde, döngüsel veya özyinelemeli sembolik bağlantılar içeren arşivlerle hizmet kesintisi. | Düzeltme: 30 Temmuz sürümleri |
| CVE-2026-9672 | — | PHP ile birlikte gelen libgd kütüphanesi güncellendi. | Düzeltme: 30 Temmuz sürümleri |
| CVE-2026-17544 | — | BCMath bccomp() fonksiyonunda sınır dışı yazma. | Yalnızca 8.4 ve 8.5. Düzeltme: 8.4.24, 8.5.9 |
PHP-FPM açığı neden en çok konuşulanı?
CVE-2026-12184, ziyaretçinin değil sunucunun dışarıya yaptığı HTTPS isteklerinde ortaya çıkıyor. file_get_contents() veya stream fonksiyonlarıyla dış bir adrese bağlanan uygulamalar (örneğin bir proxy üzerinden API çağıran eklentiler) risk altında. Sonuç veri sızıntısı değil, sitenin tamamen erişilemez hâle gelmesi. E-ticaret sitesi veya kampanya döneminde reklam trafiği alan bir açılış sayfası için birkaç dakikalık kesinti bile ciddi kayıp demek.
PHP 8.2 destek sonu ne zaman, hangi sürümler artık güvenli değil?
PHP’nin resmî destek takvimine göre her ana sürüm önce iki yıl aktif destek, ardından iki yıl yalnızca güvenlik desteği alıyor. Bugün (22 Ekim 2026) itibarıyla tablo şöyle:
| Sürüm | Durum | Güvenlik desteği bitişi | Önerimiz |
|---|---|---|---|
| 7.4 ve 8.0 | Destek dışı | Çoktan bitti (7.4: 28 Kasım 2022) | Acilen yükseltin |
| 8.1 | Destek dışı | 31 Aralık 2025 | Acilen yükseltin |
| 8.2 | Yalnızca güvenlik | 31 Aralık 2026 | Yıl bitmeden 8.3/8.4’e geçin |
| 8.3 | Yalnızca güvenlik | 31 Aralık 2027 | Güvenli hedef |
| 8.4 | Aktif destek (31 Aralık 2026’ya kadar) | 31 Aralık 2028 | Güvenli hedef, en uzun soluklu seçeneklerden |
| 8.5 | Aktif destek (31 Aralık 2027’ye kadar) | 31 Aralık 2029 | Eklentileriniz destekliyorsa uygun |
| 8.6 | Sürüm adayı (RC3, 6 Ekim 2026) | Henüz kararlı değil | Canlı sitede kullanmayın |
Rakamlar sorunun ne kadar yaygın olduğunu da gösteriyor: WordPress.org’un 27 Eylül 2026 istatistiklerine göre veri gönderen WordPress sitelerinin %16,7’si hâlâ PHP 7.4 ile çalışıyor. Yani her altı WordPress sitesinden biri, yıllardır yama almayan bir sürümde.
Hangi PHP sürümüne geçmeliyim?
Çoğu kurumsal site, WordPress ve WooCommerce projesi için bugün en mantıklı hedef PHP 8.3 veya 8.4. 8.3 eski eklentilerle daha az sürpriz çıkarıyor ve 2027 sonuna kadar güvende. 8.4 ise 2028 sonuna kadar yama alacağı için bir sonraki zorunlu geçişi daha da ileri atıyor. 8.5’i, kullandığınız tema ve eklentilerin geliştiricileri resmî olarak destek verdiğini açıkladıysa tercih edebilirsiniz. 8.2’ye geçmek ise sadece iki aylık bir nefes almak olur; önermiyoruz.
Önemli bir not: Ubuntu, RHEL, AlmaLinux veya Rocky Linux gibi dağıtımların kendi paketlerini kullanıyorsanız, düzeltmeler eski sürüm numarasına geri taşınabiliyor (backport). Örneğin Ubuntu’nun 20 Temmuz 2026 tarihli USN-8564-1 bülteni bu tür bir güncelleme. Bu durumda php -v çıktısında 8.3.33 görmeseniz bile sisteminiz yamalı olabilir; dağıtımın güvenlik bültenini kontrol edin.
PHP sürümümü nasıl kontrol ederim?
Kontrol için birkaç yol var, birini seçmeniz yeterli:
- Hosting paneli: Hostinger hPanel, cPanel veya CloudPanel’in PHP ayarları sayfası, sitenin o an kullandığı sürümü gösterir.
- WordPress: Araçlar → Site Sağlığı → Bilgi → Sunucu bölümünde PHP sürümü yazar.
- Komut satırı: SSH erişiminiz varsa
php -vkomutunu çalıştırın. Komut satırı ile web sunucusunun kullandığı PHP farklı olabilir, bunu da unutmayın. - phpinfo sayfası: Geçici olarak
<?php phpinfo();içeren bir dosya oluşturup açın, sürümü not alın ve dosyayı hemen silin.
Birden fazla siteniz varsa her birini tek tek kontrol edin. Aynı hosting hesabındaki siteler farklı PHP sürümleri kullanabilir.
PHP sürümü adım adım nasıl güncellenir?
Hangi altyapıyı kullanırsanız kullanın, ilk iki adım aynı: yedek ve test. Sonrası panelinize göre değişir.
- Tam yedek alınDosyaları ve veritabanını birlikte yedekleyin. Hosting firmanızın otomatik yedeği olsa bile, geri dönüş noktasını kendiniz belirleyin.
- Eklenti, tema ve çekirdeği güncelleyinPHP’yi değiştirmeden önce WordPress çekirdeğini, tüm eklentileri ve temayı güncelleyin. Eski kodlar yeni PHP sürümünde en sık sorun çıkaran kaynaktır. Mümkünse önce bir staging (test) kopyasında deneyin.
- Hostinger hPanelWebsites → Manage → Advanced → PHP Configuration yolunu izleyin, yeni sürümü seçip Update’e basın. İşlem 1–2 dakika sürer. Hostinger eski sürümleri listeden gizlese de mevcut eski sürümünüzü otomatik olarak değiştirmez. Yükseltmeden sonra (aynı oturum dışında) eski sürüme dönülemez ve PHP eklentileri varsayılana sıfırlanır; ionCube gibi eklentileri yeniden açmanız gerekebilir.
- cPanelSoftware → MultiPHP Manager bölümünden alan adını seçip yeni sürümü atayın. CloudLinux kullanan sunucularda bu ekran “Select PHP Version” adıyla görünür.
- Hostinger VPS + CloudPanelSites → Manage → Settings → PHP Settings → PHP Version alanından yeni sürümü seçip Save’e tıklayın.
- Panelsiz Ubuntu VPSÖnce
sudo apt update && sudo apt upgradeile sistemi güncelleyin. Ardındansudo apt install php8.3-fpmile yeni sürümü kurun (daha yeni dallar için ondrej/php PPA’sı gerekebilir). Nginx veya Apache yapılandırmanızı ve FPM havuzunuzu yeni sürüme yönlendirin. - PHP-FPM ve web sunucusunu yeniden başlatınÖrneğin
sudo systemctl restart php8.3-fpmvesudo systemctl restart nginx(veyaapache2). Docker kullanıyorsanız konteynerleri yeniden oluşturun. Yeniden başlatma yapılmazsa yamalı dosya diskte durur ama bellekte eski süreç çalışmaya devam eder. - Doğrulayın
php -v, phpinfo veya WordPress Site Sağlığı ekranıyla yeni sürümü teyit edin; ardından ana sayfa, iletişim formu, ödeme ve yönetim paneli gibi kritik sayfaları elle gezin.
Güncellemeden sonra site bozulursa ne yapmalıyım?
Beyaz ekran, “critical error” mesajı ya da bozuk bir sayfa görürseniz sakin olun; sorun genellikle tek bir eklenti veya temadır.
- Hata kaydını okuyun: Hosting panelindeki error log veya WordPress’in
WP_DEBUG_LOGayarı, hangi dosyanın hata verdiğini gösterir. - Sorunlu eklentiyi devre dışı bırakın: Yönetim paneline giremiyorsanız FTP veya dosya yöneticisiyle ilgili eklentinin klasör adını değiştirmeniz yeterli.
- Eksik PHP eklentilerini kontrol edin: Sürüm değişince eklentiler varsayılana dönebilir; ionCube, intl veya imagick gibi modülleri yeniden etkinleştirin.
- Gerekirse geri dönün: Panelinizin izin verdiği durumlarda önceki sürüme dönün ya da aldığınız yedeği geri yükleyin. Hostinger’da yükseltme sonrası düşürmenin sınırlı olduğunu unutmayın; bu yüzden önce test şart.
PHP güvenlik kontrol listesi: güncelleme dışında neler yapmalı?
Sürüm güncellemek en önemli adım, ama tek başına yeterli değil. Yönettiğimiz sitelerde uyguladığımız kısa liste şu:
- Düzenli ve test edilmiş yedekler: Yedeğin gerçekten geri yüklenebildiğini ara ara deneyin.
- Staging ortamı: Her büyük değişikliği önce test kopyasında yapın.
- Önce eklenti ve temalar: PHP’yi değiştirmeden önce tüm bileşenleri güncel tutun.
- WAF veya Cloudflare: Bir web uygulama güvenlik duvarı, kötü niyetli istekleri sunucuya ulaşmadan süzer.
- Kullanılmayan eklentileri kapatın: PostgreSQL kullanmıyorsanız pgsql, Phar’a ihtiyacınız yoksa phar eklentisi kapalı kalabilir; her açık eklenti ek bir saldırı yüzeyidir.
- En az yetki ilkesi: Veritabanı kullanıcısına ve dosya izinlerine yalnızca gerekenleri verin.
- İzleme: Uptime takibi ve hata kaydı uyarıları, FPM çökmelerini müşteriden önce sizin fark etmenizi sağlar.
- Otomatik güvenlik güncellemeleri: VPS’te
unattended-upgradesgibi bir araçla güvenlik paketlerini otomatik kurun. - Yamadan sonra yeniden başlatma: PHP-FPM, web sunucusu ve konteynerler yeniden başlatılmadan yama devreye girmez.
Ajanslar ve çok sayıda site yönetenler nasıl ilerlemeli?
Onlarca müşteri sitesini aynı hosting hesabında barındıran ajanslar için asıl zorluk teknik değil, organizasyonel. Tek tek panel gezmek yerine önce bir envanter çıkarın: her sitenin alan adı, kullandığı PHP sürümü, CMS türü, kritik eklentileri ve son yedek tarihi tek bir tabloda dursun. Ardından siteleri risk sırasına göre gruplayın. PHP 7.4, 8.0 ve 8.1 kullananlar ilk grupta, 8.2 kullananlar ikinci grupta yer almalı.
Her grup için önce temsilî bir pilot site seçin, güncellemeyi orada deneyin ve sorun çıkmazsa aynı yapılandırmayı diğer sitelere uygulayın. Müşterilerinize de kısa bir bilgilendirme gönderin: hangi gün, hangi saat aralığında işlem yapılacağını ve olası bir sorunda nasıl geri dönüleceğini açıklayın. Bu şeffaflık, hem güven oluşturur hem de olası bir hata raporunun size hızlı ulaşmasını sağlar. İşlem bittikten sonra envanter tablonuzu güncelleyin ve bir sonraki kontrol tarihini, yani en geç PHP 8.3’ün destek sonu olan 31 Aralık 2027’den önceki bir tarihi, takviminize ekleyin.
Akılda kalması gerekenler
Bu konunun İngilizce sürümünü PHP vulnerability 2026 update guide sayfasında okuyabilirsiniz. Sitenizde SEO kontrolleri yaparken işinize yarayabilecek ücretsiz URL çözücü ve SEO araçlarımıza da göz atabilirsiniz.
PHP güncellemesini birlikte yapalım
Sitelerinizin PHP sürümünü denetleyip yedekli, test edilmiş ve kesintisiz bir geçiş planlıyoruz. Tek siteniz de olsa, yüzlerce siteniz de olsa yazın.
Sık sorulan sorular
PHP güvenlik açığı sitemi nasıl etkiler?
Açığın türüne göre değişir. 2026’daki en önemli açıklar çoğunlukla hizmet kesintisine yol açıyor; örneğin CVE-2026-12184 PHP-FPM’i çökertip siteyi erişilemez hâle getirebiliyor. PostgreSQL kullanan sitelerde ise CVE-2026-17543 SQL enjeksiyonu riski taşıyor.
Sitemin hangi PHP sürümünü kullandığını nasıl öğrenirim?
Hosting panelinizin PHP ayarları sayfasına, WordPress’te Araçlar → Site Sağlığı → Bilgi → Sunucu bölümüne bakabilir, SSH ile php -v komutunu çalıştırabilir ya da geçici bir phpinfo sayfası açabilirsiniz.
PHP 8.2 destek sonu ne zaman?
PHP 8.2’nin güvenlik desteği 31 Aralık 2026’da sona eriyor. Bu tarihten sonra yeni açıklar için resmî yama yayımlanmayacak; şimdiden 8.3 veya 8.4’e geçmenizi öneriyoruz.
PHP 8.1 kullanmaya devam edebilir miyim?
Önermiyoruz. PHP 8.1’in desteği 31 Aralık 2025’te bitti. CVE-2026-14355 gibi 8.1’i de etkileyen açıklar için resmî yama yok.
Güvenli PHP sürümü hangisi?
Bugün için minimum güvenli yamalar 8.2.33, 8.3.33, 8.4.24 ve 8.5.9 veya daha yenileri. Hedef olarak PHP 8.3 veya 8.4’ü öneriyoruz.
WordPress PHP güncellemesi sitemi bozar mı?
Güncel tema ve eklentilerle genellikle sorun çıkmaz. Eski veya bakımsız bir eklenti hata verebilir; bu yüzden önce yedek alın, eklentileri güncelleyin ve mümkünse staging ortamında test edin.
Hostinger PHP sürümümü otomatik olarak güncelliyor mu?
Hayır. Hostinger eski sürümleri seçim listesinden gizliyor ama mevcut eski sürümünüzü otomatik olarak değiştirmiyor. Güncellemeyi hPanel’de Websites → Manage → Advanced → PHP Configuration yolundan sizin yapmanız gerekiyor.
PHP’yi güncelledikten sonra eski sürüme dönebilir miyim?
Panele göre değişir. Hostinger’da yükseltmeden sonra, aynı oturum dışında eski sürüme dönülemiyor. Bu yüzden değişiklikten önce yedek almak ve test etmek çok önemli.
Güncellemeden sonra PHP-FPM’i yeniden başlatmak neden gerekli?
Çalışan PHP-FPM süreçleri eski kodu bellekte tutar. Yeniden başlatmadan yamalı sürüm devreye girmez; VPS’te php-fpm ve web sunucusunu, Docker’da konteynerleri yeniden başlatmanız gerekir.
Ubuntu’da php -v eski bir numara gösteriyor, sistemim yamasız mı?
Mutlaka değil. Ubuntu ve RHEL tabanlı dağıtımlar düzeltmeleri eski sürüm numarasına geri taşıyabiliyor. USN-8564-1 gibi dağıtım güvenlik bültenlerini kontrol ederek paketinizin yamalı olup olmadığını öğrenebilirsiniz.
Kaynaklar
- PHP.net – Supported Versions
- NVD – CVE-2026-14355
- oss-security – 30 Temmuz 2026 PHP güvenlik sürümleri
- Ubuntu Security Notice USN-8564-1
- Pantheon – PHP 8.2/8.3/8.4/8.5 güvenlik güncellemeleri
- Zend Security Center
- Hostinger – PHP sürümü nasıl değiştirilir
- CraftedSignal – Temmuz 2026 PHP açıkları özeti
ITC – International Technology Center · SEO hizmetleri · İletişim
