libcurl CVE-2026-8932: mTLS bağlantı yeniden kullanımında client key farkları göz ardı edildi

libcurl'de CVE-2026-8932 olarak takip edilen düşük şiddetli bir güvenlik açığı, tek bir client certificate ile kimlik doğrulaması yapılmış bir TLS bağlantısının, farklı bir private key ile yapılandırılmış bir istek için yeniden kullanılabilmesine imkân veriyordu. dev.to'da yayımlanan bir yazıya göre libcurl'ün 7.7'den 8.20.0'a kadar olan sürümleri etkileniyor ve düzeltme 24 Haziran 2026'da curl 8.21.0 ile yayımlandı. curl komut satırı aracının kendisi etkilenmiyor.

Neyi yanlış gitti

libcurl, bir aktarım bittikten sonra açık TLS bağlantılarını tutuyor ve sonraki bir aktarım aynı ayarları kullanıyorsa bu bağlantıları yeniden devreye alıyor. Güvenlik açığı, neyin "aynı" sayıldığına karar veren mantıkta yatıyor. TLS yapılandırması iki iç struct'a bölünmüş durumda: match_ssl_primary_config() içindeki yeniden kullanım denetimi ve TLS session-cache anahtarı tarafından fiilen danışılan ssl_primary_config ve kalan seçenekleri barındıran, daha büyük olan ssl_config_data. Bir client certificate'in kilidinin nasıl açılacağını yapılandıran beş alan — SSLCERTTYPE, SSLKEY, SSLKEYTYPE, KEYPASSWD ve SSLKEYBLOB olarak açığa çıkan cert_type, key, key_type, key_passwd ve key_blob — karşılaştırmanın dışındaki ssl_config_data içinde yer alıyordu. Sertifika yolunun kendisi karşılaştırılıyordu, ancak o sertifikayı hangi private key'in açtığını betimleyen alanlar karşılaştırılmıyordu. İki handle bu beş seçenek dışında hiçbir konuda farklı değilse, denetim yine de eşleşme bildiriyor ve ikisi tek bir kimlik doğrulaması yapılmış bağlantıyı paylaşabiliyordu.

Session cache'te de paralel bir zayıflık vardı. Cache anahtarı, bir client certificate kullanıldığını belirtmek için sabit bir ':CCERT' işareti ekliyor ancak hangisinin kullanıldığını kaydetmiyordu; bu yüzden farklı sertifikalarla kurulmuş session'lar cache içinde çakışabiliyordu.

Bypass nasıl işliyor

Pratikteki risk, CURLSH share handle veya multi handle üzerinden birden fazla easy handle arasında bağlantı havuzu paylaşan uygulamalarda ortaya çıkıyor. dev.to yazısı, her kullanıcının kendi private key'i ile mTLS üzerinden kimlik doğrulaması yaptığı bir backend proxy veya API gateway tipik örneğine dikkat çekiyor. Bir handle bir sertifika ve key ile bağlanıyor, handshake'i tamamlıyor ve havuz bağlantıyı o kullanıcı için kimlik doğrulaması yapılmış olarak kaydediyor. Ardından ikinci bir handle, aynı sertifika dosyasını ama farklı bir key kullanarak istek gönderiyor. Yeniden kullanım denetimi yalnızca sertifika yolunu doğruladığı için ikinci handle, yeni bir handshake olmadan mevcut bağlantıyı alıyor ve backend isteği ilk kullanıcı olarak işliyor. curl ekibi sorunu CWE-305, yani bir kimlik doğrulama bypass'ı olarak sınıflandırdı; bunu bellek güvenliği değil bir mantık hatası olarak niteledi ve benzer bir önceki örnek olarak CVE-2022-27782'ye atıfta bulundu. Sorunu Aisle Research'ten Joshua Rogers bildirdi.

Düzeltme

7541ae5 numaralı commit, beş alanı ssl_config_data'dan ssl_primary_config'a taşıyor; böylece yeniden kullanım karşılaştırması artık sertifika türünü, key'i, key türünü, key parolasını ve key blob'unu kapsıyor. Parola, timing saldırılarına dayanıklı olacak şekilde tasarlanmış Curl_timestrcmp() rutini ile karşılaştırılıyor. Alanlar taşındığı için 19 backend dosyasındaki referansların güncellenmesi gerekti; bunların arasında openssl.c, gtls.c, mbedtls.c, rustls.c, schannel.c ve wolfssl.c yer alıyor ve ssl_config->key gibi ifadeler ssl_config->primary.key haline geldi. Session-cache tarafında sabit ':CCERT' işareti gerçek client certificate değeriyle değiştirildi; böylece farklı sertifikalara bağlı session'lar artık aynı girdiyi paylaşmıyor. Taşınan alanlar için clone ve free rutinlerine işleme eklendi ve 3303 ile 3304 adlı iki yeni test vakası davranışı doğruluyor.

Kim harekete geçmeli

dev.to şiddeti düşük olarak bildiriyor; yazı sırasında cve.org veya Red Hat tarafından yayımlanmış bir CVSS 3.1 puanı yok ve curl'ün kendi derecelendirmesi de düşük. Hata, kabaca 2010 tarihli, curl 7.7 civarındaki bir değişikliğe dayanıyor; yani kodda yaklaşık on altı yıl boyunca kaldı. Komut satırı aracı etkilenmiyor çünkü her çağrı kendi havuzuna sahip taze bir süreçtir. Risk, handle'lar arasında bağlantı paylaşırken client-certificate key malzemesini değiştiren uzun süreli uygulamalarla sınırlı; bunlar için çare 8.21.0'a yükseltmek.

Neden önemli

Bu, bir doğruluk hatasının sessizce güvenlik hatasına dönüştüğü bir örnek. Bellek kötü kullanılmadı, veri bozulmadı; kütüphane, bir bağlantıyı geri dönüştürmeden önce yalnızca yanlış soruyu sordu — iki handle'ın aynı kimliği temsil edip etmediğini değil, aynı sertifika dosyasını adlandırıp adlandırmadığını. Daha geniş ders şu: bağlantı havuzlama ve karşılıklı TLS, handshake'i şekillendiren her kimlik bilgisi pool anahtarının parçası olmadıkça kötü bir şekilde etkileşir. Birçok client kimliğini libcurl üzerinden çoğullayan çok kiracılı proxy veya API gateway işleten ekipler, yükseltmeyi düşük şiddet derecesinin önerdiğinden daha ciddi ele almalı; çünkü yanlış kimlik altında kabul edilen bir istek, başarısız olan bir istekten daha kötü olabilir. On altı yıllık hata ömrü ayrıca, yaygın olarak dağıtılan kütüphanelerin on yıl veya daha önce yazılmış varsayımlarının periyodik olarak yeniden gözden geçirilmesinden yarar gördüğünün bir hatırlatıcısı.