Dünyanın en yaygın PHP web çatılarından Laravel’de, saldırganın başka bir kullanıcının hesabına onun API anahtarını bilmeden girmesine imkân veren kritik bir açık duyuruldu. Laravel ekibinin 19 Ekim 2026’da yayımladığı GHSA-f9x3-7vq9-cph6 numaralı güvenlik bülteni, açığın önem derecesini CVSS 4.0 ölçeğinde 10 üzerinden 9,2 olarak belirledi. Açık, CVE-2026-114509 numarasıyla izleniyor.

Sorun yalnızca belirli bir yapılandırmada ortaya çıkıyor: Laravel’in yerleşik “token” kimlik doğrulama sürücüsünü kullanan ve veritabanı olarak MySQL ya da MariaDB çalıştıran uygulamalar. Ancak bu koşullar sağlandığında saldırganın herhangi bir yetkiye ya da kullanıcı etkileşimine ihtiyacı yok. Fransa’nın ulusal siber olay müdahale merkezi CERT-FR de 20 Ekim’de CERTFR-2026-AVI-1343 numaralı uyarıyla Laravel kullanıcılarını güncellemeye çağırdı.

Açık ne yapıyor?

Laravel’de “guard” adı verilen bileşenler, bir isteği kimin gönderdiğini doğruluyor. Token sürücüsü, isteğe eklenen API anahtarını veritabanındaki kullanıcı kayıtlarıyla karşılaştırarak çalışıyor. Bültene göre saldırgan, anahtar yerine metin olmayan, özel olarak hazırlanmış bir değer gönderdiğinde bu değer doğrulama sırasında yanlış işleniyor. MySQL ve MariaDB’nin bazı yapılandırmalarında sorgu, girişi reddetmek yerine beklenmedik bir kullanıcı kaydıyla eşleşiyor.

Bültenin ifadesiyle sonuç, “kimliği doğrulanmamış bir saldırganın, o kullanıcının API anahtarına sahip olmadan başka bir kullanıcı olarak oturum açabilmesi.” Bu da ilgili guard ile korunan her sayfada ve API ucunda hesap ele geçirme anlamına geliyor. Ele geçirilen hesap bir yönetici hesabıysa, saldırgan uygulamadaki tüm verilere ulaşabilir.

Laravel News’ün aktardığına göre açığı güvenlik araştırmacısı Hristijan Manasijev bildirdi. Düzeltme oldukça basit: Güncel kodda, isteğe eklenen anahtarın gerçekten bir metin olup olmadığı veritabanına sorgu gönderilmeden önce kontrol ediliyor. Metin olmayan değerler doğrudan reddediliyor. Eski kod yalnızca değerin “boş olmadığına” bakıyordu.

Bu tür hatalar güvenlik dünyasında “tür karışıklığı” olarak biliniyor: Uygulama bir metin beklerken saldırgan dizi ya da sayı gibi farklı türde bir veri gönderiyor ve kod bu beklenmedik değeri doğru ele alamıyor. PHP gibi değişken türlerinde esnek davranan dillerde ve veritabanlarının farklı türleri birbirine dönüştürdüğü durumlarda bu hata sınıfı sık görülüyor. Laravel ekibi açığın teknik ayrıntılarını bültende sınırlı tuttu; ancak düzeltmenin “yalnızca metin kabul et” kuralına dayanması, sorunun kaynağını açıkça gösteriyor.

Kimler etkileniyor?

Bültene göre 13.29.0 ve 12.68.0 öncesindeki tüm sürümler etkileniyor. Yamalar yalnızca 12 ve 13 sürüm ailesi için yayımlandı. Daha eski Laravel sürümlerini kullanan projelerin yamalı bir sürüm ailesine geçmesi gerekiyor.

Laravel News, bültenin yalnızca yerleşik token sürücüsünü kapsadığını; Laravel’in yaygın kullanılan Sanctum ve Passport paketlerinin kendi guard sürücülerini kullandığını ve bültende etkilenenler arasında sayılmadığını belirtiyor. Bir uygulamanın etkilenip etkilenmediğini anlamanın yolu, config/auth.php dosyasında 'driver' => 'token' satırı olan bir guard bulunup bulunmadığına bakmak.

Yama ağustosta çıktı, uyarı ekimde

Dikkat çekici nokta zamanlama. GitHub kayıtlarına göre yamalı 12.68.0 ve 13.29.0 sürümleri 25 Ağustos 2026’da yayımlandı. Güvenlik bülteni ise yaklaşık sekiz hafta sonra, 19 Ekim’de geldi. Bu, açık kaynak projelerde sık görülen bir uygulama: Düzeltme önce sessizce yayımlanıyor, kullanıcılara güncelleme için zaman tanınıyor, ayrıntılar sonra açıklanıyor.

Bu yaklaşımın iki yüzü var. Ağustostan beri güncelleme yapanlar zaten korunuyor. Ama Laravel’i “çalışıyorsa dokunma” anlayışıyla yöneten, düzenli bakım sözleşmesi olmayan ya da bakımı tek bir geliştiricinin omzuna yüklenmiş projeler hâlâ eski sürümde. Bülten yayımlandığı anda açığın nerede olduğu herkes için görünür hâle geldi; yani yamasız sistemler için risk artık daha yüksek.

Açık kaynak dünyasının bir başka gerçeği de burada görünüyor. Laravel gibi projeler milyonlarca ticari uygulamanın temelini oluşturuyor; ancak bu uygulamalardan kazanç sağlayan şirketlerin önemli bir kısmı, kullandıkları yazılımın güvenlik bakımına ne zaman ne de kaynak ayırıyor. Güncelleme, “sonra bakarız” denilen bir maliyet kalemi olarak görüldükçe, açıkların kapatılması ile sistemlere gerçekten uygulanması arasındaki süre uzuyor.

İkinci açık: Okuma isteğiyle veri silme

Aynı gün yayımlanan ikinci bülten (GHSA-5wcm-3v2w-8362) daha düşük, “orta” önem derecesinde (CVSS 3.1: 6,5). Laravel 12.45 ile gelen JSON:API kaynaklarını etkileyen bu açıkta, salt okuma amaçlı bir uç noktaya özel hazırlanmış bir istek gönderildiğinde, ilişkili bir tabloda yıkıcı bir veritabanı işlemi tetiklenebiliyor. Bültene göre yalnızca okuma yetkisi olan bir kullanıcı, örneğin ilişkili bir tablonun boşaltılması gibi geri döndürülemez veri kaybına yol açabiliyor. Bu açık 12.45.0 ile 13.27.0 öncesi sürümleri etkiliyor; 12.68.0 ve 13.27.0 sürümlerinde kapatıldı. CERT-FR, iki açığın birlikte veri bütünlüğünü bozma, güvenlik politikasını atlatma ve uzaktan hizmet engelleme riski taşıdığını belirtiyor.

Türkiye açısından

Laravel, Türkiye’de de yazılım ajanslarının, e-ticaret girişimlerinin ve kurumsal web projelerinin sık tercih ettiği çatılardan biri. Bu projelerin önemli bir kısmı müşteri hesapları, sipariş bilgileri ve ödeme süreçleri gibi hassas verileri yönetiyor. Bakımı ajanslara ya da serbest çalışan geliştiricilere devredilmiş sitelerde sürüm takibi çoğu zaman aksıyor.

Bu hafta PHP’nin kendisinde de kritik açıklar kapatıldı. CyberNews’in aktardığı PHP2Shell açıkları nedeniyle sunucularını güncelleyen ekiplerin aynı bakım penceresinde Laravel sürümünü de kontrol etmesi akıllıca olur. Çatıyı güncellemek, yalnızca PHP’yi güncellemekten farklı bir iş: Projedeki bağımlılıkların composer ile yükseltilmesini ve uygulamanın yeniden test edilmesini gerektiriyor.

Açığın sonuçları yalnızca teknik değil. Bir hesap ele geçirme, müşterilerin, çalışanların ya da üyelerin kişisel verilerine izinsiz erişim anlamına gelebilir. KVKK kapsamında bu tür bir ihlal, Kişisel Verileri Koruma Kurulu’na bildirim yükümlülüğü doğurur ve veri sahipleri de bilgilendirilmelidir. Bu noktada sorumluluk, yazılımı ücretsiz geliştiren açık kaynak topluluğunda değil, bu yazılımla kâr eden ama bakımına kaynak ayırmayan şirketlerde. Güncellenmeyen bir sistemin bedelini, çoğu zaman verileri sızan sıradan insanlar ödüyor.

Ne yapmalı?

  • Sürümü kontrol edin: composer show laravel/framework komutuyla kurulu sürüme bakın. 12.68.0 veya 13.29.0 altındaysanız güncelleyin: composer update laravel/framework.
  • Token sürücüsünü arayın: config/auth.php içinde token sürücüsü kullanan guard varsa ve veritabanınız MySQL/MariaDB ise bu uygulamayı öncelikli ele alın.
  • Bağımlılıkları denetleyin: composer audit komutu, kurulu paketleri yayımlanmış güvenlik bültenleriyle karşılaştırır.
  • Kayıtları inceleyin: Güncelleme öncesinde API isteklerinde anahtar alanına metin dışı (örneğin dizi biçiminde) değerler gönderilmiş mi, kayıtlarda arayın. Şüpheli bir durum varsa kullanıcıların API anahtarlarını yenileyin.
  • Uzun vadede: Eski token sürücüsünden daha güncel kimlik doğrulama paketlerine geçişi ve düzenli bağımlılık güncellemesini bakım planının parçası yapın.