NLTK 3.10, keyfi dosya okumaya imkân tanıyan yüzde-kodlama bypass açığını giderdi

Python ekosistemindeki en yaygın kullanılan doğal dil işleme kütüphanelerinden biri olan NLTK, keyfi dosya okumaya izin veren yüksek önemde bir path traversal açığını giderdi. CVE-2026-12243 olarak takip edilen ve CVSS 3.1'de 7.5 Yüksek olarak derecelendirilen güvenlik açığı, 3.9.4 dahil olmak kadar önceki NLTK sürümlerini etkiliyor ve dev.to üzerinde yayımlanan teknik bir yazıya göre 3.10.0'da yamalandı.

Bypass nasıl çalışıyor

Hata, bir corpus veya model yüklendiğinde her zaman devrede olan iki fonksiyon olan nltk.data.load() ve nltk.data.find() içinde yer alıyor. İkisi de bir kaynak adı dizgesini dosya sistemi yoluna dönüştürüyor ve NLTK bu dönüşümü, nltk/data.py içindeki literal ../, baştaki eğik çizgi, ters eğik çizgi ve Windows sürücü harflerini reddeden bir regex ile koruyor.

Sorun, kontrol edilen şeyde. Regex yalnızca ham, hâlâ URL-kodlamalı dizge üzerinde çalışıyor; hemen sonraki satır ise standart kütüphanedeki url2pathname() fonksiyonunu çağırıyor ve bu fonksiyon yan etki olarak yüzde dizilerini çözüyor. Bu nedenle corpora/..%2f..%2f..%2fetc%2fpasswd gibi bir kaynak adı, kontrol anında literal ../ içermediği için filtreden geçiyor ve yalnızca doğrulama bittikten sonra gerçek bir traversal'a dönüşüyor. Yazı bunu ders kitabı niteliğinde bir decode-after-check hatası olarak tanımlıyor: kontrol zamanı ve kullanım zamanı aynı dizgenin farklı temsilleri üzerinde çalışıyor.

Huntr üzerinden dosyalanan bir kavram kanıtına dayanan rapor, payload'ları karşılaştırıyor. nltk:../../../etc/passwd tasarlandığı gibi engelleniyor; nltk:%2fetc%2fpasswd ise sıyrılıp mutlak bir yola解码 ediyor — pardon, mutlak bir yola çözülüyor — ve yinelenen %2e%2e bölümlerinden oluşturulan bir varyant beş seviye yukarı çıkarak veri dizininin dışına taşıyor. İlgili bir diğer payload olan nltk:%2fproc%2fself%2fenviron ise süreç ortam dosyasını hedefliyor; bu dosya sık sık API anahtarları, veritabanı kimlik bilgileri ve değişken olarak aktarılan bulut sırlarını barındırıyor.

Eksik kalan önceki yama

NLTK, GitHub issue #3504 kapsamında path traversal sorununu daha önce ele almıştı ve bu azaltım tam olarak yukarıda açıklanan regex'ti. Karaliste kendisi doğruydu — literal traversal desenleri, baştaki eğik çizgiler ve sürücü harflerinin hepsi yakalanıyordu — ancak yalnızca kodlanmış formu gördüğü için, aynı desenin kodlanmış bir kopyası sıyrılabiliyordu.

İkinci savunma hattı opt-in

NLTK ayrıca, dosya açılmadan hemen önce yolu yeniden kontrol etmeyi amaçlayan bir nltk.pathsec modülüyle geliyor. Ancak varsayılan olarak yalnızca NLTK_PATHSEC_ENFORCE ortam değişkeni açıkça ayarlandığında exception fırlatıyor; aksi halde bir RuntimeWarning yayımlıyor ve open() çağrısı yine de devam ediyor. Kutudan çıktığı haliyle, bypass edilmiş bir regex'i yakalayabilecek tek güvence, çok fazla bir şey olmayan bir log satırından ibaret.

Kimler etkileniyor

Rapor, harici olarak kontrol edilen girdiyi kaynak adı olarak load() veya find() fonksiyonlarına aktaran her uygulamayı işaret ediyor: kullanıcıların corpus veya model seçmesine izin veren NLP web servisleri ve API'ler, kullanıcı tarafından sağlanan kodu çalıştıran barındırılan notebook servisleri, kaynak tanımlayıcılarını kiracıya göre parametreleştiren çok kiracılı ML pipeline'ları ve harici girdiden kaynak yolları inşa eden CI/CD pipeline'ları.

CVSS vektörü (AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:N/A:N) hikâyeyi anlatıyor: yalnızca gizlilik. Hiçbir şey değiştirilmiyor veya devre dışı bırakılmıyor, ancak saldırgan sürecin kullanıcısının okuyabildiği her şeye okuma erişimi kazanıyor — /etc/passwd ve /proc/self/environ ötesinde bu, uygulama yapılandırma dosyalarını, SSH özel anahtarlarını ve yerel olarak önbelleğe alınmış bulut-meta verisi yanıtlarını kapsıyor.

3.10.0'daki yama

3.10.0 sürümü, kodu çözülmüş formu doğrulayarak kök nedeni ele alıyor. Yeni bir yardımcı olan _assert_no_encoded_bypass(), aynı güvenli olmayan desen regex'ini tek bir unquote() geçişinden sonraki dizgeye uyguluyor ve url2pathname()'ın gerçekleştirdiği tekil decode'u yansıtıyor.

Yazı üç tasarım kararını öne çıkarıyor. İkinci bir karaliste icat etmek yerine aynı regex yeniden kullanılıyor ve böylece senkron tutulması gereken tek bir politika kalıyor. Decode işlemi tam olarak bir kez yapılıyor, çünkü yinelenen decode %2520 gibi — literal %20 — meşru şekilde çift kodlanmış değerleri bozardı. Ve artık her giriş noktası kontrolü çalıştırıyor — ret sarmalayıcısı, normalize_resource_url() içindeki nltk: şema işleme ve find() içindeki derinlemesine savunma kontrolü — böylece kaynak adının, kodu çözülmüş kontrol çalışmadan dosya yoluna dönüştüğü hiçbir kod yolu kalmıyor.

Ne yapmalı

Birincil öneri NLTK 3.10.0 veya sonraki bir sürüme yükseltmek. Hemen yükseltme mümkün olmadığında NLTK_PATHSEC_ENFORCE=true ayarı pathsec katmanının uyarısını sert bir engelle çeviriyor, ancak rapor bunu yamanın yerine geçen bir çözüm değil, geçici bir azaltım olarak çerçeveliyor.

Neden önemli

NLTK, Python NLP çalışmalarının büyük bir bölümünün altında yatıyor ve kaynak yükleyicileri bir corpus veya model her açıldığında çalıştığı için savunmasız yüzey geniş. CVSS vektörü ayrıca sorunu ayrıcalık veya kullanıcı etkileşimi gerektirmeyen, ağ üzerinden sömürülebilir bir açık olarak işaretliyor; bu, kullanıcı tarafından sağlanan kaynak adlarını kabul eden servisler için en çok önem taşıyor. Bu tek kütüphanenin ötesinde, hata yinelenen bir başarısızlık modunun temiz bir örneği: bir dizgenin bir temsilini doğrularken diğerini kullanmak. Ayrıca varsayılan olarak zorunlu kılınmayan bir derinlemesine savunma katmanının gerçek koruma sağlamadığını gösteriyor — pathsec modülü mevcuttu ve bypass'ı durdurabilirdi, ama bir uyarı olarak geldi. NLP servisleri çalıştıran ekipler, yamalanmamış dağıtımları servis hesabı için bir keyfi-okuma aracı olarak görmeli.