PHP2Shell: PHP'deki kritik açık nedir, ne kadar ciddi, ne yapmalı?

Bu yazı 22 Ekim 2026 itibarıyla bilinenleri anlatıyor. Olay hâlâ gelişiyor; özellikle saldırı verileri saatler içinde değişebilir. Bu yüzden yazıda hangi bilginin resmî kaynaktan, hangisinin bir güvenlik şirketinin kendi iddiasından geldiğini ayırmaya çalıştım.

21 Ekim 2026'da PHP ekibi, iki kritik güvenlik açığını kapatan acil bir sürüm yayımladı. Açıklar CVE-2026-109618 ve CVE-2026-109619 numaralarını taşıyor ve ikisi de CVSS 4.0 ölçeğinde 9,2 puan aldı. PHP'nin açıklamasına göre bu açıklar, kimlik doğrulaması olmadan uzaktan kod çalıştırmaya yol açabiliyor. Olay güvenlik dünyasında "PHP2Shell" adıyla anılıyor. Reuters'ın aktardığına göre Avrupa'da bazı kamu siteleri kapatıldı ve Wikipedia'yı işleten Wikimedia bazı sistemlerini devre dışı bıraktı.

Kısa özet: açık gerçek ve ciddi, çözüm var ve çözüm bir güncelleme. "Tüm internet tehdit altında" cümlesi ise ancak yarı doğru. Aşağıda neden öyle olduğunu adım adım anlatıyorum.

PHP nedir ve neden bu kadar önemli?

PHP, web sitelerinin sunucu tarafında çalışan bir programlama dili. Tarayıcınıza gelen sayfayı çoğu zaman önce sunucuda PHP hazırlıyor: veritabanından yazıyı çekiyor, şablona yerleştiriyor, HTML'e çeviriyor. Bunu bir restoranın mutfağına benzetebiliriz. Siz masada yalnızca tabağı görüyorsunuz, PHP ise arkada yemeği pişiriyor.

W3Techs'in 22 Ekim 2026 verisine göre, sunucu tarafı dili bilinen sitelerin yüzde 69,3'ü PHP kullanıyor. WordPress, Drupal, Joomla, Laravel gibi çok bilinen sistemlerin hepsi PHP üzerinde çalışıyor. Bu yüzden açık, bir WordPress eklentisinde değil, WordPress'in altındaki yorumlayıcıda. Aynı W3Techs sayfasına göre PHP kullanan sitelerin yüzde 65,3'ü PHP 8 serisinde, yüzde 26,9'u PHP 7'de, yüzde 7,7'si PHP 5'te. Yani PHP kullanan sitelerin yaklaşık üçte biri çoktan desteği bitmiş serilerde duruyor.

Ne oldu? İki günlük olay özeti

Huntress'in anlatımına göre 20 Ekim sabahı bir sosyal medya paylaşımı, PHP'de iki kritik açığın duyurulmak üzere olduğunu iddia etti. Paylaşım kaldırıldı ama ekran görüntüleri yayıldı. watchTowr bunun sızıntı olduğunu doğruladı; açıklamanın aslında Perşembe günü yapılması bekleniyordu. PHP ekibi de aynı gün, 21 Ekim 14.00 UTC'ye planlı bir ön duyuru yaptı ve ayrıntılar kamuya çıkarsa ya da saldırı kanıtı görülürse sürümü erkene alma hakkını saklı tuttuğunu yazdı.

Düzeltmeler CERT-EU'ya göre 21 Ekim'de 13.30 UTC'de, yani planlanandan biraz önce yayımlandı. Aynı gün akşam saatlerinde Calif ve Wiz araştırmacıları teknik ayrıntıları paylaştı. Wiz, WordPress, Drupal ve Joomla'nın o günkü en güncel konteyner imajlarında kimlik doğrulamasız uzaktan kod çalıştırmayı gösterdi. Bunlar kontrollü test ortamlarındaki gösterimlerdi.

Açık tam olarak nedir? Teknik bilmeden anlamak

Tek cümleyle: PHP bazen, temizlediğini sandığı ama aslında yarım ya da eski kalmış bir bilgiye güveniyor. Saldırgan da bu güveni kendi hazırladığı veriyle kötüye kullanabiliyor.

Biraz açalım. Sitenize gelen her ziyaretçi isteğini PHP bir "işçi"ye veriyor. İşçi, işi yaparken bilgisayarın belleğini bir not defteri gibi kullanıyor. İş bitince defterin sayfalarını yırtıp atıyor, yani belleği boşaltıyor. İki açık da bu toplama ve boşaltma işinin bir yerde bozulmasından çıkıyor.

• CVE-2026-109618, defter dolunca: Defter dolarsa işçi işi yarıda bırakıyor. Sayfa yarım dolu kalıyor ama temizlik adımı onu tam dolu sanıp işliyor. Yarım kalmış bir sayfanın yanlış işlenmesi, saldırgana kapı aralayabiliyor.
• CVE-2026-109619, eski kalıntı: İş bitince sayfalar atılıyor ama işçinin cebinde o sayfaların adresi kalmış olabiliyor. Aynı işçiye gelen sonraki istek bu adrese bakınca orada artık başka bir şey duruyor olabiliyor. O şeyi saldırgan hazırlamışsa sonuç tehlikeli oluyor.

Bunun adı "kimlik doğrulamasız uzaktan kod çalıştırma". Yani saldırganın sitenizde hesabı olması gerekmiyor. İnternetten özel hazırlanmış bir istek göndermesi yeterli olabiliyor ve sunucu onun istediği komutu çalıştırabiliyor. Bu, sunucunun kontrolünün kaybı demek.

En riskli kurulum PHP'ye göre Apache'nin mod_php modülü. Orada saldırı, sitenizin kendi kodu çalışmadan önce bile tetiklenebiliyor. PHP-FPM, php-cgi, FrankenPHP ve LiteSpeed da etkilenen ortamlar arasında.

JFrog'un anlatımına göre yollardan biri, dosya yüklenirken ilerleme çubuğunu besleyen bir özellikten geçiyor ve bu özellik varsayılan olarak açık. Geçici önlemlerden birinin o özelliği kapatmak olmasının sebebi bu. Wiz ayrıca, kod çalıştırmadan yalnızca işçinin "defterini okuyarak" parola ve anahtar gibi bilgilere ulaşılabildiğini gösterdi. Bu, Wiz'in kendi iddiası ve gösterimi.

Kimler etkileniyor?

• Düzeltilmiş sürümler: PHP 8.5.12, 8.4.27, 8.3.36 ve 8.2.35. Bunlardan eski olan 8.5, 8.4, 8.3 ve 8.2 sürümleri savunmasız.
• PHP 8.1 ve daha eski sürümler PHP projesinden güncelleme almıyor. Bazı Linux dağıtımları ve uzun süreli destek satıcıları kendi yamalarını veriyor. PHP ekibi ayrıca 7.4, 8.0 ve 8.1 için kaynaktan derleyenlere minimal yama sundu.
• PHP kullanmayan siteler bu açıktan doğrudan etkilenmez, çünkü açık PHP yorumlayıcısında. DonanımHaber'in haberinde Squarespace ve Wix gibi PHP tabanlı olmayan platformların aynı şekilde etkilenmediği belirtiliyor. Yine de kullandığınız bir hizmetin arkasında PHP olup olmadığını her zaman bilemezsiniz.
• Uygulama değil çalışma ortamı sorunlu. WordPress'i, eklentileri ya da temayı güncellemek tek başına açığı kapatmaz; PHP'nin kendisinin güncellenmesi ve hizmetlerin yeniden başlatılması gerekir.
• Dağıtımlar yamayı sürüm numarasını değiştirmeden uygulayabilir. Yalnızca php -v çıktısına bakmak yetmez; satıcının güvenlik duyurusunu kontrol etmek gerekir.

Wiz'in araştırması PHP 5.4'e kadar uzanan sürümlerin etkilendiğini söylüyor. CyberScoop'a göre CERT-EU da PHP 5 ve sonrasının etkilenebileceğini yazmış. watchTowr ise bu kapsamın resmî olarak doğrulanmadığını not ediyor ve PHP'nin duyurusu da geriye dönük bir liste vermiyor. Desteği bitmiş serilerde kesin bir liste olmadığı için en güvenli varsayım, hepsinin savunmasız olduğu.

Türkiye'den resmî uyarı

T.C. Siber Güvenlik Başkanlığı 21 Ekim 2026'da konuyla ilgili bir haber duyurusu yayımladı. Duyuruya göre Başkanlık, olası risklerin erken tespiti için ulusal ölçekte güvenlik taramaları başlattı ve ilgili kurum ve kuruluşlara acil güvenlik bildirimleri iletti. Kamu kurumlarından, kritik altyapı işletmecilerinden ve özel sektörden sistemlerini gözden geçirip güncellemeleri ivedilikle uygulamaları isteniyor.

Teknik tedbirler TR-26-1372 numaralı güvenlik bildiriminde yer alıyor. Bildirim, PHP'nin resmî duyurusu henüz yayımlanmadan hazırlanmış; bu yüzden güncellemenin çıkmasını takiben harekete geçilmesini söylüyor. İki CVE numarasını ve açıkların uzaktan kod çalıştırmaya yol açabileceğini belirtiyor. Önerileri şöyle:

• Güncelleme yayımlanınca etkilenen sistemleri belirlemek ve üreticinin güvenli sürümlerine gecikmeden geçmek.
• Yönetim arayüzlerine ve kritik PHP servislerine dış erişimi, güvenlik duvarı kurallarıyla yalnızca güvenilir ve yetkili IP adreslerine sınırlamak.
• Yurt dışı erişim ihtiyacı olmayan sistemleri uluslararası trafiğe kapatmak.

Okuduğum metinlerde taramaların sonucu ya da Türkiye'de kaç sistemin etkilendiği hakkında bir bilgi yok. Bu yüzden Türkiye'deki etkinin boyutuna dair bir sayı vermiyorum.

Abartıldı mı? Neye inanmalı?

Ciddiyeti destekleyen unsurlar güçlü: iki açık da kimlik doğrulaması istemiyor, PHP bir istismar gösterimi olduğunu kendisi belirtiyor, bağımsız araştırmacılar önde gelen yazılımlarda kod çalıştırmayı gösterdi, CISA ve CERT-EU acil uyarı yayımladı. Haberdeki "kamu siteleri kapandı" bilgisi de boş bir panik göstergesi değil. Kurumlar, yama gelene kadar sistemi kapatmanın, açık bırakmaktan ucuz olduğuna karar verdi.

Öte yandan abartı payı da var ve çoğu sömürü durumu ile sayılar etrafında toplanıyor.

• Saldırı bilgisi çelişkili. CISA yayın anında sömürü gözlemlemediğini yazdı. Huntress, 21 Ekim'de kendi görebildiği sistemlerde sömürü görmediğini söyledi. Patchstack, ortak barındırma firmalarından "çok sayıda aktif sömürü" bildirimi aldığını yazdı ama o günün öğleden sonrasında kendi verisinde yalnızca tarama ve yoklama gördü. Cloudflare'ın teknoloji yöneticisi erken saldırılar gördüklerini söyledi. watchTowr kendi tuzak ağında sömürü gördüğünü yazdı, ama bu şirketin kendi gözlemi. Bunların hiçbiri "internet çöktü" demiyor; ama "hiçbir şey olmuyor" da demiyor.
• Sayılar tutarsız. CyberScoop, 1,3 milyondan fazla ve Shodan'a göre yaklaşık 1,9 milyon internete açık sunucudan söz ediyor. Reuters'ın aktardığı Censys verisine göre PHP sürümü bildiren 2,6 milyon sunucunun yaklaşık 1,5 milyonu düzeltmesi olmayan bir sürümde. Bir de VirusTotal'ın sayımı var: sürümünü açıkça bildiren sunucular arasında yaklaşık 758 bini PHP 5.4 ile 8.1 arasındaki, desteği bitmiş sürümlerde; yaklaşık 272 bini desteklenen dallarda. Bunlar "açıkta olan" sunucu sayısı. Hepsinin istismar edilebilir olduğu anlamına gelmiyor, çünkü etkilenen sürümler resmî olarak sınırlı ve kurulum ayarları sonucu değiştiriyor.
• Sahte istismar kodları dolaşıyor. JFrog, GitHub'da yayımlanan bazı sözde kanıt kodlarının sahte olduğunu, birinin masaüstü duvar kağıdını değiştiren bir komut sakladığını yazdı. Güvenlik firmaları da benzer kodların zararlı yazılım içerebileceği konusunda uyarıyor. Kendi sunucunuzda denemeyin.
• Anlatıların arkasında ticari çıkar da var. Keşifte yapay zekâ modelleri kullanan şirketler (OpenAI ve Wiz gibi) bunu kendi ürünlerinin başarısı olarak anlatıyor. Bu doğru olabilir ama ölçülmüş bir sonuç değil.

Benim okumam şöyle: manşetlerdeki "tüm interneti tehdit ediyor" ifadesi, yamasız PHP sunucularını kastettiğinde doğru; yamalı sunucularda ise geçerli değil. Normal bir kullanıcı için panik gerektiren bir durum yok. Ama PHP çalıştıran birinin, "nasılsa sıra bana gelmez" diye beklemesi için de bir gerekçe yok. Bu tür açıklarda sömürü, teknik ayrıntılar kamuya çıktıktan sonra hızlanıyor. Burada ayrıntılar zaten çıktı.

Yapay zekâ boyutu: neden bu kadar konuşuldu?

Olayı farklı kılan, nasıl bulunduğu. Calif araştırmacıları OpenAI'ın "Patch the planet" girişimi kapsamında OpenAI'ın bir modeliyle çalışırken, Wiz de kendi araçlarıyla bağımsız olarak aynı sorunlara ulaştı. Wiz'in kendi anlatımına göre araştırma sırasında Wiz Atlas, Gemini 4 Argon ve GPT-5.6 Sol kullanıldı; modeller karmaşık istismar zincirlerini çözmeye ve farklı kurulumlara uyarlamaya yardım etti. CyberScoop'un aktardığına göre Wiz, hatanın onlarca yıldır koddaki yerinde durduğunu ve istismarının zor olduğunu, yapay zekânın bu zorluğu azalttığını söylüyor. Bunu şirketin kendi değerlendirmesi olarak okumak gerekiyor.

Bunun pratik anlamı, kanıtlanmış bir sayıdan çok yön duygusu. Yaygın, eski ve karmaşık bir kod tabanında uzun süre fark edilmeyen hatalar var ve onları bulmak eskisinden ucuzlamış olabilir. Hem savunmacılar hem saldırganlar için. Bu yüzden yama penceresi, yani açığın duyurulmasıyla kendi sunucunuzu güncellemeniz arasındaki süre kritik hale geliyor.

Son kullanıcı ne yapmalı?

Bir siteniz yoksa yapacağınız şey çok az ve sakin kalmak bunun parçası. Yine de birkaç mantıklı adım var.

• Kullandığınız hizmetlerden gelen güvenlik duyurularını okuyun. Bir hizmet "bellekten veri sızmış olabilir" ya da "parolaları sıfırlayın" derse bunu ciddiye alın ve parolanızı değiştirin.
• Aynı parolayı birden fazla yerde kullanmayın ve mümkünse iki adımlı doğrulama açın. Bir sitenin sunucusundan sızan parola, tekrar kullandıysanız başka hesaplara da yarar.
• Açığı bahane eden sahte "acil güvenlik güncellemesi" e-postalarına ya da bağlantılarına tıklamayın. Bu tür olaylarda dolandırıcılık denemeleri artar.
• Bir site bakımda ya da kapalıysa bu, sitenin yamasını uyguladığının işareti olabilir. Alternatif genellikle daha kötü.
• Tarayıcınızı veya telefonunuzu güncellemek bu açığı kapatmaz; açık sunucu tarafında. Sizin tarafınızdaki en etkili önlem hesap güvenliği.

Site sahipleri ne yapmalı?

Asıl iş bu grupta. Sıra şöyle.

• Envanter çıkarın. Hangi sunucuda hangi PHP sürümü çalışıyor? Başka yazılımların içine gömülü gelen PHP'yi de unutmayın. CISA da gömülü PHP dahil tüm sistemlerin envanterini öneriyor.
• Paylaşımlı hosting kullanıyorsanız sağlayıcınıza yazın: PHP yamasını ne zaman uygulayacaklar, uyguladılar mı? Panelden PHP sürümünüzü desteklenen ve yamalı bir seriye çekebiliyorsanız yapın.
• Kendi sunucunuz varsa paketleri güncelleyin ve ardından Apache, PHP-FPM ve uzun süre çalışan işçi süreçlerini yeniden başlatın. Yeniden başlatma şart; yalnızca paket yüklemek çalışan süreci güncellemiyor. Qualys, yamadan sonra hem kurulu paketlerin hem de çalışan süreçlerin düzeltmeyi içerdiğini doğrulamayı öneriyor.
• Docker kullanıyorsanız imajınızı yamalı bir tabanla yeniden derleyin ve dağıtın. Etiketlerin eski bir sürüme işaret etmediğini kontrol edin.
• PHP 8.1 ve eskisindeyseniz: satıcınızdan yama isteyin ya da desteklenen bir sürüme geçin. Geçemiyorsanız sunucuyu internetten çekmek, bir VPN ya da güvenlik duvarının arkasına almak ve aşağıdaki geçici önlemleri uygulamak gerekiyor. CISA, yama uygulanamıyorsa PHP tabanlı sistemleri çevrimdışı almayı öneriyor.
• PHP 8.2 kullanıyorsanız yama alın ama planlayın: PHP duyurusuna göre 8.2'nin güvenlik desteği 31 Aralık 2026'da bitiyor.

Hemen yama yapamıyorsanız PHP'nin kendi duyurusunda geçici önlemler var. Duyuru bunların "belirli saldırı yollarını azalttığını ama kurulumu güvenli yapmadığını" açıkça söylüyor. Aşağıdaki örnek ayarlar, duyurudaki yönergelere dayanıyor.

; php.ini (isteklerin ayrıştırılmasından önce uygulanır)
memory_limit = -1            ; mümkünse FPM havuzunda php_admin_value ile
post_max_size = 8M           ; dosya yükleme gerekiyorsa 32M
upload_max_filesize = 8M     ; post_max_size değerinden küçük kalmalı
session.upload_progress.enabled = 0
fatal_error_backtraces = 0   ; yalnızca PHP 8.5
; Ayarlardan sonra tüm PHP işçi süreçleri yeniden başlatılmalı

Bazı notlar. memory_limit değerini -1 yapmak, istek başına bellek sınırını kaldırıyor ve kaynak tüketimi riskini artırıyor; yamadan sonra sonlu bir değere geri dönmek gerekiyor. Bellek sınırı için RLIMIT_AS ya da RLIMIT_DATA kullanmayın, çünkü bunlar açık yolunu tetikleyebilir; yerine konteyner ya da cgroup sınırı önerilir. Ayarlar ini_set() ya da .user.ini ile değil, php.ini, FPM havuzu veya sunucu yapılandırması ile uygulanmalı. Bu önlemler yalnızca doğrulanmış yolları kapatıyor, başka varyantları değil.

Cloudflare ilk bir dizi WAF kuralını tüm müşterilerine, ücretsiz olanlar dahil açtı. Cloudflare bunu kendisi "geçici önlem" olarak adlandırıyor. Patchstack'in notuna göre bu koruma yalnızca sunucunuz trafiği sadece Cloudflare üzerinden alıyorsa işe yarıyor. Ayrıca açığı "kapatan" sahte eklentilere ve internetten kopyalanmış kod parçalarına güvenmeyin; Patchstack da bunlara karşı uyarıyor.

Saldırıya uğradığınızı düşünüyorsanız

Bu belirtiler kanıt değil, yalnızca ipucu: olağandışı büyük ya da bozuk PHPSESSID çerezleri, çok parçalı yükleme isteklerinin ardından gelen bellek sınırı hataları ya da tekrarlanan 500 hataları, açıklanamayan işçi süreci çökmeleri ya da yeniden başlamaları. Wiz bunların ne varlığının ne yokluğunun bir şeyi kanıtlamadığını belirtiyor. CISA ve Huntress'in önerdiği daha somut izleme, PHP işçi süreçlerinin kabuk ya da indirme aracı başlatması. Şüphe varsa sunucuyu izole edin, web sunucusu ve PHP kayıtlarını saklayın, web dizininde yeni dosya, zamanlanmış görev, yeni kullanıcı hesabı ve web kabuğu arayın, sunucudaki parolaları ve anahtarları yenileyin.

Konu nereye varabilir?

Bu bölüm yorum ve tahmin; kesin bilgi değil.

Kısa vadede en olası senaryo, yama alamayan ve görünür sunucularda otomatik taramaların artması. Fastly'den Kelly Shortridge, geniş çaplı sömürü gelecekse bunun saatler ile günler içinde olabileceğini söylüyor (CyberScoop'un aktardığı kadarıyla). Bu hızda, güncelleme yapmayan sunucuların bir kısmı kısa sürede ele geçirilebilir. İlk dalgada en çok zarar görecek olanlar, desteği bitmiş PHP sürümlerinde çalışan ve kimsenin ilgilenmediği siteler. Yukarıdaki VirusTotal sayısına göre sürümünü ifşa eden sunucuların büyük bölümü zaten eski serilerde.

Orta vadede iki şey olası. Birincisi, yeni varyantlar. PHP'nin geçici önlemleri yalnızca doğrulanmış yolları kapatıyor, başka varyantlar için bir şey söylemiyor. Wiz ise PHP'nin yamasının asıl sorunu ve diğer varyantları da ele aldığını yazıyor. Bu yüzden yamalı sürüm, geçici ayarlardan çok daha sağlam bir seçenek. İkincisi, eski sürümler. Yamasız kalan ve desteği bitmiş PHP kurulumları, bu olayın en kalıcı etkisi olabilir. 8.2'nin Aralık sonunda desteğini kaybetmesi, bir sonraki acil güncelleme baskısını şimdiden takvime koyuyor.

Uzun vadede asıl tartışma, yapay zekâ destekli keşfin hızının savunma tarafındaki ritmi nasıl değiştireceği. Bugün olduğu gibi, bir açığın bulunması ile duyurulması arasındaki gizlilik penceresi sızıntıya çok açık. Bu olayda da gizlilik süresi sızıntı yüzünden bir gün kısaldı. Bunun sonucunda yama süreçlerinin, otomatik güncellemenin ve eski sürümleri emekliye ayırmanın daha ciddiye alınması bence bu olaydan çıkacak en olası ders.

Kısa kontrol listesi

• PHP sürümünüzü ve hosting sağlayıcınızın yama durumunu öğrenin.
• Yama: 8.5.12, 8.4.27, 8.3.36 ya da 8.2.35 veya satıcınızın yamalı paketi.
• Güncellemeden sonra tüm PHP ve web sunucusu hizmetlerini yeniden başlatın.
• 8.1 ve eskisinde: yamalı satıcı paketi ya da yükseltme; o zamana kadar sunucuyu internetten çekin.
• Geçici ayarlar yama değildir; yamadan sonra memory_limit değerini geri alın.
• Sahte düzeltme eklentilerine, sahte istismar kodlarına ve sahte güvenlik e-postalarına dikkat edin.
• Parolalarınızı tekrar kullanmayın, iki adımlı doğrulamayı açın.

Kaynaklar

1. PHP.net: Security advisory, 21 Ekim 2026 (erişim: 2026-10-22)
2. PHP.net: Upcoming Critical PHP Security Release, 20 Ekim 2026 (erişim: 2026-10-22)
3. CERT-EU: Critical Vulnerabilities in PHP (2026-018) (erişim: 2026-10-22)
4. CISA: Critical Vulnerabilities in PHP Require Immediate Patching (erişim: 2026-10-22)
5. Qualys: PHP2Shell, PHP Patches Two Critical RCE Vulnerabilities (erişim: 2026-10-22)
6. Huntress: Rapid Response, php2shell (erişim: 2026-10-22)
7. Patchstack: Major security alert, PHP vulnerable to critical RCE (erişim: 2026-10-22)
8. JFrog Security Research: PHP2Shell, all you need to know (erişim: 2026-10-22)
9. Wiz Research: PHP2Shell (erişim: 2026-10-22)
10. watchTowr: PHP Remote Code Execution FAQ (erişim: 2026-10-22)
11. CyberScoop: PHP releases emergency fixes for 2 critical vulnerabilities (erişim: 2026-10-22)
12. Reuters (US News aracılığıyla): Explainer, What Is PHP and Why Did It Take Government Websites Offline? (erişim: 2026-10-22)
13. W3Techs: Usage statistics of PHP (erişim: 2026-10-22)
14. DonanımHaber: PHP nedir, neden tüm interneti tehdit ediyor? (erişim: 2026-10-22)
15. T.C. Siber Güvenlik Başkanlığı: PHP zafiyet duyurusu (erişim: 2026-10-22)
16. T.C. Siber Güvenlik Başkanlığı: TR-26-1372, PHP Programlama Dili Güvenlik Bildirimi (erişim: 2026-10-22)

Görseller: Bu yazı için hazırlanmış özgün grafiklerdir; fotoğraf veya üçüncü taraf logosu içermez.