PHP2Shell: dünya PHP'deki açığı yamarken kendi sunucularımda neyi kontrol ediyorum

21 Ekim'de PHP projesi, yorumlayıcının kendisindeki iki açık için düzeltme yayımladı: CVE-2026-109618 ve CVE-2026-109619. Açıklara php2shell adı verildi. Bunlar üzerinden sunucuda kullanıcı adı ve şifre olmadan kod çalıştırılabiliyor, PHP 5.4'ten itibaren bütün sürümler etkileniyor. Şirketinizin PHP üzerinde çalışan bir sitesi, paneli ya da iç servisi varsa, bu hafta güncellenmesi gerekiyordu. Aşağıda bu tür haftaların bende nasıl geçtiğini anlatıyorum.

Ne oldu ve sürüm neden bir gün öne alındı

Simon Willison 21 Ekim'de PHP Foundation'ın duyurusunu özetledi: 20 Ekim'de saat 15:00 UTC civarında CVE numaraları forumlara sızdı, üstelik yanlış bir puanla, 10.0 olarak (gerçek puan 9.2). Proje de sürümü 22 Ekim'den 21 Ekim'e aldı. Açığı bildiren firmalardan biri olan Calif, yanlışlıkla çalışan bir exploit'in videosunu yayımladı. Aynı yazıda Wiz'in kronolojisi de var: açık 19 Ağustos'ta bulundu, 24 Ağustos'ta PHP ekibine bildirildi.

Cloudflare 21 Ekim'de mekanizmayı açıkladı: iki açık da PHP'nin hata anında belleği nasıl yönettiğiyle ilgili. Buradan yapışkan bir nota yazılacak iki şey çıkıyor. Eklentiyi ya da sitenin kodunu güncellemek işe yaramaz, PHP'nin kendisini düzeltmek gerekir. PHP'yi hosting firması çalıştırıyorsa güncellemeyi ondan istemek gerekir. Cloudflare WAF kurallarını açıklamadan 9 saat önce devreye aldı. 23 Ekim'de aynı yazıya bir ek geldi: bağlantılı yeni bir açık çıktı, CVE-2026-115560. Güncellenmiş 8.5.12'de bile var ve bir sonraki planlı sürümde düzeltilecek.

Ubuntu 21 Ekim'de düzeltilmiş paketlerin tablosunu, 14.04'teki php5'ten 26.10'daki php8.5'e kadar, kontrol komutuyla birlikte yayımladı: apt list '?installed ?name(^php[0-9.]+$)'. Aynı yerde bir hatırlatma var: unattended-upgrades yamayı 24 saat içinde kurar, ama PHP süreçleri bundan dolayı yeniden başlamaz. Docker 22 Ekim'de resmi imajların yamalardan sonraki 24 saat içinde güncellendiğini bildirdi: 8.2.35, 8.3.36, 8.4.27 ve 8.5.12. Hemen güncelleyemiyorsanız Docker sistemi kapatmayı öneriyor ve FBI'ın aynı yöndeki tavsiyesine atıf yapıyor.

GitLab 22 Ekim'de bence en pratik notu yayımladı. Ubuntu ve Red Hat düzeltmeyi eski sürüm numarasını koruyarak backport ediyor, bu yüzden paket sürümlerini karşılaştırmak gerekiyor. php -v burada sizi yanıltır. php:8.3 gibi kayan etiketli imajları docker build --pull ile yeniden derleyin. wordpress ya da drupal gibi türetilmiş imajlar ise düzeltmeyi ancak bakımcıları yeni sürümü çıkardıktan sonra alır. Bir de genelde unutulanların listesi var: iç dashboard, pazarlama sitesi, CI imajı.

OpenAI 21 Ekim'de koordinasyonu anlattı: açığı Calif, GPT-5.6 Sol modelinin yardımıyla buldu, Wiz da bağımsız olarak buldu, düzeltmeleri PHP bakımcıları yürüttü. OpenAI bu tür bulguların artmasını bekliyor. OVHcloud 21 Ekim'de VPS sahipleri için bir talimat yayımladı: sürümü kontrol edin, güncelleyin, PHP servislerini yeniden başlatın. Percona 23 Ekim'de rapor verdi: Cloudflare kuralları yama çıkmadan önce yerindeydi, yama hemen kuruldu, sızma izi bulunmadı.

“Bizde PHP yok” diyen şirketi bu neden ilgilendiriyor

Bir araç kiralama şirketini ele alalım. Rezervasyon sitesini üç yıl önce bir yüklenici yaptı, site bir hostingde duruyor ve hangi dilde yazıldığını şirkette kimse hatırlamıyor. Şirket sahibi kendisinde PHP olmadığından emin. Cloudflare'in verilerine göre PHP sitelerin neredeyse %70'inde çalışıyor. Yani çoğu zaman PHP vardır, hem de kimsenin sorumlu olmadığı yerde.

Şirket sahibi için sonuç: “bizde PHP üzerinde ne çalışıyor” listesi, bir sonraki böyle açık çıkmadan önce hazır olmalı. Sakin bir haftada bu liste bir saatte çıkarılabilir.

Bende nasıl kurulu

ABD'deki PDR şirketinin sunucusunu 2022'den beri ben yönetiyorum: Google Cloud'da Debian, üzerinde MariaDB veritabanı, API, site ve telefon sistemi. Şirkette güvenlik soruları bana geliyor. Dünyada büyük bir saldırı olduğunda bizi ilgilendirip ilgilendirmediğine bakıyorum. Ana backend'imiz Node.js ve Python üzerinde, ama bu kontrolü gereksiz kılmıyor: sunucuda ve container'larda kurulu her şeyin listesinden geçiyorum ve paket sürümlerine bakıyorum. Sunucuyu, VPN'i ve telefon sistemini yükleniciyle yazışmadan kendim yönetiyorum. 2022'den beri geri yükleme gerektiren ciddi bir arızamız olmadı.

Stüdyonun sitesi ve şirket içi bir servis olan “Birlikte Kahve”, 2 GB belleği olan ortak bir sunucuda, Nginx arkasında Docker'da çalışıyor. “Birlikte Kahve” için sıra şöyle: güncellemede eski örnek, yenisi başlamadan önce durduruluyor. Derlemeye bellek yetmezse imaj sunucunun dışında derleniyor ve hazır olarak yükleniyor.

Bu hafta ne yapardım

1. PHP'nin çalıştığı her yerin listesini çıkarmak: hostingdeki siteler, paneller, forumlar, Docker imajları, CI imajları.
2. Paketi güncellemek ve PHP çalıştıran her süreci yeniden başlatmak. Paket sürümünü kontrol etmek.
3. Container'ları --pull ile yeniden derlemek, türetilmiş imajları bakımcının yayın tarihine göre kontrol etmek.
4. Şu an güncellemek mümkün değilse WAF'ı açmak, dosya yüklemeyi kısıtlamak, en kötü durumda servisi kapatmak.
5. 20-23 Ekim loglarında tuhaf istekleri ve yeni dosyaları aramak, bir sonraki PHP sürümünden sonra konuya geri dönmek.

Bir de sızma yine de olduysa diye, en az bir kez gerçekten geri yükleme yaptığınız bir yedek tutmak.

İlgili içerikler

Sistemin neden durumu saklayan ve yetkileri kontrol eden tek bir sunucuya ihtiyacı olduğunu Sunucu: veri, erişim ve sürecin yürütülmesi yazısında anlattım. Hizmet alanı: yayınlanabilen ve geri yüklenebilen altyapı. PDR şirketinin sunucusu ABD'deki PDR şirketinin teknik ortağı projesinde ve Google Cloud'da Debian sayfasında anlatılıyor. Aynı konuda: Node.js, Python ve Next.js'i güncelleme düzenim, 30 kişilik şirket için zero trust ve kimsenin geri yüklemediği yedek. Daha önce düzeltilecek açıkların nasıl seçileceğini ve SBOM ile provenance'ın ne olduğunu yazmıştım. Uzun zamandır kimsenin sorumlu olmadığı bir sunucunuz varsa, üzerinde ne kurulu olduğunu anlatın: Görevi konuşalım.