PHP Nedir, Ne İşe Yarar?

PHP sunucuda çalışan bir betik dili. Tarayıcı bir sayfa istediğinde sunucudaki PHP kodu devreye girer, gerekirse veritabanına bağlanır, HTML’i üretir ve ziyaretçiye yalnızca bitmiş çıktıyı yollar. Kodun kendisi kullanıcıya hiç ulaşmaz.

Yapılan iş de çeşitli: üyelik sistemleri, iletişim formları, e-ticaret sepetleri, blog motorları, yönetim panelleri, REST API’ler. Word Press PHP ile yazıldı ve W3Techs’in Eylül 2026 ölçümüne göre internetteki tüm sitelerin yüzde 40,7'sini çalıştırıyor. Wikipedia, Etsy ve Mailchimp gibi büyük isimler de PHP kullanıyor. Aynı kurumun 26 Ekim 2026 verisinde, sunucu tarafı dili belirlenebilen sitelerin yüzde 69,2'si PHP üzerinde çalışıyor. Yani “PHP öldü” lafı, kullanım rakamlarıyla pek örtüşmüyor. Yine de pay yıllar içinde geriledi ve Java Script, Temmuz 2026'da Ruby’yi geçip ikinci sıraya yerleşti.

Küçük Bir Araçtan Dile

Hikâye 1994'te Rasmus Lerdorf’un kendi özgeçmiş sayfasına gelen ziyaretçileri izlemek için C ile yazdığı küçük CGI programlarıyla başladı. Bunları 8 Haziran 1995'te “Personal Home Page Tools” adıyla Usenet’te duyurdu. Form işleme ve HTML’in içine gömülebilen basit bir söz dizimi vardı. Lerdorf sonradan, bir programlama dili yazmak gibi bir niyeti hiç olmadığını, dilin kendi kendine büyüdüğünü anlattı.

1997'de PHP/FI 2.0 geldi. 1998'de Zeev Suraski ile Andi Gutmans motoru baştan yazıp PHP 3'ü çıkardı, ad da “PHP: Hypertext Preprocessor” oldu. PHP 4 (2000) Zend Engine’i getirdi. PHP 5 (2004) nesne yönelimli programlamayı oturttu, bugünkü framework’lerin temeli o dönemde atıldı. PHP 6 yarıda kaldı ve hiç yayımlanmadı, numara doğrudan 7'ye atladı.

PHP 7 (2015) hızda büyük bir sıçrama yaptı. PHP 8 (2020) JIT derleyiciyi, union type’ları, adlandırılmış argümanları ve attribute’ları getirdi. 8.1'de enum’lar ve fiber’lar geldi. 8.4'te property hook’lar ve asimetrik görünürlük eklendi. 20 Kasım 2025'te çıkan PHP 8.5 pipe operatörünü, standartlara uygun yeni URI eklentisini, clone with söz dizimini ve arrayfirst() ile arraylast() fonksiyonlarını getirdi. PHP 8.6'nın 19 Kasım 2026'da çıkması planlanıyor, şu an aday sürüm aşamasında.

Bugünkü PHP, 2005'te yazılan PHP’ye pek benzemiyor. Katı tipler, enum’lar, Composer ile paket yönetimi ve ciddi test araçları var. Eleştirilerin bir kısmı, mesela tutarsız fonksiyon adları, hâlâ geçerli. Ama dilin amatör imajı artık eskisi kadar hak edilmiş sayılmaz.

Dilin yönetimi de değişti. Eskiden birkaç gönüllünün omzundaydı, bugün geliştirme PHP Foundation ve PHP Group gibi yapıların desteğiyle yürüyor. Yeni özellikler RFC adı verilen öneri sürecinden, topluluk oylamasıyla geçiyor. Bu yüzden değişiklikler artık kimsenin keyfine bırakılmış değil; geriye dönük uyumsuzluklar uzun uyarı dönemlerinden sonra yürürlüğe giriyor.

Hangi Sürüm Hâlâ Destekleniyor?

Ekim 2026 itibarıyla desteklenen dallar 8.2, 8.3, 8.4 ve 8.5. PHP 8.5 için güvenlik yamaları 31 Aralık 2029'a kadar sürecek. 8.4'ün aktif desteği 31 Aralık 2026'da bitiyor, güvenlik desteği ise 31 Aralık 2028'e kadar devam ediyor. 8.2 yalnızca güvenlik düzeltmesi alıyor ve 31 Aralık 2026'da tamamen kapanıyor. PHP 8.1 ve öncesi desteksiz. 8.3'ün bitiş tarihi kaynaklar arasında tutarsız: Bazıları Aralık 2027, biri Kasım 2026 veriyor. Planınızı yapmadan önce php.net’teki Supported Versions sayfasından kontrol edin.

PHP ekibi yılda bir minör sürüm çıkarıyor ve her sürüme yaklaşık dört yıl destek veriyor. Bu takvim, yazılımı güncel tutmayı şansa bırakılmayacak bir iş haline getiriyor. Yılda bir geçiş yapan ekip, beş yıl sonra tek seferde dev bir geçişle uğraşan ekibe göre çok daha rahat.

Neden Altyapı Olarak PHP Seçildi?

Sebep teknik üstünlükten çok pratikliktı. PHP’nin yayıldığı yıllarda paylaşımlı hosting ucuzdu ve PHP desteği neredeyse standarttı. Bir dosyayı FTP’yle yüklemek yetiyordu; ayrı sunucu süreci, derleme adımı ya da karmaşık kurulum gerekmiyordu. HTML’in içine kod yazılabildiği için bir tasarımcı bile dinamik sayfa çıkarabiliyordu. Her istek kendi süreci içinde başlayıp bittiği için bir hata sunucunun geri kalanını çökertmiyordu. Öğrenmesi de barındırması da kolay bir modeldi.

Sonra ekosistem işi kilitledi. Word Press, Drupal, Joomla ve Magento gibi ürünler PHP üzerine kuruldu. Bir şirketin web sitesine ihtiyacı olduğunda seçim çoğu zaman önceden belliydi. Composer, Laravel ve Symfony gelince projeler düzenli bir mimariyle yazılmaya başladı. PHP bilen geliştirici bulmak da kolaydı, bu da şirketler için ayrı bir gerekçeydi. Bugün bile Word Press ağırlıklı bir pazarda, PHP’nin payının hızla çökmesi için Word Press’in terk edilmesi gerekir.

Bir başka etken maliyet. Bir PHP uygulamasını çalıştırmak için özel bir altyapı gerekmiyor; en ucuz hosting paketi bile işi görüyor. Küçük işletmeler, ajanslar ve serbest çalışanlar için bu fark büyük. Üstelik yıllarca biriken eğitim içeriği, forum cevabı ve hazır eklenti, yeni başlayan birinin bir sorunda yalnız kalmasını nadir bir ihtimal yapıyor.

Açıklar: Eskiden Bugüne

PHP’nin güvenlik geçmişi iki yerden okunmalı: dilin çekirdeği ve üzerine yazılan uygulamalar.

Eski dönem açıklarının çoğu dilin kolaylığından doğdu. registerglobals, URL’den gelen değerlerin otomatik olarak değişkene dönüşmesine izin veriyordu ve sonradan kaldırıldı. Eski mysql* fonksiyonları parametreli sorguyu teşvik etmediği için SQL enjeksiyonu yaygınlaştı, PHP 7'de silindi, yerine PDO ve mysqli öne çıktı. Dosya yüklemelerinin denetlenmemesi, include ile gelişigüzel dosya çağırmak, çıktının kaçışlanmaması (XSS) yıllarca en sık görülen hatalar arasındaydı. 2024'te Windows üzerinde PHP-CGI kullanan sunucuları etkileyen CVE-2024-4577 ise eski bir yapılandırma biçiminin hâlâ risk taşıdığını gösterdi.

Güncel olay doğrudan çekirdeği ilgilendiriyor. 20 Ekim 2026'da PHP çekirdeğindeki iki kritik uzaktan kod çalıştırma açığının ayrıntıları, koordineli duyurudan önce internete sızdı. PHP ekibi ertesi gün, 21 Ekim’de acil bir güvenlik sürümü yayımladı: 8.5.12, 8.4.27, 8.3.36 ve 8.2.35. Açıklar “PHP2Shell” adıyla anılıyor, CVE-2026-109618 ve CVE-2026-109619 numaralarını taşıyor, ikisi de CVSS v4.0'da 9.2 puan aldı.

Teknik özet şöyle: Birincisi, bellek yetersizliği durumunda istek verisinin yarım başlatılmış halde kalmasından; ikincisi, istek durumunun bellek serbest bırakıldıktan sonra da tutulmasından kaynaklanıyor. Saldırgan kimlik doğrulaması olmadan, web sunucusu hesabının yetkisiyle kod çalıştırabiliyor. PHP ekibi bunu mod_php ve varsayılan sınırlarla doğruladı. Sürüm notlarındaki ifade net: Tam bir hafifletme yok, tek güvenli yol güncellemek. CVE numaraları ve bazı ayrıntılar PHP’nin kendi duyurusundan değil, watch Towr ve Huntress gibi güvenlik firmalarının raporlarından geldiği için bu kısmı temkinli aktarıyorum.

Asıl tehlike eski sürümlerde. W3Techs’e göre PHP kullanan sitelerin yüzde 65,5'i PHP 8'de, yüzde 26,7'si PHP 7'de, yüzde 7,7'si PHP 5'te. Yani yaklaşık üçte biri çoktan desteği bitmiş sürümlerde çalışıyor. PHP 8.2'nin desteği de 31 Aralık 2026'da sona eriyor. Plesk gibi bazı panel üreticileri 8.1, 8.0 ve 7.4 için kendi derlemelerini güncelledi, ama bu herkes için geçerli değil. Kendi sunucusunu yöneten biri için iş basit: php -v ile sürümü kontrol edin, yamalı sürüme geçin. Paylaşımlı hostingdeyseniz firmanızdan hangi sürümde olduğunuzu ve yamanın uygulanıp uygulanmadığını yazılı olarak isteyin.

Uygulama katmanı ayrı bir hikâye. Krayin CRM’deki CVE-2026-38526 (CVSS 9.9), TinyMCE yükleme uç noktasının dosya türünü denetlememesinden kaynaklanıyor. Yüklenen .php dosyası web dizininde doğrudan çalıştığı için sorun büyüyor. Yükleme klasörünü kod çalıştırmayacak şekilde yapılandırmak ve uzantıyı sunucu tarafında doğrulamak bu sınıfın temel çaresi. PHP sitelerinde yaşanan ihlallerin çoğu çekirdekten değil, bakımsız eklentilerden ve özel yazılmış kodlardan çıkıyor. PHP2Shell gibi çekirdek açıkları nadir ve o yüzden daha çok ses getiriyor.

JavaScript ve CSS Dünyasına Etkisi

PHP’nin web’e en büyük katkısı, “sayfa dinamik olabilir” fikrini sıradanlaştırmak oldu. İlk yıllarda CSS ve Java Script, PHP’nin ürettiği HTML’in içine serpilen ikincil parçalardı. Word Press’in tema yapısı, şablon parçalarını birleştiren ve stilleri ayrı dosyalara çıkaran bir düzen oturttu. jQuery’nin Word Press ile birlikte yayılması da aynı dönemin ürünü.

AJAX gelince ilişki değişti: Sunucu tam sayfa yerine veri döndürmeye başladı, PHP de json_encode ile JSON üretti. React ve Vue çıkınca PHP ikinci role geçti. Laravel API olarak arkada durdu, Next.js veya Nuxt ön yüzü çizdi. Bu “headless” düzen bugün çok yaygın. Hatta bir PHP ürünü olan Word Press bile blok editörünü React tabanlı Java Script ile yeniden kurmak zorunda kaldı.

Sonra ters bir akım çıktı. Java Script yükünden bıkanlar için Laravel Livewire, arayüz bileşenlerini PHP sınıfı olarak yazdırıyor ve AJAX isteklerini kendisi hallediyor. Alpine.js ile birleşince TALL stack (Tailwind, Alpine, Livewire, Laravel) ortaya çıkıyor. Inertia.js, Vue veya React sayfalarını Laravel yönlendirmesine bağlıyor. htmx ise HTML niteliklerinden AJAX tetikliyor, yani “sunucu HTML döndürsün” fikrine dönüş. Bunu moda diye geçmemek lazım: Java Script derleme zincirinin ağırlığı birçok ekip için gerçek bir maliyet. Öte yandan Laravel’in başlangıç paketleri bile Vite ve Tailwind ile geliyor. Yani PHP dünyası ön yüz araçlarından kaçmıyor, onları kendi içine alıyor.

Güvenlik tarafında da iz var. Çıktısı kaçışlanmayan bir PHP sayfası, saldırganın Java Script’ini ziyaretçinin tarayıcısında çalıştırıyor (XSS). Bu yüzden Content-Security-Policy, Http Only ve Same Site çerezleri ön yüz geliştiricilerinin de alışkanlığı oldu. Blade gibi şablon motorları çıktıyı varsayılan olarak kaçışlıyor, bu da ham PHP şablonlarına göre ciddi bir fark.

Site Sahibi Ne Yapmalı?

Açıkların haberini okuyup geçmek yetmez. Birkaç somut adım var:

Sunucudaki PHP sürümünü öğrenin. Panelde ya da php -v çıktısında görünür. 8.5.12, 8.4.27, 8.3.36 veya 8.2.35 ve üstüne geçin. 8.1 ve altındaysanız yama yok, sürüm atlamanız şart. Word Press kullanıyorsanız çekirdeği, temayı ve eklentileri güncelleyin. Kullanmadığınız eklentiyi pasif bırakmak yerine silin. Yükleme klasörlerinde PHP çalıştırmayı kapatın. Bu, dosya yükleme açıklarının zararını sınırlar. Yönetim panelini ek bir koruma katmanıyla (IP kısıtı, iki aşamalı doğrulama) kapatın. Düzenli yedek alın ve geri yüklemeyi bir kez deneyin.

PHP2Shell gibi bir açık duyurulduğunda saldırganlar otomatik tarama başlatır. Yama ile saldırı arasındaki süre günlerle, bazen saatlerle ölçülüyor. Bu yüzden “sonra bakarım” demek burada pahalıya gelir.

Sonuç

PHP’yi savunmak da ona saldırmak da yarım doğru. Dil yirmi beş yılda ciddi biçimde olgunlaştı, ama dünyadaki PHP kodunun büyük kısmı hâlâ eski sürümlerde ve bakımsız eklentilerde duruyor. Pratik özet: PHP 8.5'e, olmadı en az 8.3'e geçin, 21 Ekim yamalarını uygulayın, eklentileri güncel tutun. Ön yüz için PHP’nin sunduğu seçenekler bugün her zamankinden fazla. Yeni bir proje başlatıyorsanız Laravel ya da Symfony ile modern bir yapı kurmak, eski tarz dağınık PHP dosyalarına göre hem güvenliği hem bakımı çok daha kolaylaştırır. Mevcut bir siteniz varsa, önce sürümünüzü öğrenin ve takvime bir güncelleme günü yazın.

Kaynaklar:

W3Techs: PHP kullanım istatistikleri (26 Ekim 2026) Priority Pixels: İnternetin ne kadarı PHP üzerinde çalışıyor Full Scale: PHP 2026'da hâlâ geçerli mi PHP Manual: PHP’nin tarihçesi Wikipedia: PHP Bacancy: PHP sürüm tarihçesi PHP 8.5.0 sürüm duyurusu (GitHub) Laravel News: PHP 8.5 yayımlandı PHP 8.5.12 güvenlik sürümü (GitHub) Huntress: php2shell hızlı müdahale watchTowr: PHP2Shell SSS Plesk: PHP2Shell duyurusu Modern PHP: Güncel PHP sürümü (Ekim 2026) HeroDevs: PHP EOL tarihleri Krayin CRM CVE-2026-38526 (GitHub) Redberry: Laravel ön yüz mimarisi 2026 Tighten: Laravel’de htmx kullanımı

Press #Laravel #Java Script #CSS #Siber Güvenlik #Yazılım Geliştirme#Word Press #Laravel #Java Script #CSS #Siber Güvenlik #Yazılım Geliştirme

What is PHP, What Does It Do?

PHP is a scripting language that runs on the server. When the browser requests a page, the PHP code on the server kicks in, connects to the database if necessary, generates the HTML, and simply sends the finished output to the visitor. The code itself never reaches the user.

The work done is also diverse: membership systems, contact forms, e-commerce baskets, blog engines, management panels, REST APIs. Word Press is written in PHP and powers 40.7 percent of all sites on the internet, according to W3Techs' September 2026 measurement. Big names like Wikipedia, Etsy and Mailchimp also use PHP. According to the same institution's October 26, 2026 data, 69.2 percent of the sites whose server-side language can be determined are running on PHP. So the saying "PHP is dead" doesn't quite match the usage figures. Still, the share has declined over the years, with JavaScript overtaking Ruby for second place in July 2026.

From a Small Tool to a Language

The story began in 1994, when Rasmus Lerdorf wrote small CGI programs in C to track visitors to his resume page. He announced these on Usenet under the name "Personal Home Page Tools" on June 8, 1995. It had simple syntax that could be embedded into form processing and HTML. Lerdorf later explained that he had no intention of writing a programming language, and that the language grew on its own.

In 1997 PHP/FI 2.0 arrived. In 1998, Zeev Suraski and Andi Gutmans rewrote the engine and released PHP 3, called “PHP: Hypertext Preprocessor”. PHP 4 (2000) brought Zend Engine. PHP 5 (2004) established object-oriented programming, and the foundations of today's frameworks were laid at that time. PHP 6 was abandoned and never released, the number jumped directly to 7.

PHP 7 (2015) made a huge leap in speed. PHP 8 (2020) introduced the JIT compiler, union types, named arguments and attributes. Enums and fibers came in 8.1. Property hooks and asymmetric visibility were added in 8.4. PHP 8.5, released on November 20, 2025, introduced the pipe operator, a new standards-compliant URI extension, the clone with syntax, and the arrayfirst() and arraylast() functions. PHP 8.6 is scheduled to be released on November 19, 2026, it is currently in the candidate release phase.

Today's PHP is not very similar to the PHP written in 2005. There are strict types, enums, package management with Composer, and serious testing tools. Some of the criticisms, such as inconsistent function names, still apply. But the language's amateur image is no longer as deserved as it once was.

The management of the language has also changed. It used to be on the shoulders of a few volunteers, today development is carried out with the support of structures such as PHP Foundation and PHP Group. New features go through a recommendation process called RFC, through community voting. Therefore, changes are no longer left to anyone's whim; retroactive incompatibilities take effect after long warning periods.

Which Version is Still Supported?

As of October 2026, supported branches are 8.2, 8.3, 8.4 and 8.5. Security patches for PHP 8.5 will last until December 31, 2029. Active support for 8.4 ends on December 31, 2026, and security support continues until December 31, 2028. 8.2 only gets security fixes and shuts down completely on December 31, 2026. PHP 8.1 and earlier are not supported. The end date for 8.3 is inconsistent between sources: some give December 2027, one gives November 2026. Check the Supported Versions page on php.net before making your plan.

The PHP team releases a minor release once a year and provides support for each release for approximately four years. This schedule makes keeping software up to date a task that cannot be left to chance. The team that transitions once a year is much more comfortable five years later than the team that tackles a giant transition all at once.

Why was PHP chosen as the infrastructure?

The reason was practicality rather than technical superiority. In the years when PHP spread, shared hosting was cheap and PHP support was almost standard. Uploading a file via FTP was enough; There was no separate server process, compilation step or complex installation required. Since code could be written into HTML, even a designer could create dynamic pages. Because each request started and ended in its own process, an error did not crash the rest of the server. It was a model that was easy to learn and accommodate.

Then the ecosystem locked down the business. Products such as Word Press, Drupal, Joomla and Magento are built on PHP. When a company needs a website, the choice is often obvious. When Composer, Laravel and Symfony arrived, projects started to be written with a regular architecture. It was also easy to find developers who knew PHP, which was another reason for companies. Even today, in a Word Press-dominated market, Word Press would have to be abandoned for PHP's share to collapse rapidly.

Another factor is cost. No special infrastructure is required to run a PHP application; Even the cheapest hosting package does the job. For small businesses, agencies and freelancers, the difference is huge. Moreover, the training content, forum answers and ready-made plugins accumulated over the years make it rare for a beginner to be alone in a problem.

Explains: From the Past to the Present

PHP's security history should be read from two places: the core of the language and the applications written on it.

Many of the deficits of the old period arose from the ease of the language. registerglobals allowed values ​​from the URL to be automatically converted into variables and was later removed. Because the old mysql* functions did not encourage parameterized queries, SQL injection became widespread and was deleted in PHP 7, replaced by PDO and mysqli. Not checking file uploads, calling arbitrary files with include, and not escaping output (XSS) were among the most common mistakes for years. CVE-2024-4577, which affected servers using PHP-CGI on Windows in 2024, showed that an old configuration style still poses a risk.

The current event directly concerns the core. On October 20, 2026, details of two critical remote code execution vulnerabilities in the PHP kernel leaked to the internet ahead of the coordinated announcement. The PHP team released an immediate security release the next day, October 21: 8.5.12, 8.4.27, 8.3.36, and 8.2.35. The vulnerability goes by the name “PHP2Shell” and carries numbers CVE-2026-109618 and CVE-2026-109619, both of which received a score of 9.2 in CVSS v4.0.

The technical summary is as follows: First, in case of memory shortage, the request data remains half-initialized; The second is due to the fact that the request state is retained after the memory is released. The attacker can run code without authentication, with the authority of the web server account. The PHP team confirmed this with mod_php and default limits. The statement in the release notes is clear: There is no full mitigation, the only safe way is to update. Since CVE numbers and some details come not from PHP's own announcement, but from reports by security companies such as Watch Towr and Huntress, I quote this part with caution.

The real danger is in old versions. According to W3Techs, 65.5 percent of sites using PHP are on PHP 8, 26.7 percent are on PHP 7, and 7.7 percent are on PHP 5. That means about a third are already running on out-of-support versions. Support for PHP 8.2 also ends on December 31, 2026. Some panel manufacturers, such as Plesk, have updated their builds for 8.1, 8.0 and 7.4, but this is not the case for everyone. For someone who manages their own server, the job is simple: check the version with php -v, switch to the patched version. If you are on shared hosting, ask your company in writing which version you are on and whether the patch has been applied.

The application layer is a different story. CVE-2026-38526 in Krayin CRM (CVSS 9.9) is caused by the TinyMCE upload endpoint not checking the file type. The problem is compounded because the uploaded .php file runs directly in the web directory. Configuring the installation folder to not run code and verifying the extension on the server side is the main remedy for this class. Most of the violations experienced on PHP sites occur not from the core, but from poorly maintained plugins and specially written codes. Kernel vulnerabilities such as PHP2Shell are rare and therefore make more noise.

JavaScript and Its Impact on the CSS World

PHP's biggest contribution to the web was to trivialize the idea that a "page can be dynamic". In the early years, CSS and Java Script were secondary pieces sprinkled into the HTML generated by PHP. Word Press's theme structure has established a layout that combines template parts and extracts styles into separate files. The spread of jQuery with Word Press is also a product of the same period.

When AJAX came, the relationship changed: The server started returning data instead of a full page, and PHP produced JSON with json_encode. When React and Vue came out, PHP took the second role. Laravel stood behind as the API, Next.js or Nuxt drew the front end. This “headless” layout is very common today. Even Word Press, a PHP product, had to rebuild its block editor with React-based Java Script.

Then a reverse current appeared. For those tired of the Java Script burden, Laravel Livewire prints interface components as PHP classes and handles AJAX requests itself. When combined with Alpine.js, the TALL stack (Tailwind, Alpine, Livewire, Laravel) emerges. Inertia.js connects Vue or React pages to Laravel redirection. htmx, on the other hand, triggers AJAX from HTML attributes, which is a return to the idea of ​​"let the server return HTML". This shouldn't be passed off as a fad: the weight of the JavaScript compilation chain is a real cost for many teams. On the other hand, even Laravel's starter packages come with Vite and Tailwind. So the PHP world is not running away from frontend tools, it is embracing them.

There is also a trace on the security side. An unescaped PHP page executes the attacker's Java Script in the visitor's browser (XSS). That's why Content-Security-Policy, Http Only and Same Site cookies have become the habit of front-end developers. Template engines like Blade escape output by default, which is a significant difference from raw PHP templates.

What Should the Site Owner Do?

It is not enough to just read the news about the vulnerabilities. There are a few concrete steps:

Find out the PHP version on the server. It appears in the panel or in the php -v output. Move to 8.5.12, 8.4.27, 8.3.36 or 8.2.35 and above. If you are on 8.1 or below, there is no patch, you must upgrade. If you're using Word Press, update the core, theme and plugins. Delete the plugin you are not using instead of leaving it inactive. Turn off running PHP in installation folders. This limits the damage of file upload vulnerabilities. Cover the administration panel with an additional layer of protection (IP restriction, two-step verification). Take regular backup and try restoring once.

When a vulnerability like PHP2Shell is announced, attackers initiate automatic scanning. The time between patch and attack is measured in days, sometimes hours. That's why saying "I'll look at it later" becomes expensive here.

Conclusion

It is half right to defend PHP and to attack it. The language has matured significantly in twenty-five years, but much of the world's PHP code still sits in old versions and neglected plugins. Practical summary: Upgrade to PHP 8.5, or at least 8.3, apply October 21st patches, keep plugins up to date. PHP's frontend options are greater today than ever before. If you are starting a new project, building a modern structure with Laravel or Symfony makes both security and maintenance much easier than messy old-style PHP files. If you have an existing site, first find out your version and write an update date on the calendar.

Sources:

W3Techs: PHP usage statistics (October 26, 2026) Priority Pixels: How much of the internet runs on PHP Full Scale: Is PHP still relevant in 2026 PHP Manual: History of PHP Wikipedia: PHP Bacancy: PHP version history PHP 8.5.0 release announcement (GitHub) Laravel News: PHP 8.5 released PHP 8.5.12 security release (GitHub) Huntress: php2shell quick response watchTowr: PHP2Shell FAQ Plesk: PHP2Shell announcement Modern PHP: Current PHP version (October 2026) HeroDevs: PHP EOL dates Krayin CRM CVE-2026-38526 (GitHub) Redberry: Laravel frontend architecture 2026 Tighten: Using htmx in Laravel

Press #Laravel #Java Script #CSS #Cyber ​​Security #Software Development#Word Press #Laravel #Java Script #CSS #Cyber ​​Security #Software Development

Was ist PHP und was macht es?

PHP ist eine Skriptsprache, die auf dem Server läuft. Wenn der Browser eine Seite anfordert, greift der PHP-Code auf dem Server, stellt bei Bedarf eine Verbindung zur Datenbank her, generiert den HTML-Code und sendet einfach die fertige Ausgabe an den Besucher. Der Code selbst gelangt nie zum Benutzer.

Auch die geleistete Arbeit ist vielfältig: Mitgliedschaftssysteme, Kontaktformulare, E-Commerce-Körbe, Blog-Engines, Management-Panels, REST-APIs. WordPress ist in PHP geschrieben und betreibt 40,7 Prozent aller Websites im Internet, so eine Messung von W3Techs vom September 2026. Große Namen wie Wikipedia, Etsy und Mailchimp verwenden ebenfalls PHP. Nach Angaben derselben Institution vom 26. Oktober 2026 laufen 69,2 Prozent der Websites, deren serverseitige Sprache ermittelt werden kann, auf PHP. Der Spruch „PHP ist tot“ passt also nicht ganz zu den Nutzungszahlen. Dennoch ist der Anteil im Laufe der Jahre zurückgegangen, wobei JavaScript im Juli 2026 Ruby auf dem zweiten Platz überholte.

Vom kleinen Werkzeug zur Sprache

Die Geschichte begann 1994, als Rasmus Lerdorf kleine CGI-Programme in C schrieb, um die Besucher seiner Lebenslaufseite zu verfolgen. Diese kündigte er am 8. Juni 1995 im Usenet unter dem Namen „Personal Home Page Tools“ an. Sie verfügten über eine einfache Syntax, die in Formularverarbeitung und HTML eingebettet werden konnte. Lerdorf erklärte später, dass er nicht die Absicht hatte, eine Programmiersprache zu schreiben, und dass die Sprache von selbst gewachsen sei.

1997 kam PHP/FI 2.0 auf den Markt. 1998 schrieben Zeev Suraski und Andi Gutmans die Engine neu und veröffentlichten PHP 3 mit dem Namen „PHP: Hypertext Preprocessor“. PHP 4 (2000) brachte Zend Engine. PHP 5 (2004) begründete die objektorientierte Programmierung und legte damals den Grundstein für die heutigen Frameworks. PHP 6 wurde aufgegeben und nie veröffentlicht, die Zahl stieg direkt auf 7.

PHP 7 (2015) hat einen enormen Geschwindigkeitssprung gemacht. PHP 8 (2020) führte den JIT-Compiler, Union-Typen, benannte Argumente und Attribute ein. Aufzählungen und Fasern kamen in 8.1. Eigenschafts-Hooks und asymmetrische Sichtbarkeit wurden in 8.4 hinzugefügt. PHP 8.5, veröffentlicht am 20. November 2025, führte den Pipe-Operator, eine neue standardkonforme URI-Erweiterung, den Klon mit Syntax sowie die Funktionen arrayfirst() und arraylast() ein. Die Veröffentlichung von PHP 8.6 ist für den 19. November 2026 geplant und befindet sich derzeit in der Kandidaten-Release-Phase.

Das heutige PHP ist dem 2005 geschriebenen PHP nicht sehr ähnlich. Es gibt strenge Typen, Aufzählungen, Paketverwaltung mit Composer und seriöse Testtools. Einige der Kritikpunkte, wie etwa inkonsistente Funktionsnamen, gelten weiterhin. Doch das Amateurimage der Sprache ist nicht mehr so ​​verdient wie früher.

Auch die Verwaltung der Sprache hat sich geändert. Früher lag es auf den Schultern einiger weniger Freiwilliger, heute erfolgt die Entwicklung mit Unterstützung von Strukturen wie der PHP Foundation und der PHP Group. Neue Funktionen durchlaufen einen Empfehlungsprozess namens RFC, bei dem die Community abstimmt. Daher sind Änderungen nicht länger den Laune von irgendjemandem überlassen; Rückwirkende Unverträglichkeiten treten nach längeren Vorwarnfristen in Kraft.

Welche Version wird noch unterstützt?

Ab Oktober 2026 sind die unterstützten Zweige 8.2, 8.3, 8.4 und 8.5. Sicherheitspatches für PHP 8.5 gelten bis zum 31. Dezember 2029. Der aktive Support für 8.4 endet am 31. Dezember 2026 und der Sicherheitssupport läuft bis zum 31. Dezember 2028. 8.2 erhält nur Sicherheitsupdates und wird am 31. Dezember 2026 vollständig heruntergefahren. PHP 8.1 und früher werden nicht unterstützt. Das Enddatum für 8.3 stimmt zwischen den Quellen nicht überein: Einige geben Dezember 2027 an, eine gibt November 2026 an. Überprüfen Sie die Seite „Unterstützte Versionen“ auf php.net, bevor Sie Ihren Plan erstellen.

Das PHP-Team veröffentlicht einmal im Jahr eine Nebenversion und bietet für jede Version etwa vier Jahre lang Support. Dieser Zeitplan macht die Aktualisierung der Software zu einer Aufgabe, die nicht dem Zufall überlassen werden kann. Das Team, das einmal im Jahr wechselt, fühlt sich fünf Jahre später viel wohler als das Team, das einen riesigen Übergang auf einmal in Angriff nimmt.

Warum wurde PHP als Infrastruktur gewählt?

Der Grund war eher die Praktikabilität als die technische Überlegenheit. In den Jahren, als sich PHP verbreitete, war Shared Hosting günstig und PHP-Unterstützung fast Standard. Das Hochladen einer Datei per FTP reichte; Es war kein separater Serverprozess, kein Kompilierungsschritt oder eine komplexe Installation erforderlich. Da Code in HTML geschrieben werden konnte, konnte sogar ein Designer dynamische Seiten erstellen. Da jede Anfrage in einem eigenen Prozess begann und endete, führte ein Fehler nicht zum Absturz des restlichen Servers. Es war ein Modell, das leicht zu erlernen und anzupassen war.

Dann schloss das Ökosystem das Geschäft ab. Produkte wie WordPress, Drupal, Joomla und Magento basieren auf PHP. Wenn ein Unternehmen eine Website benötigt, liegt die Wahl oft auf der Hand. Als Composer, Laravel und Symfony auf den Markt kamen, begann man, Projekte mit einer regulären Architektur zu schreiben. Es war auch einfach, Entwickler zu finden, die PHP beherrschten, was ein weiterer Grund für Unternehmen war. Selbst heute, in einem von WordPress dominierten Markt, müsste WordPress aufgegeben werden, damit der Marktanteil von PHP rapide einbricht.

Ein weiterer Faktor sind die Kosten. Zum Ausführen einer PHP-Anwendung ist keine spezielle Infrastruktur erforderlich. Selbst das günstigste Hosting-Paket reicht aus. Für kleine Unternehmen, Agenturen und Freiberufler ist der Unterschied enorm. Darüber hinaus kommt es aufgrund der im Laufe der Jahre angesammelten Schulungsinhalte, Forum-Antworten und vorgefertigten Plugins selten vor, dass ein Anfänger mit einem Problem allein ist.

Erklärt: Von der Vergangenheit bis zur Gegenwart

Der Sicherheitsverlauf von PHP sollte an zwei Stellen gelesen werden: am Kern der Sprache und an den darauf geschriebenen Anwendungen.

Viele der Defizite der alten Zeit waren auf die Leichtigkeit der Sprache zurückzuführen. registerglobals ermöglichte die automatische Umwandlung von Werten aus der URL in Variablen und wurde später entfernt. Da die alten mysql*-Funktionen keine parametrisierten Abfragen unterstützten, verbreitete sich die SQL-Injection und wurde in PHP 7 gelöscht und durch PDO und mysqli ersetzt. Datei-Uploads nicht zu prüfen, beliebige Dateien mit include aufzurufen und die Ausgabe nicht zu maskieren (XSS) gehörten jahrelang zu den häufigsten Fehlern. CVE-2024-4577, das im Jahr 2024 Server mit PHP-CGI unter Windows betraf, zeigte, dass ein alter Konfigurationsstil immer noch ein Risiko darstellt.

Das aktuelle Ereignis betrifft direkt den Kern. Am 20. Oktober 2026 wurden vor der koordinierten Ankündigung Einzelheiten zu zwei kritischen Schwachstellen bei der Remotecodeausführung im PHP-Kernel ins Internet gelangt. Das PHP-Team veröffentlichte am nächsten Tag, dem 21. Oktober, eine sofortige Sicherheitsversion: 8.5.12, 8.4.27, 8.3.36 und 8.2.35. Die Schwachstelle trägt den Namen „PHP2Shell“ und trägt die Nummern CVE-2026-109618 und CVE-2026-109619, die beide in CVSS v4.0 eine Bewertung von 9,2 erhielten.

Die technische Zusammenfassung lautet wie folgt: Erstens bleiben die Anforderungsdaten bei Speichermangel halbinitialisiert; Der zweite Grund liegt darin, dass der Anforderungsstatus nach der Freigabe des Speichers erhalten bleibt. Der Angreifer kann Code ohne Authentifizierung mit der Berechtigung des Webserverkontos ausführen. Das PHP-Team hat dies mit mod_php und Standardlimits bestätigt. Die Aussage in den Versionshinweisen ist klar: Es gibt keine vollständige Abhilfe, der einzig sichere Weg ist ein Update. Da CVE-Zahlen und einige Details nicht aus PHPs eigener Ankündigung, sondern aus Berichten von Sicherheitsfirmen wie watchTowr und Huntress stammen, zitiere ich diesen Teil mit Vorsicht.

Die eigentliche Gefahr liegt in alten Versionen. Laut W3Techs verwenden 65,5 Prozent der Websites PHP 8, 26,7 Prozent PHP 7 und 7,7 Prozent PHP 5. Das bedeutet, dass etwa ein Drittel bereits mit nicht mehr unterstützten Versionen läuft. Der Support für PHP 8.2 endet ebenfalls am 31. Dezember 2026. Einige Panel-Hersteller, wie beispielsweise Plesk, haben ihre Builds für 8.1, 8.0 und 7.4 aktualisiert, was jedoch nicht bei allen der Fall ist. Für jemanden, der seinen eigenen Server verwaltet, ist die Aufgabe einfach: Überprüfen Sie die Version mit php -v und wechseln Sie zur gepatchten Version. Wenn Sie Shared Hosting nutzen, fragen Sie Ihr Unternehmen schriftlich, welche Version Sie nutzen und ob der Patch angewendet wurde.

Die Anwendungsschicht ist eine andere Geschichte. CVE-2026-38526 in Krayin CRM (CVSS 9.9) wird dadurch verursacht, dass der TinyMCE-Upload-Endpunkt den Dateityp nicht überprüft. Das Problem wird dadurch verschärft, dass die hochgeladene .php-Datei direkt im Webverzeichnis ausgeführt wird. Die Hauptlösung für diese Klasse besteht darin, den Installationsordner so zu konfigurieren, dass kein Code ausgeführt wird, und die Erweiterung auf der Serverseite zu überprüfen. Die meisten Verstöße auf PHP-Seiten entstehen nicht durch den Kern, sondern durch schlecht gewartete Plugins und speziell geschriebene Codes. Kernel-Schwachstellen wie PHP2Shell sind selten und verursachen daher mehr Lärm.

JavaScript und seine Auswirkungen auf die CSS-Welt

Der größte Beitrag von PHP zum Web bestand darin, die Idee zu trivialisieren, dass eine „Seite dynamisch sein kann“. In den Anfangsjahren waren CSS und JavaScript zweitrangige Bestandteile des von PHP generierten HTML. Die Theme-Struktur von WordPress hat ein Layout etabliert, das Vorlagenteile kombiniert und Stile in separate Dateien extrahiert. Auch die Verbreitung von jQuery zusammen mit WordPress ist ein Produkt dieser Zeit.

Als AJAX auf den Markt kam, änderte sich die Beziehung: Der Server begann, Daten statt einer ganzen Seite zurückzugeben, und PHP erzeugte JSON mit json_encode. Als React und Vue herauskamen, übernahm PHP die zweite Rolle. Laravel blieb zurück, als die API, Next.js oder Nuxt das Frontend zeichneten. Dieses „kopflose“ Layout ist heutzutage weit verbreitet. Sogar WordPress, ein PHP-Produkt, musste seinen Blockeditor mit React-basiertem JavaScript neu erstellen.

Dann trat ein Rückstrom auf. Für diejenigen, die den JavaScript-Overhead satt haben: Laravel Livewire druckt Schnittstellenkomponenten als PHP-Klassen und verarbeitet AJAX-Anfragen selbst. In Kombination mit Alpine.js entsteht der TALL-Stack (Tailwind, Alpine, Livewire, Laravel). Inertia.js verbindet Vue- oder React-Seiten mit der Laravel-Umleitung. htmx hingegen löst AJAX aus HTML-Attributen aus, was eine Rückkehr zur Idee darstellt, „den Server HTML zurückgeben zu lassen“. Dies sollte nicht als Modeerscheinung abgetan werden: Das Gewicht der JavaScript-Kompilierungskette ist für viele Teams ein echter Kostenfaktor. Andererseits enthalten sogar die Starterpakete von Laravel Vite und Tailwind. Die PHP-Welt rennt also nicht vor Frontend-Tools davon, sondern begrüßt sie.

Auch auf der Sicherheitsseite gibt es eine Spur. Eine nicht maskierte PHP-Seite führt das JavaScript des Angreifers im Browser des Besuchers aus (XSS). Aus diesem Grund sind Content-Security-Policy-, HttpOnly- und SameSite-Cookies zur Gewohnheit von Frontend-Entwicklern geworden. Template-Engines wie Blade maskieren die Ausgabe standardmäßig, was einen erheblichen Unterschied zu rohen PHP-Vorlagen darstellt.

Was sollte der Websitebesitzer tun?

Es reicht nicht aus, nur die Nachrichten über die Schwachstellen zu lesen. Es gibt ein paar konkrete Schritte:

Finden Sie die PHP-Version auf dem Server heraus. Es erscheint im Panel oder in der php -v-Ausgabe. Wechseln Sie zu 8.5.12, 8.4.27, 8.3.36 oder 8.2.35 und höher. Wenn Sie Version 8.1 oder niedriger verwenden, gibt es keinen Patch, Sie müssen ein Upgrade durchführen. Wenn Sie WordPress verwenden, aktualisieren Sie den Kern, das Theme und die Plugins. Löschen Sie das Plugin, das Sie nicht verwenden, anstatt es inaktiv zu lassen. Deaktivieren Sie die Ausführung von PHP in Installationsordnern. Dadurch wird der Schaden durch Datei-Upload-Schwachstellen begrenzt. Decken Sie das Administrationspanel mit einer zusätzlichen Schutzebene ab (IP-Beschränkung, zweistufige Verifizierung). Erstellen Sie regelmäßig ein Backup und versuchen Sie es einmal mit der Wiederherstellung.

Wenn eine Schwachstelle wie PHP2Shell bekannt wird, starten Angreifer einen automatischen Scan. Die Zeit zwischen Patch und Angriff wird in Tagen, manchmal Stunden gemessen. Deshalb wird es hier teuer, zu sagen: „Das schaue ich mir später an.“

Abschluss

Es ist halb richtig, PHP zu verteidigen und anzugreifen. Die Sprache ist in 25 Jahren erheblich ausgereifter geworden, aber ein Großteil des weltweiten PHP-Codes befindet sich immer noch in alten Versionen und vernachlässigten Plugins. Praktische Zusammenfassung: Upgrade auf PHP 8.5 oder mindestens 8.3, Patches vom 21. Oktober anwenden, Plugins auf dem neuesten Stand halten. Die Frontend-Optionen von PHP sind heute größer als je zuvor. Wenn Sie ein neues Projekt starten, erleichtert der Aufbau einer modernen Struktur mit Laravel oder Symfony sowohl die Sicherheit als auch die Wartung erheblich als unordentliche PHP-Dateien im alten Stil. Wenn Sie eine bestehende Site haben, ermitteln Sie zunächst Ihre Version und tragen Sie ein Aktualisierungsdatum in den Kalender ein.

Quellen:

W3Techs: PHP-Nutzungsstatistik (26. Oktober 2026) Prioritätspixel: Wie viel des Internets läuft auf PHP Full Scale: Ist PHP im Jahr 2026 noch relevant PHP-Handbuch: Geschichte von PHP Wikipedia: PHP Bacancy: PHP-Versionsgeschichte PHP 8.5.0-Release-Ankündigung (GitHub) Laravel News: PHP 8.5 veröffentlicht PHP 8.5.12-Sicherheitsrelease (GitHub) Huntress: php2shell-Schnellantwort watchTowr: PHP2Shell-FAQ Plesk: PHP2Shell-Ankündigung Modernes PHP: Aktuelle PHP-Version (Oktober 2026) HeroDevs: PHP-EOL-Termine Krayin CRM CVE-2026-38526 (GitHub) Redberry: Laravel-Frontend-Architektur 2026 Verschärfen: Verwendung von htmx in Laravel

PHP #PHPGecurity #PHP2Shell #WebDevelopment #WordPress #Laravel #JavaScript #CSS #CyberSecurity #SoftwareDevelopment